Join Log in
Score:-1
avatar Server

What is the limitation on what records a .com domain can have?

kw flag
ZAB

If I don't need a subdomain www, can a mydomain.com domain has an A record pointing directly to my server IP without any mediocre NS servers? How many A or NS records can a .com registry store and what minimum TTL it can have? The question is stupid but I can't find any document on this. It seems like a good practice to let *.gtld-servers.net domain servers who host .com domains registry answer IP directly, but all the domains I check only have NS records and A records with IP to their NS records, like google do for example. google.com has google.com. NS ns1.google.com and ns1.google.com. A 216.239.32.10. Why doesn't it have google.com. A 142.250.185.174 pointing directly to their server? Is it a limitation of the .com registry or what?

50
1 + 0
Score:2
avatar Server
cn flag
Håkan Lindqvist

When you register a domain name, what that gets you in technical terms is the delegation of a zone by that name to the nameservers of your choice.

What that delegation means is that the parent zone adds NS records for your zone and, if needed, glue address records (A/AAAA) records for the names in the NS records (as well as DS if the child zone is signed). The TTL of these records follow whatever policy the registry has in place.
These NS and glue A/AAAA records are not authoritative and are only used to locate the authoritative nameservers that can answer queries for names that are part of the child zone; ie, these delegation records are not used to answer client queries even for these NS or A/AAAA records.

Delegation of zones is how registries operate in general, this is not specific to com.

What you are asking for sounds like an alternative centralized model where the registrant does not get a zone of their own that they can operate as they see fit, instead having the registry host the registrants records as part of the TLD zone.
That is not the model that registries use, but it would be a technically possible alternative kind of service to provide.

