Glue records is not A record replacement
Someone recently reached out to me discussing DNS and as that person started taking deep dive in DNS, he came across the glue records. He asked me “Why not just use A records on a sub-zone with glue record at the parent zone”?
This was a fantastic question. I am going to document it in this post on why not. First and foremost let’s have a clear understanding of glue records.
Remembering DNS resolution chain
A DNS resolver when tries to resolve a given domain name and following the full resolution chain, tries to find the answer to the query from root servers as a resolver has an IP of 13 root servers hardcoded in the root hints file, they give a non-authoritative reply pointing it to respective TLD server (for .com, .net, .in etc) and next resolver hits the authoritative server to get an answer. I covered this in DNS 101 session last year in November for INNOG (slides here).
Now glue records come in the picture as “google.com” zone uses nameservers as ns1.google.com, ns2.google.com etc. Thus we cannot expect DNS resolver to resolve “google.com” when .com gTLD tells its name server is under the same domain in question i.e ns1.google.com.
anurag@server02 ~> dig google.com ns +short
ns4.google.com.
ns1.google.com.
ns2.google.com.
ns3.google.com.
anurag@server02 ~>
So glue records are used here to break this sort of cyclic dependency. In this example, Google will register A and AAAA records of ns1/2/3/4.google.com on gTLD .com authoritative servers. This is achieved via interfaces from registrars and often called “register nameserver” or “glue records” or “child nameservers” etc.
So back to question - what if Google creates A and AAAA records for say mail.google.com or calendar.google.com right on the .com gTLD instead of creating records on their own authoritative servers? Won’t that reduce one level of lookup to make things faster?
The answer is no. The reason for that is the only an authoritative server for a given zone has the authority to reply for records under that zone. In this example authoritative for “google.com” zone is ns1/2/3/4.google.com and not the .com gTLD. In fact .com gTLD won’t even pass the glue records in the “authority” section of reply but instead in the “additional section” of the record.
anurag@server02 ~> dig @a.gtld-servers.net. google.com ns
; <<>> DiG 9.16.1-Ubuntu <<>> @a.gtld-servers.net. google.com ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13056
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN NS
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 132 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Wed Aug 04 18:36:52 IST 2021
;; MSG SIZE rcvd: 287
anurag@server02 ~>
Here we query for google.com zone and it replies with NS records for Google. It shows that zone is delegated further along with A and AAAA for the nameserver in the additional section, not the authority section.
So while these A/AAAA records exist, we cannot get them in authoritative reply from the gTLD auth.
anurag@server02 ~> dig @a.gtld-servers.net. ns1.google.com a
; <<>> DiG 9.16.1-Ubuntu <<>> @a.gtld-servers.net. ns1.google.com a
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15323
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.google.com. IN A
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 120 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Wed Aug 04 18:39:31 IST 2021
;; MSG SIZE rcvd: 287
anurag@server02 ~>
But if we query for ns1.google.com to one of authoritative, we will get reply within the auth section.
anurag@server02 ~> dig @ns1.google.com ns1.google.com a
; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.google.com ns1.google.com a
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20439
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ns1.google.com. IN A
;; ANSWER SECTION:
ns1.google.com. 345600 IN A 216.239.32.10
;; Query time: 60 msec
;; SERVER: 2001:4860:4802:32::a#53(2001:4860:4802:32::a)
;; WHEN: Wed Aug 04 18:41:30 IST 2021
;; MSG SIZE rcvd: 59
anurag@server02 ~>
Demo with sub-zone
Another way to demonstrate this concept is by creating another subzone. While I don’t obviously have access to google.com zone, let me show that with my domain “anuragbhatia.com” itself. I am going to going to delegate a subzone - subzone.anuragbhatia.com to Hurricane Electric’s authoritative servers (ns1/2/3/4/5.he.net) while parent zone “anuragbhatia.com” stays on Google cloud for now.
anurag@server02 ~> dig anuragbhatia.com ns +short
ns-cloud-e1.googledomains.com.
ns-cloud-e3.googledomains.com.
ns-cloud-e2.googledomains.com.
ns-cloud-e4.googledomains.com.
anurag@server02 ~> dig subzone.anuragbhatia.com ns +short
ns1.he.net.
ns4.he.net.
ns3.he.net.
ns5.he.net.
ns2.he.net.
anurag@server02 ~>
Now if I create a record under subzone.anuragbhatia.com at its authoritative - test1.subzone.anuragbhatia.com
This should work as we would expect it to. DNS resolvers will hit authoritative of parent zone “anuragbhatia.com” and they will give non-authoritative reply passing NS records of Hurricane Electric.
anurag@server02 ~> dig test1.subzone.anuragbhatia.com a @ns-cloud-e1.googledomains.com.
; <<>> DiG 9.16.1-Ubuntu <<>> test1.subzone.anuragbhatia.com a @ns-cloud-e1.googledomains.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31458
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test1.subzone.anuragbhatia.com. IN A
;; AUTHORITY SECTION:
subzone.anuragbhatia.com. 60 IN NS ns1.he.net.
subzone.anuragbhatia.com. 60 IN NS ns2.he.net.
subzone.anuragbhatia.com. 60 IN NS ns3.he.net.
subzone.anuragbhatia.com. 60 IN NS ns4.he.net.
subzone.anuragbhatia.com. 60 IN NS ns5.he.net.
;; Query time: 108 msec
;; SERVER: 2001:4860:4802:32::6e#53(2001:4860:4802:32::6e)
;; WHEN: Wed Aug 04 18:52:32 IST 2021
;; MSG SIZE rcvd: 155
anurag@server02 ~>
anurag@server02 ~> dig test1.subzone.anuragbhatia.com a +short
1.2.3.4
anurag@server02 ~>
Now in the same way, if create test2.subzone.anuragbhatia.com (not at its authoritative i.e Hurricane Electric) but say at parent zone on Google Cloud auth DNS.
So now Google cloud has the A record though it’s not authoritative for the specific subzone.
Let’s ask Google Cloud auth DNS for this record.
anurag@server02 ~> dig test2.subzone.anuragbhatia.com a @ns-cloud-e1.googledomains.com.
; <<>> DiG 9.16.1-Ubuntu <<>> test2.subzone.anuragbhatia.com a @ns-cloud-e1.googledomains.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22927
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test2.subzone.anuragbhatia.com. IN A
;; AUTHORITY SECTION:
subzone.anuragbhatia.com. 60 IN NS ns1.he.net.
subzone.anuragbhatia.com. 60 IN NS ns2.he.net.
subzone.anuragbhatia.com. 60 IN NS ns3.he.net.
subzone.anuragbhatia.com. 60 IN NS ns4.he.net.
subzone.anuragbhatia.com. 60 IN NS ns5.he.net.
;; Query time: 112 msec
;; SERVER: 2001:4860:4802:32::6e#53(2001:4860:4802:32::6e)
;; WHEN: Wed Aug 04 18:57:12 IST 2021
;; MSG SIZE rcvd: 155
anurag@server02 ~>
Thus it doesn’t work and does not reply with the A record.
So the answer to the question about replacing A/AAAA with just glue record is that it is not going to work because the zone is delegated further. But glue record is very much needed if the domain is using nameservers under the same domain.
Have a nice DNS day! :)