What is a glue record?

A glue record is a term for a record that's served by a DNS server that's not authoritative for the zone, to avoid a condition of impossible dependencies for a DNS zone.

Say I own a DNS zone for example.com. I want to have DNS servers that're hosting the authoritative zone for this domain so that I can actually use it - adding records for the root of the domain, www, mail, etc. So, I put the name servers in the registration to delegate to them - those are always names, so we'll put in ns1.example.com and ns2.example.com.

There's the trick. The TLD's servers will delegate to the DNS servers in the whois record - but they're within example.com. They try to find ns1.example.com, ask the .com servers, and get referred back to... ns1.example.com.

What glue records do is to allow the TLD's servers to send extra information in their response to the query for the example.com zone - to send the IP address that's configured for the name servers, too. It's not authoritative, but it's a pointer to the authoritative servers, allowing for the loop to be resolved.

I requested that this answer be merged in from a duplicate question, as the existing answers did not explain the role of the ADDITIONAL section.

To see how it works, type this: dig +trace +additional google.com SOA

This will trace the nameserver authority starting from the root servers (+trace). Adding +additional will also show you the ADDITIONAL section of each DNS server response. Normally most people think of DNS in terms of the QUESTION and the ANSWER sections, but ADDITIONAL also plays an important role: if the nameserver knows the answers to any queries that are related to the answer, it can pre-emptively supply those answers in the ADDITIONAL section without requiring additional queries from your client.

Note that the authoritative nameservers for google.com are rooted under the domain they're authoritative for. (ns1.google.com, ns2.google.com, etc.)

When you ask a nameserver to supply the list of nameservers for a domain, they will often supply a list of A-type records (IP addresses) in the ADDITIONAL section, not just the NS-type answers: these are called glue records, used to prevent circular dependencies. In this case, those A records are served from the TLD (.com, .org, etc.) nameservers based on the IP addresses that someone supplied the DNS registrar responsible for the domain. They can usually be changed by logging into the admin web interface they supply you.

