question Can I place an A (address) record for my domain name directly in a TLD zone file?

[Detlev]

So, I understand that the normal structure for making a domain name operational is as follows:

1. Store one or more NS (nameserver) records for my domain name in a TLD zone file - e.g.,

.com zone file

EXAMPLE NS NS15.DOMAINCONTROL
EXAMPLE NS NS16.DOMAINCONTROL

2. The TLD zone file also includes A (address) records for those nameservers - e.g.,

NS15.DOMAINCONTROL A 97.74.107.8
NS16.DOMAINCONTROL A 173.20.75.8

3. The nameservers each maintain a zone file that includes one or more authoritative A records for my domain name - e.g.,

EXAMPLE.COM 600 IN A 185.132.04.59

Now, here's my question. Is there a way to place the A record for my domain name directly into the TLD zone file?

I understand why this would not be a good idea. My IP address could change, and it would be inefficient to ask Verisign to update the .com zone file any time my IP address changes. Far better to simply point to one or more authoritative nameservers so that I can easily update the zone file on those nameservers if my IP address changes.

But my question is whether it is nonetheless possible to store the A record for my domain name directly into the TLD zone file so that there is no need to redirect to an authoritative nameserver to resolve a DNS query.

I assume that even if this practice were technically possible, the registry wouldn't permit it. In that vein, I assume that registries permit only registrars to access their registry systems in order to request updates to the zone file. And so, the only A records that registrars place in TLD zone files are domain names for authoritative nameservers, not for end user domain names.

Thanks!

 

[capybara]

What is your problem exactly?

My IP address could change

Domain name has nothing to do with your IP address. The server IP address is supposed to be static. Nowhere in the industry of hosting/data centers the IP address can just suddenly change.

 

[branding]

What is your problem exactly?

Domain name has nothing to do with your IP address. The server IP address is supposed to be static. Nowhere in the industry of hosting/data centers the IP address can just suddenly change.

Sure it can. They get reallocated all the time.

 

[Detlev]

Correct. IP addresses can be reallocated (although there are ways to mostly prevent against that). But regardless, my question doesn't stem from any particular problem that I'm looking to solve. I'm simply researching the DNS from an academic, technical, and legal perspective, and this is a question that has popped up.

What prevents me from using an A record in the .COM zone file for my domain name instead of an NS record that points to an authoritative nameserver? Put differently, what prevents me from using Verisign's .COM nameserver as the authoritative nameserver for my second-level domain?

Is it simply that Verisign permits only registrars to add A records to the .COM zone file, and registrars won't let me place an A record for my domain there?

Again, I understand the logic in not allowing registrants to place A records in TLD zone files. Using NS records that point to stable nameservers and making any changes to the nameserver zone files shields the TLD zone file from thousands (millions?) of updates per day. I'm just trying to understand what practically restricts me from doing this. An RFC perhaps? Registry policies? Registrar policies?

 

[capybara]

I'm just trying to understand what practically restricts me from doing this.

Its not that something "restricts" you, you just don't have any writing access to it at all, and not supposed to. Without having a particular problem I fail to understand your angle, you kinda have answered yourself already. You can't call the air force to send interceptor jets to deal with those pigeons on your balcony, likewise you as an individual can't mess with the zone file.

 

[Detlev]

So, it sounds like it's fundamentally an access restriction. Registries permit only accredited registrars to access their shared registration systems to make changes to the zone file. And registrars will only add A records for nameservers to the zone file (not web servers). I suppose that if I became an accredited registrar myself, I could cheat the system by adding an A record to zone file that purports to be a nameserver but is actually a web server. Or perhaps DNS tools like BIND wouldn't work in that circumstance (expecting to find something different).

I do wonder, though, if registry-registrar agreements generally prohibit registrars from doing this. After quickly perusing a few, I didn't see any restrictions like that. I also wonder if any RFCs counsel against this.

 

[branding]

So, it sounds like it's fundamentally an access restriction. Registries permit only accredited registrars to access their shared registration systems to make changes to the zone file. And registrars will only add A records for nameservers to the zone file (not web servers). I suppose that if I became an accredited registrar myself, I could cheat the system by adding an A record to zone file that purports to be a nameserver but is actually a web server. Or perhaps DNS tools like BIND wouldn't work in that circumstance (expecting to find something different).

