<

[Last Call] Learn how to a build a cloud-first strategyRegister Now

x

DNS Glue -- WHAT and WHY

Published on
9,728 Points
3,528 Views
2 Endorsements
Last Modified:
Approved
Daniel McAllister
Working in computing since 1987, and in IT since 2000, Dan McAllister is a Developer & Admin for the QMail Toaster project.
One of the most often confused topics in the area DNS is the idea of GLUE records. Specifically, what they are, when they are needed, when they are provided, and how they are created.

First, WHAT IS GLUE?
To understand GLUE, you must first understand that DNS is a top-down, recursive, distributed database. Thus, to resolve (on your own) the name host.example.com., you first contact one of the 13 top-level (root) DNS servers and ask about .com. The reply will tell you where to find .com's nameservers, so you'll choose one of those and ask about example.com. The result will tell you where example.com's nameservers are, so you'll choose one of those to ask about host.example.com, whereupon you finally get your reply: 10.0.0.10.

That's all well and good, until you look deeper and see that nameserver entries are NAMES, not IP addresses. So if the nameserver for example.com is dns.example.com, you're going to be stuck -- you can't query the nameserver dns.example.com for the name dns.example.com because its self-referencing. (The term in DNS, is circular.)

That is where GLUE comes in. GLUE is simply an IP address of a nameserver that is provided as "additional data" in the DNS reply from a parent server. So, when I query the .com server for example.com's nameservers, it will reply not just with dns.example.com, but also with the IP address of dns.example.com (10.0.0.100) in the "additional data" area of the response. Thus, I don't get caught in a loop, and I also save an additional query.

So, WHEN DO I NEED GLUE?
Specifically, any time a nameserver for a subdomain is within the parent's own domain, GLUE must be provided. However, it is also common for GLUE to be provided at other times -- lets look at an example to see:
 
Suppose example.com has 4 nameservers:
    dns.example.com
    dns.other.com
    dns.another.net
    dns.otro.es

In the first case, when we query the .com server for example.com, since the return value is dns.example.com (which is within our own domain), we MUST include GLUE -- the result otherwise would be circular.

In this case, the owner of example.com has to provide the GLUE data at their registrar (that is, I have to create a special entry at the registrar that says that the IP address of dns.example.com is 10.0.0.100 so that it can be included in queries for example.com).

In the second case, when we query the .com server for example.com, since the return value is dns.other.com, GLUE doesn't technically HAVE to be provided, but if you look at what comes next (a second query to the .com server for the NS entries for other.com) and realize that the data is therefore already available in that server, it makes sense that the TLD will preemptively provide the GLUE -- in fact, it will do so for any other .com name listed.

However, it is important to note that the owner of other.com has to have created their own GLUE record for that nameserver at their own registrar.

In the third case, when we query the .com server for example.com, since the return value is dns.another.net, the result is on another TLD -- BUT in this case, the same .com server (physical server) is also a .net TLD server (common for those particular TLDs), so GLUE is provided -- essentially as a convenience -- it is, after all, preventing a query to its .net service. This is similar to the second example, but the fact that GLUE is provided is almost accidental, and not guaranteed.

In the third case, when we query the .com server for example.com, since the return value is dns.otro.es, the result is on another TLD, and this time not one that the .com server just happens to also service. Thus, no GLUE can be provided and the querying client must now independently resolve the name starting with the .es TLD. More work for the client, but the data just isn't on the .com server to provide...
 
HOW DO I KNOW IF I NEED GLUE?
The technical answer is that if you're providing your own DNS service, you will need GLUE. But in practice, you can just specify your DNS servers at your registrar... if GLUE would be needed, and isn't already present, your registrar will tell you (it won't allow the entry).

So finally, HOW DO I CREATE GLUE?
GLUE entries must be made in the parent domain. In the examples shown here, I had to create a GLUE entry for dns.example.com in the .com server. To do that, I used tools at my registrar's site to create a host entry on the .com servers. Typically, you can only create host entries for the domain you are managing on that registrar.

However, if I had a sub-domain for example.com (sub1.example.com) that had DNS servers at ns.sub1.example.com, then I would have to make GLUE entries (they are just A records) in the example.com zone for ns.sub1.example.com. The values will be used as GLUE automatically by all major DNS server software packages.
2
Comment
1 Comment
 
LVL 32

Expert Comment

by:DrDamnit
Well written. Excellent. Useful.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Join & Write a Comment

this video summaries big data hadoop online training demo (http://onlineitguru.com/big-data-hadoop-online-training-placement.html) , and covers basics in big data hadoop .
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
Other articles by this author
Suggested Courses

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month