(disclaimer: AAAA records containing IPV6 addresses can also be supplied as part of the glue, but I left this out for simplicity's sake.)

After searching forever and reading a lot about glue records and still not understanding what they were or how you can make them I finally found an answer and it's a very simple one.

As I understand there is no magic extra information sent from somewhere, this is how it works.

Lets say your domain is example.com and you want to use your own name servers ns1.example.com and ns2.example.com, you need at least two DNS servers.

• ns1.example.com has IP 192.0.2.10
• ns2.example.com has IP 192.0.2.20

In order for this to work now you need the top domain owner to put following records into their DNS.

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

Those two A records are the glue records and they need to be at the top domain, in this case .com, and not all registrars can get this done for you.

If this is wrong please correct me. I just thought I try explain in a simple way for others who can't find correct answer.

There is a precise (and concise) explanation on wikipedia.
To quote:

Circular dependencies and glue records

Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred.
If the name given in the delegation is a subdomain of the domain for which the delegation is being provided, there is a circular dependency. In this case the nameserver providing the delegation must also provide one or more IP addresses for the authoritative nameserver mentioned in the delegation. This information is called glue.

. . .

For example, if the authoritative name server for example.org is ns1.example.org, a computer trying to resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in example.org, this requires resolving example.org first, which presents a circular dependency.
To break the dependency, the nameserver for the org top level domain includes glue along with the delegation for example.org. The glue records are address records that provide IP addresses for ns1.example.org. The resolver uses one or more of these IP addresses to query one of domain's authoritative servers, which allows it to complete the DNS query.

Well, those are three questions:

1. What exactly (but briefly) is a DNS glue record?
2. Why are they needed and
3. how do they work?

The brief answer to the first question likely will make little sense without context, given by a somewhat long-winded answer to the later two questions. Here, then, is an alternative explanation with historic references to the RFCs to give some context to the terminology, especially:
RFC 822 "Standard for the Format of ARPA Internet Text Messages" 1982, https://www.rfc-editor.org/rfc/rfc822.html, now obsoleted by;
RFC 5322 "Internet Message Format" 2008, https://www.rfc-editor.org/rfc/rfc5322 ;
RFC 882 "Domain Names - Concepts and Facilities" 1983, https://www.rfc-editor.org/rfc/rfc882, which precedes and is obsoleted by;
RFC 1034 "Domain Names - Concepts and Facilities" 1987, https://www.rfc-editor.org/rfc/rfc1034, and;
RFC 1035 "Domain Names - Implementation and Specification" 1987, https://www.rfc-editor.org/rfc/rfc1035 ; the intervening
RFC 952 "DoD Internet Host Table Specification" 1985, https://www.rfc-editor.org/rfc/rfc952.html ;
RFC 1123 "Requirements for Internet Hosts -- Application and Support" 1989, https://www.rfc-editor.org/rfc/rfc1123.html, especially;
RFC 2181 "Clarifications to the DNS Specification" 1997, https://www.rfc-editor.org/rfc/rfc2181, and;
RFC 2535 "Domain Name System Security Extensions" 1999, https://www.rfc-editor.org/rfc/rfc2535.

Now, briefly, to the first question: A DNS "glue record" is a colloquial term - not defined in an RFC - for a type of DNS IP Address Resource Record, an "A" record or "AAAA" record. An IP Address record is also a "glue record" when that IP Address record gives an address which links a path to the public secondary DNS Protocol server of a delegated "child zone"/"domain name", where, in particular, that public secondary DNS Protocol server "domain name" for that delegated "child zone" is also in, and immediately under the authority within, that child zone. And here - since I have not found this explicitly stated in an RFC - the Network Administrator is simply expected to infer that, when the delegated "child zone" is also in, and immediately under the authority within, that child zone, then the parent zone must also provide one or more IP Address records which, in the end, link to the child zone authoritative DNS Protocol servers. "Glue records" are all about the interplay of "authoritative" and "nonauthoritative" servers, where, by design, a "parent zone" is not authoritative for a "child zone".

And then, there is a caveat, raised at What is the difference between the NS records and the glue records?, by Ladadadada, that there is an uncertainty in practice, perhaps not quite clarified in the RFCs, as to whether any particular DNS Protocol client will, or will not, follow a path and then verify that a linked child zone DNS Protocol server is also the authoritative server for that child zone, effectively verifying that the IP Addresses do match. The possibility exists that a "glue record" IP Address may lead to an authoritative server with a "Name Server" resource record leading to a different, thus inconsistent, IP Address for one or more authoritative DNS Protocol servers for that child zone. Maybe the server address is verified. Maybe the server address is not verified, and the IP Address is out-of-date, and maybe this server's zone file is also "half-way" out-of-date, with the correct "Name Server" records, but serving out-of-date or otherwise wrong answers for other resources. Of course, this circumstance implies DNS administrative errors, so it is just a caveat. This "shouldn't" happen in practice.

Answers through the RFCs to the later two questions become complicated when "common knowledge" is expected from the reader and "overloaded" terminology is often used, where, in practice, in common usage, the same term is used in reference to two, sometimes more, different things or different abstractions. Another thing to recognize here is the early association in the development of Internet Messaging and the Domain Name System and then the way this association influenced the use of Internet Messaging terminology in the Domain Name System RFCs, as "common knowledge", for those times.

In particular, this leads to very inconsistent use of the term "domain name" in the various RFCs, a term which, in different contexts, might refer to either:

1. A "host domain name", or
2. A "subzone domain name".

These terms may be inferred historically from the RFCs. As "common knowledge", a "host" itself is both 1) a machine with a physical network interface, and 2) an Operating System IP "socket" interface to which an IP Address has been assigned. The "host domain name" term comes from RFC 1123, which uses the term explicitly.

The term "subzone domain name" may be inferred from across several RFCs. We see "domain name" of a "child domain", as originally in RFC 822, or "child zone" later in RFC 2181, or "subzone", a "subzone domain name", as implied in other RFCs, especially RFC 1035 and RFC 2535.

These "domain names" are two very different things, both of which may be used either as:

1. values for "an owner name" in a DNS Protocol Data Packet and the left-hand side "owner" of a "Master File" or "zone file" resource record, or also as
2. the RDATA "cononical name" value in an NS, MX, or CNAME resource record, or as the MNAME "cononical name" in an SOA resource record, in a data packet and on the right-hand side of a zone file, as in RFC 1034 and RFC 1035.

Especially in the early RFC 952, we see that these two different concepts of "domain" are simply "lumped together":

GRAMMATICAL HOST TABLE SPECIFICATION

  A. Parsing grammar
  ...
     <domainname> ::= <hname>
     <official hostname> ::= <hname>

Another likely area of confusion is the "NS Resource Record", which also has two very different meanings, depending upon context. We may read from RFC 2181, Section 6.1, below https://www.rfc-editor.org/rfc/rfc2181#section-6 :

