2

I am bit confused with where "Glue record" is used in DNS.

This documents say

If you are using someone else's name servers (eg. your ISP's), you won't need to worry about glue records. You only need to worry about glue records when you are configuring your own name servers where a circular reference exists.

And so Glue record will be present only for nameservers which are within the domain for which they are authoritative for. i.e they are required if example.com has nameserver as ns1.example.com and it will not be required if it is on another domain.

Based on this document I use dig command to see if glue records are present for domains which have nameserver hosted in another domain. And surprisingly they too have glue records !. I am trying to see if novanext.com has glue record as their nameservers are in different domain.

Updated

$ dig ns com.
;; ANSWER SECTION:
com.            85916   IN  NS  j.gtld-servers.net.
com.            85916   IN  NS  f.gtld-servers.net.
com.            85916   IN  NS  i.gtld-servers.net.
com.            85916   IN  NS  g.gtld-servers.net.
....

And next getting the "glue" record of novanext.com domain.

$ dig ns novanext.com @g.gtld-servers.net.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns novanext.com @g.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55040
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;novanext.com.          IN  NS

;; AUTHORITY SECTION:
novanext.com.       172800  IN  NS  ns2.net4india.com.
novanext.com.       172800  IN  NS  ns1.net4india.com.

;; ADDITIONAL SECTION:
ns2.net4india.com.  172800  IN  A   202.71.131.12
ns2.net4india.com.  172800  IN  A   202.71.131.13
ns2.net4india.com.  172800  IN  A   202.71.131.241
ns1.net4india.com.  172800  IN  A   202.71.128.222
ns1.net4india.com.  172800  IN  A   202.71.128.37
ns1.net4india.com.  172800  IN  A   202.71.129.33

;; Query time: 279 msec

How is this possible ? I have googled a lot but still not able to figure it out. Any help will be appreciated.

  • 2
    I don't actually see the glue record for airbnb.in in your output? All I see is IPV4 and IPV6 glue records for the domains that the servers are indeed authorative for. – Reaces Jan 28 '15 at 10:41
  • 1
    yes absolutely, glue records are IPV4 or IPV6 address of nameservers and this document also says so. Do domain names have glue record ? – Yaalie Jan 28 '15 at 11:58
  • 2
    @Yaalie Reaces is correct, actually. Look closely at the left side of the AUTHORITY section. That's a referral for in., not airbnb.in.. You asked for airbnb.in., but were given a referral to the nameservers for in. because they are the most specific nameservers that root is aware of. dig +trace +additional airbnb.in would show you the full referral chain, glue records included. – Andrew B Jan 28 '15 at 15:26
  • 2
    @AndrewB and Reaces sorry for wrongly pasting the output. I have updated the dig output in my question section. Please refer it – Yaalie Jan 28 '15 at 16:29
  • @Yaalie Okay, that makes much more sense. I've submitted an answer that should explain this. – Andrew B Jan 28 '15 at 16:32
4

And so Glue record will be present only for nameservers which are within the domain for which they are authoritative for. i.e they are required if example.com has nameserver as ns1.example.com and it will not be required if it is on another domain.

Sadly, this is an incorrect conclusion to draw. There's nothing to stop you from serving glue records that aren't strictly necessary. Let's say that I operate the nameservers for example.com, and I want to delegate sub.example.com to ns1.contoso.com.

Defining the delegation is simple enough:

sub.example.com. IN NS ns1.contoso.com.

That should be enough by itself, but I could also define a glue record for it:

ns1.contoso.com. IN A 203.0.113.1

This would cause my nameserver to include 203.0.113.1 in the referrals for ns1.contoso.com as glue. My nameservers aren't responsible for contoso.com, and no sane nameserver on the internet is going to store that glue record in cache.

What they will do is assume that I want 203.0.113.1 to be queried if ns1.contoso.com is not currently in cache. This is fine...until the admins for contoso.com change the IP address of ns1.contoso.com. My glue would be wrong, and in many cases this referral would break.

  • As mentioned in this answer, I've noticed that several TLDs (e.g. COM, NET) provide glue records for nameservers present in other TLDs, as an optimization strategy. It is unclear to me who and how these are created and updated. To give an example: "dig ns MISSERENDIPITY.COM @g.gtld-servers.net." returns a glue record for its nameserver DNS.TECHNORAIL.COM. However, the authoritative nameserver for TECHNORAIL.COM is ARUDNS1.ARUBA.IT. How does COM know (and update) that glue record, when it comes from a nameserver associated to the IT zone? – Thomas Dec 7 '16 at 22:50
  • My practical experience doesn't extend into the TLD registries, unfortunately. Maybe @Alnitak or Håkan could chime in here? – Andrew B Dec 7 '16 at 23:48
  • Pinging @HåkanLindqvist in a separate comment since only one notification is allowed per comment. – Andrew B Dec 7 '16 at 23:48
  • @Thomas it looks like the Verisign name servers are applying an optimisation such that if any domain name contained in their servers has (sibling) glue for "dns.techorail.com" they'll serve it (i.e. there's a "host record" for that server name). Note how they don't return glue for "dns4.arubadns.cz." but only for the .net and .com servers. Now, whether that glue is correct is another matter - I know some VRSN folks I can ask... – Alnitak Dec 8 '16 at 8:49
  • 1
    @Thomas someone, at some point (probably using "EPP") created "host records" for "dns.technorail.com", and provided the IP address. Most likely hypothesis is that at that time the DNS for technorail.com was also at those servers, before it moved to the aruba.it domain, hence the requirement for the glue records. I suspect that the NS records changed, but they didn't remove the host records. – Alnitak Dec 9 '16 at 9:01
3

You should be careful to not confuse glue records with additional section records. While it is true that glue records are placed in the additional section, not all additional records are glue.

In your example with novanext.com, you're seeing additional records for ns1 and ns2.net4india.com. This happens because the .com zone happens to have A records for those name servers, but strictly speaking this is not glue. It is in included in the additional section as an optimization, to save a second lookup.

Note that glue data is not considered to be authoritative. If you try querying the .com name servers for a glue record, you'll get back a referral and you won't get the glue record in the answer section. This is what's happening in the case of misserendipity.com and dns.technorail.com per one of the comments above. There is a host/glue record for dns.technorail.com but you can't see it by querying for it directly because you get the referral instead. Probably this host/glue record is no longer strictly necessary, but since it is there it is included in referrals that reference it.

.com and .net didn't always work this way. It was necessary to change their behavior before they were signed with DNSSEC. This NANOG post explains the change.

  • Thanks for chiming in. Those are some useful insights. One thing remains unclear to me: if the authoritative nameserver for technorail.com (which is arudns1.aruba.it) decides to change the A record of dns.technorail.com in its own zone file, how will this change be propagated to the COM zone file? Wouldn't that host record for dns.technorail.com in the COM zone file remain stagnant without any explicit EPP commands coming from technorail.com's registrar? Thanks! – Thomas Dec 9 '16 at 22:50
  • @Thomas there's no automated mechanism for a change to that A record to update the host record in the .com zone. – Alnitak Dec 10 '16 at 9:38
1

If you ask a root nameserver for the NS record of airbnb.in, it won't know. That's not the job of the root nameservers. The root nameservers will just refer you to the nameservers for the .in registry.

$  dig +trace +additional -t ns airbnb.in

; <<>> DiG 9.7.3 <<>> +trace +additional -t ns airbnb.in
;; global options: +cmd
.           489327  IN  NS  g.root-servers.net.
.           489327  IN  NS  b.root-servers.net.
.           489327  IN  NS  m.root-servers.net.
.           489327  IN  NS  c.root-servers.net.
.           489327  IN  NS  d.root-servers.net.
.           489327  IN  NS  l.root-servers.net.
.           489327  IN  NS  h.root-servers.net.
.           489327  IN  NS  f.root-servers.net.
.           489327  IN  NS  k.root-servers.net.
.           489327  IN  NS  i.root-servers.net.
.           489327  IN  NS  e.root-servers.net.
.           489327  IN  NS  a.root-servers.net.
.           489327  IN  NS  j.root-servers.net.
a.root-servers.net. 30831   IN  A   198.41.0.4
a.root-servers.net. 30831   IN  AAAA    2001:503:ba3e::2:30
b.root-servers.net. 30831   IN  A   192.228.79.201
b.root-servers.net. 30831   IN  AAAA    2001:500:84::b
c.root-servers.net. 30831   IN  A   192.33.4.12
c.root-servers.net. 30831   IN  AAAA    2001:500:2::c
d.root-servers.net. 30831   IN  A   199.7.91.13
d.root-servers.net. 30831   IN  AAAA    2001:500:2d::d
e.root-servers.net. 30831   IN  A   192.203.230.10
f.root-servers.net. 30831   IN  A   192.5.5.241
f.root-servers.net. 30831   IN  AAAA    2001:500:2f::f
g.root-servers.net. 30831   IN  A   192.112.36.4
h.root-servers.net. 30831   IN  A   128.63.2.53
;; Received 496 bytes from 10.20.206.2#53(10.20.206.2) in 38 ms

in.         172800  IN  NS  a2.in.afilias-nst.info.
in.         172800  IN  NS  b1.in.afilias-nst.in.
in.         172800  IN  NS  ns7.cdns.net.
in.         172800  IN  NS  a0.in.afilias-nst.info.
in.         172800  IN  NS  a1.in.afilias-nst.in.
in.         172800  IN  NS  c0.in.afilias-nst.info.
in.         172800  IN  NS  b2.in.afilias-nst.org.
in.         172800  IN  NS  b0.in.afilias-nst.org.
a0.in.afilias-nst.info. 172800  IN  A   199.7.87.1
a1.in.afilias-nst.in.   172800  IN  A   115.249.164.142
a2.in.afilias-nst.info. 172800  IN  A   199.249.117.1
b0.in.afilias-nst.org.  172800  IN  A   199.253.56.1
b1.in.afilias-nst.in.   172800  IN  A   125.19.40.90
b2.in.afilias-nst.org.  172800  IN  A   199.249.125.1
c0.in.afilias-nst.info. 172800  IN  A   199.253.57.1
ns7.cdns.net.       172800  IN  A   194.0.1.7
a0.in.afilias-nst.info. 172800  IN  AAAA    2001:500:29::1
a1.in.afilias-nst.in.   172800  IN  AAAA    2001:4528:fff:13::142
a2.in.afilias-nst.info. 172800  IN  AAAA    2001:500:45::1
b0.in.afilias-nst.org.  172800  IN  AAAA    2001:500:50::1
b1.in.afilias-nst.in.   172800  IN  AAAA    2404:a800:2:1e::19:90
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 32 ms

airbnb.in.      86400   IN  NS  ns4.markmonitor.com.
airbnb.in.      86400   IN  NS  ns7.markmonitor.com.
airbnb.in.      86400   IN  NS  ns5.markmonitor.com.
airbnb.in.      86400   IN  NS  ns3.markmonitor.com.
airbnb.in.      86400   IN  NS  ns2.markmonitor.com.
airbnb.in.      86400   IN  NS  ns1.markmonitor.com.
airbnb.in.      86400   IN  NS  ns6.markmonitor.com.
;; Received 168 bytes from 199.253.57.1#53(c0.in.afilias-nst.info) in 70 ms

airbnb.in.      86400   IN  NS  ns2.markmonitor.com.
airbnb.in.      86400   IN  NS  ns7.markmonitor.com.
airbnb.in.      86400   IN  NS  ns5.markmonitor.com.
airbnb.in.      86400   IN  NS  ns1.markmonitor.com.
airbnb.in.      86400   IN  NS  ns3.markmonitor.com.
airbnb.in.      86400   IN  NS  ns6.markmonitor.com.
airbnb.in.      86400   IN  NS  ns4.markmonitor.com.
;; Received 168 bytes from 64.124.69.50#53(ns1.markmonitor.com) in 35 ms

Note that if you were to try to use, a1.in.afilias-nst.in or b1.in.afilias-nst.in as a nameserver for the .in TLD, you would need using a glue record. Otherwise, there would be a chicken-and-egg problem. The root nameservers responded with glue records for the other nameservers (e.g. ns7.cdns.net = 194.0.1.7) as a performance optimization, even though they aren't required.

The airbnb.in domain doesn't need glue records, since its nameservers are all in .com.

  • 2
    But airbnb.in domain has glue records as you can see my output which has ADDITIONAL section containing the IPv4 and IPv6 addresses of the nameserver. I am referring this document for verifying glue record. – Yaalie Jan 28 '15 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.