Blog Post

Glue Records and Why They are Crucial

In this article, we would be focusing more on a very important concept in DNS; known as “Additional Records” or “Glue Records”.

A lot has been written and discussed about Domain Name System (DNS) in the past few days. The DDoS attacks on one of the major managed DNS Providers a while ago just made us all take DNS issues seriously once again.

So why so much emphasis on getting DNS Right? We at Catchpoint, like a lot of other people in this Ecosystem, strongly believe that DNS is not just a metric but a lifeline; a backbone for our online systems. It is extremely important to the Internet as it lays the foundation for the WWW (World Wide Web).

DNS in simple terms translates Host names to IP Addresses. Though the objective of DNS seems straight forward and simple, yet in real life it has grown to become one of the most complex systems we have today –

  • Domain Registries
  • Global Top Level Domains (gTLDs)
  • Numerous Country Code Top Level Domains (ccTLDs) and
  • an ever growing list of all the new TLDs (.space, .photography etc.)

All these add more complexity to an already complex system.

Since DNS is not restricted to a single machine (being a distributed, coherent and a hierarchical database) and involves multiple hierarchies and entities, ensuring that every hierarchy and entity involved in managing the system is working efficiently becomes crucial. At the top of the hierarchy is the

  • Root(.) followed by
  • gTLD servers and
  • Authoritative Nameservers for domains.

Every level in this hierarchy has an important role to play in the resolution process of a Domain Name**.**

  • The Registries (Verisign managing .COM and .NET)
  • Registrars (GoDaddy and Namecheap)
  • Registrants (We who register a Domain Name)
  • ISPs
  • Managed DNS Service Providers

We all are a part of this system and it becomes extremely important for us, as Registrants, to keep an eye on how these multiple components are functioning to ensure that we have a stable and well-functioning system.

In this article, we would be focusing more on a very important concept in DNS; known as “Additional Records” or “Glue Records”.

Additional Records or Glue Records

In simplest of terms, Glue records are A records or IP Addresses that are assigned or mapped to a Domain Name or a sub-domain. Glue records become extremely important when the Nameservers for a domain name are the sub-domains of the domain name itself.

The Glue records can be seen under the “Additional Section” of a DNS Response.

Let’s take an example to understand how Glue Records work; assume you have a domain name called “yourdomain.com” for which you are using the following set of Nameservers:

ns1. yourdomain.com

ns2. yourdomain.com

In the DNS Resolution process, the authoritative nameservers for yourdomain.com are ns1.yourdomain.com and ns2.yourdomain.com. The DNS resolution for ns1.yourdomain.com would first require the resolution of yourdomain.com which in turn returns the authoritative nameservers as ns1 and ns2.yourdomain.

As you may have already noticed, this creates a circular dependency or in simple terms; a Loop and the resolution never succeeds.

Glue records help in breaking this dependency by providing the IP Addresses for ns1.yourdomain.com and ns2.yourdomain.com in the lookup process, this breaks the loop from getting created as we no longer need to resolve the nameservers for the IP Addresses – these addresses are already provided in the form of “Glue Records”.

In the example above, we see that Glue records helped remove the circular dependency by providing the A Records for ns1.ctrls.in and ns2.ctrls.in which were returned as the Authoritative Nameservers for the domain: ctrls.in. If this was not the case, the DNS Lookup would have failed because of a circular dependency.

For Domain names, which do not use sub-domains of the same domain as Authoritative Nameservers, Glue records help in reducing the number of lookups by providing the IP Addresses for the authoritative Nameservers. Here is an example for Wikipedia.com.

In this case, Wikipedia.org returned ns1.wikimedia.org, ns2.wikimedia.org and ns3.wikimedia.org as the authoritative nameservers for the domain. This would have required an additional level of DNS lookup for Wikimedia.org to get the A/AAAA record for the domain name initially queried for i.e. Wikipedia.org.

One of our customers, a leading CDN provider headquartered in China, reached out to us a while ago, complaining that the A records being returned for 2 of their Nameservers were incorrect (Old IPs).

When investigating this case, we observed that when doing a DNS Experience test for the Nameservers, the IPs being returned by the authoritative nameservers were correct. However, when running a DNS Direct test to the Nameservers of the Domain using any of the gTLDs (a-m.gtld-servers.net.), the IPs returned were the incorrect IPs.

Digs to the domain name using the command: dig “domain name here” @a.root-servers.net returned the same response as Catchpoint’s DNS tests.

Further investigation led us to believe that this was one of those cases where the changes to the GLUE/Additional record at the Domain Registrar’s end was not pushed to the gTLD Servers.

What fixed this issue?

Based on our recommendations, our Client reached out to the Domain Registrar for the domain and got the Glue records updated for the Domain. The change made was pushed to all the gTLD servers and the issue was resolved.

This incident emphasizes the importance of monitoring each level as well as each component of this amazingly vast system we know as DNS. Having a Monitoring strategy focused around DNS is not just recommended but is crucial to discover issues that may be under our control or out of our control.

Synthetic Monitoring
DNS
CDN
SLA Management
Media and Entertainment
This is some text inside of a div block.

You might also like

Blog post

Mastering IPM: Key Takeaways from our Best Practices Series

Blog post

DNS Security: Fortifying the Core of Internet Infrastructure

Blog post

Mastering IPM: Protecting Revenue through SLA Monitoring