DNS is one of the most crucial service around the Internet. And in the meantime, one of the harder to understand. Maybe because of the fact that multiple TTL makes it longer to analyze. Or maybe its criticity makes it harder to play with (contrary to a dummy web server, which can be broken on purpose to understand them). Failure in DNS server implies direct impact on the whole organization. Anyway, as I spent some time understanding it (and even if I still have much to learn about it) I will explain what a Glue Record is and why they are needed.
- Here is the global picture of a request of www.pelicanux.net
1 2 3 4 5 6 7 8 9
First client makes request to its recursing server. It simply requests the server which IP address resides in /etc/resolv.conf or /etc/network/interfaces in Linux world, or the prefered DNS server in Windows systems.
The recursive server start recursion and first looks for NS servers for the . (Root) domain. This is easy enough as the servers for the Root domain (named Root servers) are hard coded into its configuration. Recurser chooses one of them.
The recurser asks him to resolve the net. domain. The chosen NS Root indicates the servers responsible for the net. domain. Let’s call them Authoritative TLD servers, as they are responsible for the net. TLD domain. Recurser chooses one of them.
Finally, recurser asks Authoritative TLD server for the pelicanux.net. domain. The server responsible for this domain is ks3269125.kimsufi.com.
ks3269125.kimsufi.com. is the server to contact to get the information (such as IP address) about www.pelicanux.net.
All these steps can be tracked running dig:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
- Ok now I got IP address for www.pelicanux.net
My recurser has done all these step getting only NS records for each domain layer. How is it possible to contact the server available for the domain knowing only its FQDN?
Well, here is the trick: Additional Section.
In fact, at each point, the servers respond with an additional section indicating the IP address of the server it gives the FQDN. This can be seen with the +additional dig flag set.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
By the way, this lets me contact directly the NS server responsible for the pelicanux.net domain (ks3269125.kimsufi.com.) without having to make an other recursion on it…
Without Additional Section, I would never be able to resolve www.pelicanux.net. Because this implies resolving ns.kimsufi.com. To make it clear, let’s try this resolution:
First resolve com. asking root servers. I know where root servers are (once again, hardcoded in configuration). So, I get answer on com. servers. And now, I ask com. servers for the kimsufi.com. domain. These servers only maps domain with hostname so all I get is the information that ns.kimsufi.com. serves the kimsufi.com. domain. And this is it. Without Additional Section.
What a Glue record is is just the additional information maping NS IP address to the NS FQDN. This is optional if the ns is located outside the domain I am trying to resolve. (In my preview example, to resolve www.pelicanux.net, I had to contact ns.kimsufi.com NS server). But this is totally required when the NS server is located inside the domain I am trying to resolve. (Here, ns.kimsufi.com is inside kimsufi.com).
This is because TLD name server only maps Hostnames to domain names.
Here are some links which helped me understand this: