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? Like a lot of other people in this Ecosystem, we 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. 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.
All these add more complexity to an already complex system.
Since DNS is not restricted to a single machine (being a distributed, coherent, and 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:
Every level in this hierarchy has an important role to play in the resolution process of a Domain Name:
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 will focus 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:
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 returns the authoritative nameservers as ns1 and ns2.yourdomain.
As you may have already noticed, this creates a circular dependency, or other words 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 two 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.
|Catchpoint DNS Monitors
|Experience DNS Test||For DNS tests that use the experience monitor, Catchpoint randomly selects a server from each level of the DNS route and queries it for the domain.|
|Direct DNS Test||This test provides the complete query and response from the DNS server specified for the test along with the length of time it took to complete the test and any errors received during testing.|
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.