6.1. Zone authority
The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone.

and note particularly the phrase "NS records ... are the mandatory records in every zone" and additionally note:

Other than the DNSSEC cases mentioned immediately below, servers should ignore data other than NS records, and necessary A records to locate the servers listed in the NS records, that may happen to be configured in a zone at a zone cut.

At the same time, though, we also read in the preceding Section 6:

... The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. A child zone does not contain any explicit reference to its parent.

So the reader is left to infer, on their own, that there exist two very different classes of NS Resource Record in a zone file:

1. those mandatory records having the exact same "label" as the zone "origin" domain itself, giving the "host domain names" of the self-descriptive authoritative public secondary DNS Protocol servers. They refer to this zone and are authoritative. And
2. those optional records having labels not exactly matching the zone origin domain and thereby specifying the, now extended, child zone origin domains and linking a path to the public secondary DNS Protocol server names for the child zone. They refer to some other zone and are not authoritative. These records are only a "best guess", remembering particularly that this parent zone cannot be authoritative for the child zone.

We should take a moment here and realize that this second class of NS records may then also require the inclusion of corresponding Address records, as "glue records", when the delegated "child zone" is also in, and immediately under the authority within, that child zone, as previously discussed. We should also realize that these exact same NS records, and their associated "glue records", are required to be included - it might be supposed "included redundantly" - in the zone file of the child zone, for the "subzone domain name", as the authoritative expression of the subzone domain's public secondary DNS Protocol servers, and their IP addresses. Again, remember, the "parent" zone is never authoritative for the "child" zone, even if the parent zone file includes and has already provided the exact same information - never for the child zone's NS records, and never for any other kind of child zone resource record.

So now to the second question, "Why are glue records needed?", we should first say that, strictly speaking, glue records are not needed, not at all, provided that:

1. The zone file does not describe any kind of child "zone domain name" involving NS records of the previously described second class, or
2. The zone file does include NS records describing a child "zone domain name", yet also, the public secondary DNS Protocol servers for the child zone are not in and immediately under the authority within that child zone.

Unless a network administrator is configuring some large organization needing delegated subdomains, with their own self-administered DNS Protocol servers, there is no need for any "glue record". And even then, a large organization might very well prudently distribute its DNS Protocol servers outside of any delegated subdomain, again, possibly avoiding any need for "glue records" if those server addresses will already be resolved elsewhere, perhaps by some outside provider.

"Glue records" are more likely something needed with a "vanity" domain, or with a small organization that wants to administer both its own DNS Protocol servers, and the zone file used by the organization's upstream DNS provider, likely their DNS Registrar. And even then, most likely, only the Registrar's zone file will have "glue records" linking to their customer's own DNS Protocol servers, which likely are not also being used by the customer to delegate subzone domain names.

But, as will be addressed in the upcoming answer to the third question, "how do they work" - "why" is a little more complicated. Operation of the DNS implies following a path through a hierarchy of domain components, as discussed in RFC 882, under "Name space specifications and terminology", which ultimately requires a "bridging" IP Address, from a nonauthoritatve server to an authoritative server, at every "zone cut". Unless confined to the "root" zone, there are always zone cuts along the path to a desired target "domain name". The "glue records" provide that "bridging" across zone cuts.

It should be mentioned here, for historical context, the transitive mechanism of the NS record and the Address record. Note that the NS record holds a "subzone domain name", the "owner", on the left-hand side of the resource record, and a "host domain name", the RDATA "canonical name", on the right-hand side. There is no IP Address here - yet. Why is that? We can refer back to "common knowledge", from the now obsolete RFC 822, at Section 6.2.3, under https://www.rfc-editor.org/rfc/rfc822.html#section-6.2, which prominently states:

6.2.3. DOMAIN TERMS
A domain-ref must be THE official name of a registry, network, or host. It is a symbolic reference, within a name sub-domain. At times, it is necessary to bypass standard mechanisms for resolving such references, using more primitive information, such as a network host address rather than its associated host name.
...
Domain-literals which refer to domains within the ARPA Internet specify 32-bit Internet addresses, in four 8-bit fields noted in decimal, as described in Request for Comments #820, "Assigned Numbers." For example:
[10.0.3.19]

Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
       is  permitted  only  as  a means of bypassing temporary
       system limitations, such as name tables which  are  not
       complete.