I do wonder, though, if registry-registrar agreements generally prohibit registrars from doing this. After quickly perusing a few, I didn't see any restrictions like that. I also wonder if any RFCs counsel against this.

Even if you were a registrar that wouldn't work. If you really are interested in why you cannot make this work the way you propose you should study the DNS system a bit more.

It's way too much to explain in detail in a forum post that would cover all angles and reasons why it cannot be done.

 

[tonyk2000]

If you own somedomain.com and want to use it, you'll need to have nameservers serving somedomain.com zone. This is how DNS system works. It is hierarchical.

In theory, one may have a lot more records in some root zone. It would not be easy to manage, but it is possible. As the result, unexpected side effects may happen. See, for example:
https://forums.cpanel.net/threads/cpanel-27188-autossl-issues-with-gov-co-domains.653987/

However, if you wish to run dns for somedomain.com on lets say alpha.somedomain.com and beta.somedomain.com server names, then their IPs MUST be included into root zone for .com. This process is called "nameserver registration". A registrar would not let you submit the set of {alpha.somedomain.com, beta.somedomain.com} dns servers for somedomain.com if you did not "register" their IPs first (in appropriate section of domain management area). By doing so, you will indeed tell the registry "please add A records for alpha.somedomain.com and beta.somedomain.com right into the .com zone file". And they will do it. But these "A" records would be published if and only if at least one domain with these NS records exists in the zone file. More details:
https://dzone.com/articles/glue-records-and-why-they-are-crucial
Even in this case, separate dns zone for "somedomain.com" is supposed to exist on both machines serving your domains dns, and this zone should also include two A records - for alpha.somedomain.com and beta.somedomain.com

 

[branding]

If you own somedomain.com and want to use it, you'll need to have nameservers serving somedomain.com zone. This is how DNS system works. It is hierarchical.

In theory, one may have a lot more records in some root zone. It would not be easy to manage, but it is possible. As the result, unexpected side effects may happen. See, for example:
https://forums.cpanel.net/threads/cpanel-27188-autossl-issues-with-gov-co-domains.653987/

However, if you wish to run dns for somedomain.com on lets say alpha.somedomain.com and beta.somedomain.com server names, then their IPs MUST be included into root zone for .com. This process is called "nameserver registration". A registrar would not let you submit the set of {alpha.somedomain.com, beta.somedomain.com} dns servers for somedomain.com if you did not "register" their IPs first (in appropriate section of domain management area). By doing so, you will indeed tell the registry "please add A records for alpha.somedomain.com and beta.somedomain.com right into the .com zone file". And they will do it. But these "A" records would be published if and only if at least one domain with these NS records exists in the zone file. More details:
https://dzone.com/articles/glue-records-and-why-they-are-crucial
Even in this case, separate dns zone for "somedomain.com" is supposed to exist on both machines serving your domains dns, and this zone should also include two A records - for alpha.somedomain.com and beta.somedomain.com

This covers most aspects. You can work around the glue records if you want to use the NS for other domains but it would require an additional lookup and is not recommended or concidered to be bad practice. Some registrars prevent you from using unregistered nameservers at all.

I would advise against it as well unless you know what you're doing.

 

[Jurgen Wolf]

TLD zone file contains only authoritative nameservers for each domain and nothing more.

 

[lock]

It will make no difference your site will work as it did no seo will change nothing you will notice other than number.

 

[jmcc]

So, I understand that the normal structure for making a domain name operational is as follows:

The A record, in the TLD's zone file, basically gives the IP address of the nameserver that is to be queried next for information about the domain name. What happens is something like this (extremely simplified. ):
The root zone servers contain the authoritative nameservers and DNS IP addresses, and some other stuff for the TLDs ( https://www.internic.net/domain/root.zone )

query: which nameservers know about www.yourwebsite.example?
answer: root zone servers say check nameservers for .example
forwarded query: To authoratitive nameservers for .example: which nameservers know about www.yourwebsite.example?
answer: check nameserver running on the A record you supplied.
---- query then goes to the nameserver specified for your domain name (A record saves and extra lookup for the IP)
forwarded query: To your nameserver tell me about www.yourwebsite.example
(the IP in the A record nameserver for your domain name) which has no nameserver software running.)
result: query fails. (SERVFAIL error code)

