Glue Records: When Your NS Lives in Your Zone
4 min read
## The Chicken-and-Egg Problem
Imagine you own `example.com` and you want to run your own nameservers at `ns1.example.com` and `ns2.example.com`. You tell your registrar: "Use ns1.example.com and ns2.example.com as my nameservers." The registrar publishes this in the `.com` TLD zone as a delegation:
```
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
```
Now a resolver tries to find the IP for `www.example.com`:
1. Asks the root zone: "Who is authoritative for `.com`?"
2. Gets referred to the `.com` TLD servers
3. Asks a `.com` TLD server: "Who is authoritative for `example.com`?"
4. Gets: "ns1.example.com and ns2.example.com"
5. Now needs to resolve `ns1.example.com`... which requires asking `example.com`'s authoritative server... which is ns1.example.com... which it cannot reach because it does not know the IP.
This circular dependency is the classic DNS chicken-and-egg problem. The answer is Glue Record records.
## What Glue Records Are
Glue records are A (and AAAA) records for nameserver hostnames that are included in the **parent zone's** delegation response, alongside the NS records. They break the circularity by providing the IP address of the nameserver without requiring the child zone to be queried first.
The TLD zone for `.com` contains:
```
; Delegation NS records
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.
; Glue records (A records for the nameservers within the zone)
ns1.example.com. 172800 IN A 203.0.113.53
ns2.example.com. 172800 IN A 203.0.113.54
```
Now when the resolver gets the referral to `example.com`, the response includes the IP addresses of `ns1.example.com` and `ns2.example.com` as additional records. No circular lookup needed.
## When Glue Is Required vs. Optional
Glue is only required when the nameserver hostname is **within the zone being delegated**. If your nameservers are at a different domain, no glue is needed:
| Nameserver | Zone | Glue Required? |
|---|---|---|
| `ns1.example.com` | `example.com` | Yes — circular |
| `ns1.nameservice.net` | `example.com` | No — resolved independently |
| `ns1.sub.example.com` | `sub.example.com` | Yes — still circular |
| `ns1.sub.example.com` | `example.com` | Yes — within zone |
When nameservers are hosted at a third-party provider (Cloudflare, AWS Route 53, etc.), their nameserver hostnames are typically in the provider's own domain (e.g., `mia.ns.cloudflare.com` for the `cloudflare.com` zone). Cloudflare maintains glue for those hostnames. No glue is needed in your zone.
## How to Submit Glue Records
Glue records are registered at the **registry** level through your registrar's control panel or EPP system. This is separate from your zone file. The zone file within your zone also needs A records for the nameserver hostnames, but the authoritative glue lives at the TLD registry.
Most registrar control panels have a "Host Records" or "Register Nameserver" section distinct from the DNS editor. Workflow:
1. Log into your registrar
2. Find "Nameserver registration" or "Host records"
3. Register `ns1.example.com` with IP `203.0.113.53`
4. Register `ns2.example.com` with IP `203.0.113.54`
5. Then set your domain's nameservers to `ns1.example.com` and `ns2.example.com`
Steps 3-4 must happen before step 5, or the delegation will be broken immediately.
## Verifying Glue at the Registry
To check the glue records at the TLD level, query the TLD nameservers directly with the `+additional` flag:
```bash
# Check glue for example.com at the .com TLD servers
dig NS example.com @a.gtld-servers.net +additional
# This returns the NS records AND the glue (in ADDITIONAL SECTION)
# AUTHORITY SECTION:
# example.com. 172800 IN NS ns1.example.com.
# example.com. 172800 IN NS ns2.example.com.
# ADDITIONAL SECTION:
# ns1.example.com. 172800 IN A 203.0.113.53
# ns2.example.com. 172800 IN A 203.0.113.54
# If glue is MISSING, ADDITIONAL SECTION will be empty
```
You can also check with RDAP (Registration Data Access Protocol) — query the domain and look at the nameserver objects. They should include IP address data if glue is present.
```bash
curl https://rdap.verisign.com/com/v1/nameserver/ns1.example.com | jq .
```
## Updating Glue After an IP Change
If you change the IP address of your nameserver, you must update the glue at the registry as well as the A record in your zone file. Updating only the zone file leaves stale glue in the TLD zone, causing resolution failures for anyone who cold-resolves your domain (no cache) and follows the stale delegation.
The safe update procedure:
1. Update the A record in your zone file. Set TTL (Time To Live) very low (60 seconds) beforehand.
2. Wait for TTL to expire across the resolver network (at least the old TTL duration)
3. Update the glue record at the registry (via registrar control panel or EPP)
4. Wait for the TLD zone to propagate (usually minutes)
5. Restore TTL to normal
Failing to update glue is one of the most common causes of mysterious DNS resolution failures after server migrations.
## DNSSEC and Glue
When DNSSEC is enabled, glue records are not directly signed in the parent zone (they appear in the Additional section, which is not signed). However, the NS Record delegation is signed, and the child zone's DNSKEY/RRSIG chain validates the content of the nameserver records once the resolver can reach them. The glue records themselves are treated as hints and should be verified once the authoritative zone is queried. See DNSSEC Deep Dive: Signing, Validation, and Troubleshooting for the chain of trust that validates the full delegation. For zone file structure including how glue A Record entries appear in both the parent and child zones, see Zone Files: Structure and Management.
DNS Record Helper