Or, to paraphrase, a "domain name" is generally not an IP Address. Thus, the RDATA of the NS record is a "domain name", not an IP Address, and a separate Address record associates this NS RDATA "domain name" with the "ARPA Internet specific" resource record RDATA, the actual IP Address. And then, consequently, the Address record, in this context, might also be called a "glue record", and the NS record is not. This second class of NS record is always needed to mark a "zone cut" in a parent zone, but the associated Address record is maybe needed, or maybe not needed, as discussed.

There is one other note on terminology here, with respect to the SOA resource record and the distinction of "primary" DNS Protocol server and "public secondary" server. In RFC 1035, Section 3.3.13 "SOA RDATA format", at https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13, there is:

MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

SOA records cause no additional section processing.

Take note of the past-tense, "was the original or primary source". Again, we should take a moment here and realize that, very commonly, none of the public DNS Protocol servers are necessarily also the primary server for the zone, and also, that the "primary source of data for this zone" need not even be publicly accessible. While it is common that the primary server is publicly accessible, that is not required. And while it is also possible that the primary server is the public and only server for the zone, it is preferable to have redundant servers. To ease administration of multiple servers, a single primary server, may make a "zone transfer" or "Authoritative Transfer", "AXFR", to a group of secondary servers. To be pedantic, then, the "primary" server is specified in the SOA record MNAME, and consequently, the servers specified in the RDATA of the required first class of NS resource records are "public secondary" servers. Still, it may be that the SOA MNAME and an NS RDATA name also refer to the the same server.

Finally, as to the third question, "How do glue records work?", it is useful to reflect upon the implied operation of the DNS Protocol in exchanges between the client and various servers, discussed in RFC 1034, especially Section 5 "Resolvers", under https://www.rfc-editor.org/rfc/rfc1034.html#section-5, and RFC 1035, Section 7 "Resolver Implementation", generally, and particularly noting Section 7.2, under https://www.rfc-editor.org/rfc/rfc1035#section-7.2 :

Some fine points:

The resolver may encounter a situation where no addresses are available for any of the name servers named in SLIST, and where the servers in the list are precisely those which would normally be used to look up their own addresses. This situation typically occurs when the glue address RRs have a smaller TTL than the NS RRs marking delegation, or when the resolver caches the result of a NS search. The resolver should detect this condition and restart the search at the next ancestor zone, or alternatively at the root.

The client engages in a sequence of queries, working its way through the domain name hierarchy, mostly resolving subdomain components to IP Addresses, typically finding first a "root" server "domain name", then its IP Address, then a "global top level domain" server "domain name", then its IP Address, then a third level "domain name", a "subzone domain name" being delegated by the, at this point, parent global top level domain, and searching for the IP Address for this zone's DNS Protocol server. The server for the global top level domain will authoritatively provide a "zone cut", specifying a "subzone domain name". And then the client will want an IP Address for this third level "subzone domain name" DNS Protocol server. However, as discussed, in every "cut", following the domain name hierarchy, the "parent" zone is not the authoritative source for the IP address of the DNS Protocol server for the "child" zone, by design. Still, the client needs an IP Address - where from?

It may be possible for the client to begin following another path through the domain name hierarchy, searching for this IP Address, which only ends when the client identifies the server with the "Source of Authority" for the IP Address of the DNS Protocol server specified for this child subzone domain name, and any other record sought. But regardless, at every "cut", from zone to subzone, the client must have a "bridge" from a nonauthoritative source for a server IP Address, to an "authoritative" source for this IP Address. That is why a "glue record" may be referred to as only a "hint" about a server's IP Address. The parent zone server offers a "best guess", a "suggestion", redirecting the client from the current server to the "next" server, continuing the client's search for a server with the "Source of Authority" to finally declare authoritatively that this IP Address is the IP Address of the "host domain name" DNS Protocol server for the target "subzone domain name".

The "glue records" provide that IP Address "bridge" from nonauthoritative source server to, eventually, an authoritative source server. Whether the client bothers to verify that the current server's IP Address actually matches an authoritative DNS Name Server IP Address for the target "subzone domain name" is at the discretion of the client. Hope for the best - or do confirm it manually. It might be possible to completely leave out listing the first class of self-descriptive authoritative NS records from the zone file, and still provide the client with any other resource record - as long as the client just "hopes for the best" and doesn't actually check for the NS records and their associated Address records.

See also RFC 8499 "DNS Terminology" 2019, https://www.rfc-editor.org/rfc/rfc8499.html.