0 + 21
kw flag
ZAB
The zone starts under the domain, www.google.com is the domain in the zone. No? Of course the top level domains registry shouldn't have A records for the second level domains. The *.google.com zone is delegated to ns1.google.com. But why can't they have A record for the google.com itself? This limitation looks artificial. The number of queries would be the same anyway. But ok, is this limitations listed somewhere? What kind of records a top level registry can have and what records it can't have? And what about the number of records, it can't have 64 NS records probably, but where is is stated?
0
Reply
cn flag
Håkan Lindqvist
@ZAB The delegation `NS` record in the parent zone defines the end of that zone and the beginning of the child zone. Records for names that are part of the child zone live in the child zone. The type of records in a zone that only does delegations (as was discussed here) are limited to those that I mentioned in my answer (`NS`, glue `A`/`AAAA` if applicable, and `DS` if applicable), and as I noted, those `NS` and `A`/`AAAA` records are not authoritative and therefore not used for answering client queries.
0
Reply
kw flag
ZAB
Those records are used to answer clients. This is how the recursive DNS resolution works. First your caching server connects to the root server asks for .com, then connects to .com and get NS and A records for ns1.google.com, and then pass the same google.com query to ns1.google.com which is redundant, but ok. It also has SOA record and may be something else too. There should be a document that pedantically list all of the above. How many records what type of records minimum and maximum ttl etc. I want to find it.
0
Reply
cn flag
Håkan Lindqvist
@ZAB There are the authoritative `SOA` and `NS` records for the parent zone itself, true. I was answering regarding the records relating the the registered domain name, but if I misunderstood what you were actually asking about I guess my answer was incomplete. What I described is essentially that delegation is all that is done, and the technical side of what the delegation is in technical terms. This makes it clear that you cannot do what your original question asks for. Regarding the policy of how many `NS` records are allowed or what TTL is used, that is probably documented by the registry.
0
Reply
kw flag
ZAB
How to find where is it documented? The records are just strings basically, technically the protocol itself would let me add `mydomain.com. A 127.0.0.1` there or add 64 NS records with TTL of 1 second there, the only reason why I can't do it because scripts check it against some rules. Where is this document describing those rules? I want to read it.
0
Reply
cn flag
Håkan Lindqvist
@ZAB The single most relevant rule for your question is quite simple: they are only doing delegations for the registered domains (details described in my answer). And when you have delegated something, the authoritative records can only live in the delegated (child) zone. This is what my answer tries to make clear.
1
Reply
kw flag
ZAB
I understood and upvoted it. But it is not complete. Its more like an observation. For some reason, call it the delegation principle, registry won't store A record for the mydomain.com itself and mischiefly require client to make another redundant query to a mediocre NS server to get it, despite it can store the A records but only for NS servers. And I want to see the full picture what is allowed what is not allowed, not making assumptions or theories.
0
Reply
cn flag
Håkan Lindqvist
@ZAB As I have said, the delegation `NS` and any glue `A`/`AAAA` are not authoritative and not used to answer client queries anyway. If a client queries for `example.com NS` it will not get the delegation as the answer, but the authoritative `NS` records from the child zone as the answer, so there is no difference there. There is no situation where you get that "shortcut" that you ask for. And as the registry has delegated for registered domain, they *cannot* serve other data as those names are part of a zone that has been delegated elsewhere.
0
Reply
Paul avatar
cn flag
Paul
@ZAB Technically, `127.0.0.1` is a reserved IP address. You seem to be confusing what is _possible_ from a purely programmatic perspective with how everyone on the world wide web works _together_. You need to spend time reading the RFCs.
0
Reply
cn flag
Håkan Lindqvist
@ZAB Could you clarify which part of "only delegation is done for registered domains" (policy decision) or "the delegation consists of non authoritative `NS` and glue `A`/`AAAA` as necessary, and `DS` if desired" (DNS fact) it is that you question. Because if you accept both those claims, then those two combined fully answer your original question, in that it's not possible to do what you ask for in practice, and the only way it could be done would be if registries allowed a non-delegation case where you get to add whatever records into their zone instead of having your domain name delegated.
0
Reply
kw flag
ZAB
@Paul I've used `127.0.0.1` as an example. But actually you can store this IP in the DNS record, why not?
0
Reply
kw flag
ZAB
@HåkanLindqvist you are using the term "glue". Is it just a term or is it technically different, and processed, queried and returned differently? Isn't it an ordinal A record on a binary protocol level like any other A records?
0
Reply
cn flag
Håkan Lindqvist
@ZAB "Glue" is the term used for these address records that are used for bootstrapping purposes. Both the delegation `NS` and the glue `A`/`AAAA` are non-authoritative and again are *NOT* used for answering client queries, *ONLY* for finding the nameservers that can provide answers to client queries. Again, even if a client were to ask for `example.com NS` it would not get *those* `NS` records back as the answer, but the actual authoritative `NS` records from the child zone.
0
Reply
Paul avatar
cn flag
Paul
@ZAB Server Fault is for answering specific questions. Your series of questions are nearly endless. You should spend time reading through the RFCs and then come here to ask specific questions regarding an RFC. Expecting someone to hash out how the entire World Wide Web functions in a comment section is not reasonable, and that is what you are doing, whether you realize it or not (I suspect not).
0
Reply
cn flag
Håkan Lindqvist
@ZAB (The key to why the glue address records are sometimes necessary is that `NS` records refer to nameservers *by name*, and if that name is inside the zone that is being delegated it would be impossible to find out the address unless you bootstrapped the process by providing these glue address records)
0
Reply
kw flag
ZAB
@Paul I can't find this in rfc1035 or other technical RFC describing the protocol. It is more like an administrative or political decision to allow some A records and not allow other A records inside the .com domain registry. It can also be described in an RFC though. Can you point which one? I have a simple question stated in the title. I need a document describing the rules and limitations of the .com registry record storage. The rest is just my naive thoughts and discussion of why some of them are artificial and require redundant queries etc.
0
Reply
cn flag
Håkan Lindqvist
@ZAB The policy decision is to only do delegations. The technical implication is that you can't add any of "your records" in the TLD zone, only the delegation (again, `NS`, glue `A`/`AAAA` records corresponding to those `NS` records as needed, `DS` if desired), everything of yours is in your zone on your chosen nameservers.
0
Reply
cn flag
Håkan Lindqvist
@ZAB And again, there are *no* `NS`, `A` or `AAAA` records relating to your zone that the parent zone nameservers will actually provide the *answers* for. There are only the non-authoritative `NS` and `A`/`AAAA` that are part of the delegation. If you ask the parent for eg `example.com NS` or `ns1.example.com A` (if we assume that is one of the names from `NS` records) you still do not get an answer from the parent zone nameservers, only the normal referral response telling you who to ask about this for the actual answer.
0
Reply
kw flag
ZAB
@HåkanLindqvist how many NS records are allowed what TTL is allowed? Without a document it is hard to guess what kind of hacks is possible and what are prohibited. I can add "mydomain.com. NS www.mydomain.com" and "www.mydomain.com. A <myserverip>" records to the registry. According to you answers it is ok, it is just a glue, right? This should work and I wouldn't even need to setup ns servers. But in reality I will be banned most likely.
0
Reply
cn flag
Håkan Lindqvist
@ZAB As I have been saying, those hacks that you propose do not work as the parent zone nameservers do not provide answers even for those names.
0
Reply
cn flag
Håkan Lindqvist
@ZAB Look at the result of eg `dig @a.gtld-servers.net ns1.google.com A +norec` (you used google.com in some examples before so I stuck to that here). As you see, it contains no answer to the stated question. The *ANSWER* section is completely empty, only the referral (*AUTHORITY* section with `NS`, *ADDITIONAL* section with `A`/`AAAA`) have records and the `aa` (authoritative answer) flag is not set. Ie, a resolver server getting this response will have to ask any one of the nameservers listed in that referral about `ns1.google.com A` before it can give an answer to its client.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.