-
Wait...
-
Something is missing here!
-
How could the resolver find 'ns1.dnsimple.com' before 'dnsimple.com'?
-
Since 'ns1.dnsimple.com' is a subdomain of 'dnsimple.com', how could we resolve 'ns1.dnsimple.com' without resolving 'dnsimple.com' first?
-
Isn't the search going backwards?
-
Wouldn't we get stuck in a loop at some point?
-
For example, let's say that the authoritative server for domain.com is ns1.domain.com
-
If I wanted to browse domain.com, the .COM TLD would tell me to get the IP address from the authoritative server: ns1.domain.com
Go ask ns1.domain.com
-
ns1.domain.com is a subdomain of domain.com
We cannot get to a subdomain without getting to the domain first!
-
Stuck in a loop!
-
So, what happened? How come the resolver was able to find 'dnsimple.com' through 'ns1.dnsimple.com'?
-
Simple!
Glue records!
-
Glue records?
-
Exactly!
-
Awesome!
I'll explain then!
-
When the resolver asked the .COM TLD about dnsimple.com, extra information was attached to that response.
-
The resolver got at least one IP address for each name server.
-
We call that the glue!
-
So the resolver not only got the name of the authoritative name server, it also got the IP address.
-
Thus breaking the circular dependency.
-
Nice! I understand it now!
-
Glue records rock!
-
Yes, they do!
hahaha, thanks!
-
-
You made it through the end! Now is a good time to watch the video that we made for this comic!
-
Watch this short animation based on this comic. They finally have a voice!
Watch video