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.


$ dig ns com.
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

;novanext.com.          IN  NS

novanext.com.       172800  IN  NS  ns2.net4india.com.
novanext.com.       172800  IN  NS  ns1.net4india.com.

ns2.net4india.com.  172800  IN  A
ns2.net4india.com.  172800  IN  A
ns2.net4india.com.  172800  IN  A
ns1.net4india.com.  172800  IN  A
ns1.net4india.com.  172800  IN  A
ns1.net4india.com.  172800  IN  A

;; 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, 2015 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, 2015 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, 2015 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, 2015 at 16:29
  • @Yaalie Okay, that makes much more sense. I've submitted an answer that should explain this.
    – Andrew B
    Jan 28, 2015 at 16:32

4 Answers 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

This would cause my nameserver to include 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 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, 2016 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, 2016 at 23:48
  • Pinging @HåkanLindqvist in a separate comment since only one notification is allowed per comment.
    – Andrew B
    Dec 7, 2016 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, 2016 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, 2016 at 9:01

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, 2016 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, 2016 at 9:38

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
a.root-servers.net. 30831   IN  AAAA    2001:503:ba3e::2:30
b.root-servers.net. 30831   IN  A
b.root-servers.net. 30831   IN  AAAA    2001:500:84::b
c.root-servers.net. 30831   IN  A
c.root-servers.net. 30831   IN  AAAA    2001:500:2::c
d.root-servers.net. 30831   IN  A
d.root-servers.net. 30831   IN  AAAA    2001:500:2d::d
e.root-servers.net. 30831   IN  A
f.root-servers.net. 30831   IN  A
f.root-servers.net. 30831   IN  AAAA    2001:500:2f::f
g.root-servers.net. 30831   IN  A
h.root-servers.net. 30831   IN  A
;; Received 496 bytes from 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
a1.in.afilias-nst.in.   172800  IN  A
a2.in.afilias-nst.info. 172800  IN  A
b0.in.afilias-nst.org.  172800  IN  A
b1.in.afilias-nst.in.   172800  IN  A
b2.in.afilias-nst.org.  172800  IN  A
c0.in.afilias-nst.info. 172800  IN  A
ns7.cdns.net.       172800  IN  A
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 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 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 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 = 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, 2015 at 12:04

For a more recent way of answering, look now at the official document on DNS terminology, that is RFC 8499.

It defines glue records like this:

Glue records:  "...[Resource records] which are not part of the
  authoritative data [of the zone], and are address RRs for the
  [name] servers [in subzones].  These RRs are only necessary if the
  name server's name is 'below' the cut, and are only used as part
  of a referral response."  Without glue "we could be faced with the
  situation where the NS RRs tell us that in order to learn a name
  server's address, we should contact the server using the address
  we wish to learn."  (Quoted from [RFC1034], Section 4.2.1)

  A later definition is that glue "includes any record in a zone
  file that is not properly part of that zone, including nameserver
  records of delegated sub-zones (NS records), address records that
  accompany those NS records (A, AAAA, etc), and any other stray
  data that might appear."  (Quoted from [RFC2181], Section 5.4.1)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .