Pelicanux

Just A Few Random Words

Dns and Glue-Records

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.

DNS Architecture

  • Here is the global picture of a request of www.pelicanux.net
1
2
3
4
5
6
7
8
9

                                +----+
                           +--->|Root|
                           |    +----+
 +------+       +---------++    +-----------------+
 |Client|+----->|Recursive|+--->|Authoritative TLD|
 +------+       +---------++    +-----------------+
                           |    +------------------+
                           +--->|Authoritative FQDN|
                                +------------------+

  • 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

philippe@phoenix:~$ dig +trace www.pelicanux.net A

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace www.pelicanux.net A
;; global options: +cmd
.         3599915 IN  NS  e.root-servers.net.

... from a to m ...

.         3599915 IN  NS  b.root-servers.net.
;; Received 449 bytes from 192.168.1.1#53(192.168.1.1) in 84 ms

net.          172800  IN  NS  a.gtld-servers.net.

... from a to m ...

net.          172800  IN  NS  m.gtld-servers.net.
;; Received 492 bytes from 192.203.230.10#53(192.203.230.10) in 91 ms

pelicanux.net.        172800  IN  NS  ns.kimsufi.com.
pelicanux.net.        172800  IN  NS  ks3269125.kimsufi.com.
;; Received 147 bytes from 192.55.83.30#53(192.55.83.30) in 86 ms

www.pelicanux.net.    1000    IN  CNAME   pelicanux.net.
pelicanux.net.        1000    IN  A   5.39.82.22
pelicanux.net.        1000    IN  NS  ns.kimsufi.com.
pelicanux.net.        1000    IN  NS  ks3269125.kimsufi.com.
;; Received 117 bytes from 5.39.82.22#53(5.39.82.22) in 31 ms
  • Ok now I got IP address for www.pelicanux.net

But…

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

philippe@phoenix:~$ dig +trace +additional www.pelicanux.net A

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace +additional www.pelicanux.net A
;; global options: +cmd
.         3598750 IN  NS  m.root-servers.net.

... From a to m ...

.         3598750 IN  NS  g.root-servers.net.
f.root-servers.net.   3598750 IN  A   192.5.5.241

... from a to m ...

a.root-servers.net.   3598750 IN  A   198.41.0.4
;; Received 449 bytes from 192.168.1.1#53(192.168.1.1) in 87 ms

net.          172800  IN  NS  a.gtld-servers.net.

... From a to m ...

net.          172800  IN  NS  m.gtld-servers.net.
a.gtld-servers.net.   172800  IN  A   192.5.6.30

... From a to m ...

m.gtld-servers.net.   172800  IN  A   192.55.83.30
;; Received 492 bytes from 192.203.230.10#53(192.203.230.10) in 433 ms

pelicanux.net.        172800  IN  NS  ns.kimsufi.com.
pelicanux.net.        172800  IN  NS  ks3269125.kimsufi.com.
ns.kimsufi.com.       172800  IN  A   213.186.33.199
ks3269125.kimsufi.com.    172800  IN  A   5.39.82.22
;; Received 147 bytes from 192.52.178.30#53(192.52.178.30) in 59 ms

;; Received 35 bytes from 213.186.33.199#53(213.186.33.199) in 25 ms

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…

Glue Records

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.

Sources

Here are some links which helped me understand this: