Does a.gtld-servers.net have a list of all .com domains?

Question

When I do dig @a.gtld-servers.net example.com, it quickly returns the nameservers for example.com and the IP addresses for those nameservers (glue records).

Does that mean a.gtld-servers.net (and *.gtld-servers.net) have a record of all .com domains locally? They respond very quickly, so I don't think they're making a further query themselves. Similarly, a request for example.com's nameservers doesn't redirect me to domains.starting.with.e.gtld-servers.net or anything.

I do realize a.gtld-servers.net is probably several machines and that I'm being routed to the one nearest me (through that new one-ip-multiple-machine technology), but this would just mean several other machines have all .com domains.

EDIT: Thanks to everyone who answered! Followup question: if someone "hacks into" one of these machines, couldn't they get a list of all .com domains? This seems like useful information, unless it's already available somewhere for free? I realize domain information is public, but is still difficult to obtain in bulk. I'm guess *.gtld-servers.net don't support zone transfers (though .edu's nameservers did, at least a few years ago).

NOTE: I realize example.com isn't an actual domain-- just replace it with any other .com domain above (I originally had xyz.com, but someone correctly edited it to avoid using a real domain name).

Answer 1

Yes, the "x.gtld-servers.net" are the authoritative servers for the "com" top level domain, so they have all the "pointers" for the .com domains. You can see the nameservers for the TLD by running

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero

Answer 2

You got already a reply long ago but I feel we can be more precise and you have a follow-up question, that should have been another question in fact.

So let us go back from beginning.

If you query the root servers to learn about the .COM delegation (note that everything below applies in the same way for .NET as both are handled by the same registry) you get this reply:

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

So in summary any of these nameservers is authoritative for .COM and they all have the same data (so you can broader your question, a.gtld-servers.net is in no way special, everything below will apply to any of these nameservers).

When you will query these nameservers for any .COM/.NET domain name they need to reply authoritatively with the nameservers authoritative for the domain name you are asking for.

Hence, by definition, "Does that mean a.gtld-servers.net (and *.gtld-servers.net) have a record of all .com domains locally?", yet it means exactly that! With some caveat around "all" that is adressed further below.

Note that you speak about glue records, this is a specific case, and not the most frequent one. Typically a request for a domain at any of the above nameservers will just give back one or more NS records.

Let us take time to address the other minor points in your text:

They respond very quickly, so I don't think they're making a further query themselves.

An authoritative nameserver, by definition, has the data it needs to reply queries with, without having to rely on any external resource, otherwise it is not really authoritative.

As for the speed this is partly subjective and highly dependent on what and how you test, but there are several factors: by default DNS uses UDP which is lighter than TCP hence faster, and such nameservers are anycasted which means that with some luck you always have one "near" you.

I do realize a.gtld-servers.net is probably several machines

You can remove the "probably" :-) These nameservers receive so many queries that any single box will never be able to withstand.

If you go to https://stat.ripe.net/192.5.6.30#tabId=routing you will see a lot of information that may be difficult to digest but basically, seeing that this single IP of a.gtld-servers.net (in fact the block in which it is) is announced by several AS all controlled by one company, which is a strong indicator of anycasting, which works beautifully for most of DNS.

If you go to http://www.root-servers.org/ you can learn more. This is related to the root nameservers, not the .COM ones any more, but technically it is exactly the same thing. You could discover for example that the 13 root servers are managed by 12 different organisations accross 930 instances (an instance is not just one server, it is a location, a "point of presence" where the operator has a "node" which is typically routing gear, multiple servers in load balancing/fail over setup, some monitoring/remote hands capabilities, etc.). F for example is in 222 places.

and that I'm being routed to the one nearest me (through that new one-ip-multiple-machine technology), but this would just mean several other machines have all .com domains.

Yes many machines have the list of all .COM domain names. But first a precision: on these nameservers you will get the list of all nameservers for all .COM domain names... which means that for domain names not delegated you will not find them here. This can happen in multiple case:

1. when you register a domain name, you can choose not to set nameservers, or remove them later.
2. your registrar, for example because of a payment dispute could add the status clientHold on your domain name, which makes it disappear from the DNS
3. the registry could put the domain on serverHold for whatever reasons.

(see https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en if you want to learn more about these statuses and others).

Depending on how you define "all" and what you would do with such data, you may then not get really absolutely all of them.

In all the above cases, the domain will not appear on the registry DNS servers, but will appear when you do a whois query. So whois servers (again, not a single box) will also have... the list of all .COM domain names and even more data than on nameservers because:

1. you have really all domain names, including those not resolving and hence not on registry nameservers
2. whois provides far more information, such as contact data

And these are still only public facing registry services having, in some way or part, the list (or part of it) of domain names.

As for your follow-up:

Followup question: if someone "hacks into" one of these machines, couldn't they get a list of all .com domains?

Technically, yes. But:

1. This is certainly not the easiest target you will find online
2. And in this specific case the data is already available for free.

.COM is a gTLD and as such is under contract with ICANN. ICANN mandates all gTLD registries to publish their zonefiles (which is basically what the nameservers use themselves, so the NS records plus the A/AAAA glues), at least once per day, and access is free for anyone as long as you sign an agreement in order to make sure that you do not reuse this data for "bad" purposes (like republishing it yourself).

See https://czds.icann.org/en for all details about that. This can give you access to hundreds of gTLDs zonefiles.

Note that if your question is extended to "if someone hacks into one of these machines and change the content that is adds or removes .COM domain names..." then we can quickly answer with:

1. the changes will not be seen worldwide, since you hack only one box and there are numerous nameservers, first by name then by anycasting
2. DNSSEC may make your changes appear as errors and hence will be spotted quickly (besides any local countermeasures by the operator itself of course).

In short it is not the best idea to do that in order to mess with .COM domain names, and there are other ways.

I realize domain information is public, but is still difficult to obtain in bulk.

See above for ICANN program. As for ccTLD the situation varies but more often they do not give access to their zonefile, and not in real time.

Sometimes, you can access it after some time, for example through "open data" movements. One example: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html for .FR domain names.

I'm guess *.gtld-servers.net don't support zone transfers (though .edu's nameservers did, at least a few years ago).

Easy to test:

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

No, right now, no .COM authoritative nameservers accept AXFR queries. But this is not necessarily the same everywhere. If you query the f.root-servers.net nameserver you can do an AXFR query to get all TLDs published. Some other TLDs may also allow that.

Note that there are "a lot" of recommendations against allowing public AXFR queries. The facts are that they are huge answers by definition, and could strain a server if repeated, that is true. On can argue endlessly on why/if the public has a need of this information. It was more used at the beginning of the DNS to copy zones between nameservers (there are far better alternatives now). So AXFR is often disabled... except that if you do DNSSEC at the same time, in some specific way (that is NSEC and not NSEC3 variant), it is easy to walk, through standard DNS queries and without AXFR, all of your zone and reconstruct the zonefile. Tools exist to do that.

Note also that various providers online will sell you zonefiles and/or list of all domain names for many TLDs, which they acquired by various means (one idea among others: you take the open zonefiles, like .COM, and for TLD .example you query one by one all the name you have found in .COM, that could give you some ideas, besides of course dictionary walking based on the languages most used in the TLD searched).

Answer 3

Do a query for the domain itself – dig @a.gtld-servers.net com. – and look for the "authoritative answer" flag:

snowflake ~ $ dig @a.gtld-servers.net com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
             ^^