The TLD's zonefile contains the domain names and the authoritative nameservers for those domain names. It may also include the A record for those nameservers. That's possibly the confusing part. There is an expectation that there will be nameserver software running on those nameservers (NS) that will then answer the queries about your website/domain name from that domain name's zone file.

What you want to do, from a DNS point of view, is effectively make the TLD's zone file the zone file for your domain name so that the queries will just stop with the TLD's zone file. The query chain is this:

query -> root zone DNS -> TLD authoritative DNS -> your DNS -> your site

What you are trying to do is this:
query -> root zone DNS -> TLD authoritative DNS-> your site.

(I've left out the query to your ISP's DNS which is then forwarded to the root servers.)

Most of the registries are trying to get away from including A records for nameservers other than their own in their TLD's zone files and it was one of the things that was discussed when the 2012 round of new gTLDs were being considered. (This is the concept paper from the ICANN Zone File Access advisory group for the CZDS which now provides access to the zone files from the new gTLDs and some of the legacy gTLDs: https://archive.icann.org/en/topics/new-gtlds/zfa-concept-paper-18feb10-en.pdf ) It was necessary to standardise the zone files as up to that point some TLDs had their own format The .NAME zone file was quite different to others (more complex as it contained much more data than simple domain name/nameserver stuff) and was more difficult to parse. Most of the new gTLD zone files only include the A records for the TLD's nameservers. The reason for this shift was that .COM/NET/ORG used to have to have a role account assigned for each same-TLD nameserver (a .COM nameserver would have its own role account etc). That was OK when the Internet was small but the .COM is now over 143 million registrations. The current size of the .COM zonefile is over 10GB.

The role account for the nameserver could make changes to the IP address for the nameserver. This was back when Network Solutions used to send out paper invoices for registrations. The number of DNSes was also much lower but as more people got on line and more hosters started running their own nameservers, that approach became a bit cumbersome. Some control panel software also sets up DNS automatically so that it is not unusual to see hundreds of thousands of nameservers in .COM being authoritative for only a single domain name.

Regards...jmcc

 

[Detlev]

Thanks very much, everyone. I think this answers my question. To summarize:

Two things prevent me (a lowly registrant) from adding A records for my web server directly into the TLD zone file (in order to bypass the additional step of querying a separate nameserver or, put differently, in order to use the TLD nameserver as the authoritative nameserver for my domain).

(1) The registry operator will not permit me to add A records to the TLD zone file. Registry operators permit only accredited registrars to "register" authoritative nameservers, in response to which the RO will add the IP address of the nameserver to the TLD zone file (but only if at least one domain name in the TLD zone file has an NS record pointing to the nameserver name). This is an Organization Limitation. (Thanks, @tonyk2000)

(2) Even if I tried to cheat the system by becoming accredited as a registrar and then "registering" a nameserver IP address that was actually the IP address of my web server, it still would not work. The recursive resolver would interpret the A record returned by the TLD nameserver not as the ultimate address associated with the domain name but as the IP address of the authoritative nameserver for the domain name. And so, rather than forwarding that IP address back to user clients/browsers to use to send HTTP requests to the web server, the resolver would try to query the IP address to ask for the A record for the domain name. Finding no nameserver software running on the web server, the query would fail. This is a Technical Limitation. (Thanks, @jmcc)

(BTW, I suppose the DNS response from the TLD nameserver that returns the A record also indicates that it's a referral to an authoritative nameserver and not the end address of the domain name?)

There may also be a third reason: Registry operators may permit A records in their TLD zone files only for their nameservers. However, it looks like that's not uniform across the industry yet.

Please let me know if I've misstated anything. Thanks for helping me to support my assumption with clear reasons rather than merely intuition.

 

[tonyk2000]

@Detlev - just accept how DNS in case of common gtlds work No need to become accredited registrar for investigative purposes... And, by the way - if you register www.somedomain.com as a nameserver, and assign this nameserver to anotherdomain.com - then there would be A record for www.somedomain.com right in the com zone file. If and only of anotherdomain.com still remains active with www.somedomain.com listed as its nameserver. In this case, routine requests for www.somedomain.com would be served by the root zone. It is how the things are supposed to work, at least technically.
It may well be that your registrar will show an error if you try to register a nameserver starting with www., because the registrar would assume that you are doing something wrong... not a normal endusers behavior to register nameservers starting with www, maybe ns1. or ns2 are common, but www. is not. However, technically it should work.