Pointing a Domain to Your Own ns1 and ns2 Won't Work Without Glue Records

A common assumption goes like this: you set ns1.example.com and ns2.example.com as nameservers in WHM, enter them at the registrar, and if the domain still doesn't resolve a few hours later, propagation is being slow. So you wait a day. Then two. The domain still doesn't resolve, because nothing was ever going to propagate. The parent zone has no idea where ns1.example.com lives, and no amount of waiting will teach it. The missing piece is a glue record. This article covers why glue exists, what WHM can and can't do about it, and how to check the registry yourself with dig before you write anything off as propagation.

Why waiting for propagation is the wrong diagnosis

Propagation is a real effect, but it comes from one specific thing: caching. When you change something, recursive resolvers that already cached the old answer keep serving it until the TTL (time to live) runs out. That explains a domain that still points to the old place for some visitors. It doesn't explain a domain that resolves for nobody, including resolvers that never cached anything about it. If a fresh resolver with an empty cache can't resolve your domain, caching isn't the problem. The delegation chain is broken somewhere, and with self-hosted nameservers the usual break is at the registry. Support desks see this pattern often. The customer is confident the setup is right because every screen they changed shows the right values. The screen they never touched is the one that matters.

The chicken-and-egg problem glue solves

To resolve a name, a resolver walks down from the root. The root servers send it to the .com servers. The .com servers reply with a referral: example.com is handled by ns1.example.com and ns2.example.com, go ask them. The resolver now needs the IP address of ns1.example.com. That hostname sits inside example.com, so its A record lives in the example.com zone. That zone is served by ns1.example.com, which is the server the resolver is trying to find. It's a loop: you need the zone to find the server, and you need the server to read the zone. Glue breaks the loop. A glue record is an A (or AAAA) record for the nameserver hostname, stored in the parent zone itself. The .com servers hand it out alongside the referral, in the ADDITIONAL section of the response. The resolver gets both the names of your nameservers and their addresses in one reply, so it never has to look inside a zone it can't reach yet. Glue is only required when the nameserver hostname sits inside the domain it serves. DNS calls this in-bailiwick. If example.com uses ns1.otherhost.net, there's no loop, because the resolver can look up otherhost.net separately. Glue for ns1.otherhost.net still has to exist, but it belongs to otherhost.net's registration, not to example.com's. At the registry level, glue is usually managed as a host object, which registrars tend to call child nameservers, registered nameservers, host records, or something close to that. The name varies, but the idea is the same. You tell the registry that ns1.example.com exists and has this IP, and the registry publishes that address in the TLD zone.

What WHM settings do and don't do

WHM lets you define the server's nameserver hostnames and, depending on the version, add A records for them. Those settings are useful. They decide which NS records go into zones created on that server, and they make sure the example.com zone on your server contains A records for ns1 and ns2. All of that lives on your server, though. WHM has no connection to the .com registry. It can't create a host object and it can't publish glue in the TLD zone. Those A records inside your own zone are exactly the ones a resolver can't reach until glue exists. The registrar side has two separate steps, and people often do only the second:

Register ns1.example.com and ns2.example.com as child nameservers under example.com, each with its server's IP address. This step creates the glue.
Set those hostnames as the nameservers for example.com and for any other domains that should use them. This step creates the delegation.

Registrars handle a missing step 1 differently. Some reject the nameserver change outright with an error saying the host doesn't exist. Others accept it and leave you with a delegation that points nowhere useful. Whichever happens, the fix is the same: register the hosts first, then delegate. It's also worth staging the zone on the new nameservers before you delegate, so resolvers find real records instead of an empty zone the moment the change goes live. That part is covered in Pre-populating DNS Records on New Nameservers Before Registrar Cutover.

Checking delegation and glue at the registry with dig

You don't have to trust any control panel here. You can ask the TLD servers directly what they publish. Start with a trace, which follows the delegation from the root the way a resolver does, without relying on any cache:

BASH

# Follow the delegation chain from the root servers down
dig +trace example.com

# Find the authoritative servers for a TLD other than .com/.net
dig org NS +short

If the trace reaches the .com servers, receives a referral to ns1.example.com, and then stalls or errors out, look closely at that referral. Querying one of the TLD servers directly shows the referral in full. For .com and .net, the servers are named a.gtld-servers.net through m.gtld-servers.net:

BASH

# Ask a .com TLD server what it publishes for the domain (read-only)
dig @a.gtld-servers.net example.com NS +norec

Illustrative output format (trimmed, using documentation IP ranges):

TEXT

;; 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   192.0.2.10
ns2.example.com.    172800  IN  A   198.51.100.20

Read it in two parts. The AUTHORITY section is the delegation, meaning which nameservers the registry says are in charge. The ADDITIONAL section is the glue. If AUTHORITY lists ns1.example.com and ns2.example.com but ADDITIONAL is empty or missing one of them, the glue was never registered for that host, and resolvers can't find it. Waiting won't change that answer. If the AUTHORITY section still shows your old nameservers, the delegation itself hasn't changed at the registry. That points back to the registrar order, not to anyone's cache. Registry changes typically show up on the TLD servers fairly quickly, so an old answer there long after the change usually means the change didn't go through. Once the glue looks right, check that it matches reality. Compare the IP in the ADDITIONAL section with the address your server really answers on, and query your nameserver directly by IP with something like dig @192.0.2.10 example.com SOA +norec. You should get an authoritative answer, shown by the aa flag in the header. If it times out, the problem is on the server side: the DNS service isn't running, it's bound to the wrong address, or a firewall is blocking port 53 over UDP or TCP. Glue can't fix that.

Mistakes that survive the first fix

Stale glue is the one that catches people months later. When the server moves to a new IP, the A records in your zone get updated, but the glue at the registry keeps the old address until someone changes it at the registrar. Resolvers that rely on the glue keep going to the old IP. Every domain delegated to those nameservers can be affected, not just example.com. Updating the child nameserver records belongs on any IP migration checklist. A mismatch between glue and the zone causes quieter trouble. If the registry says ns1 is at one address and your zone says another, different resolvers can end up with different answers depending on which source they trust and cache. Keep the two identical. Then there's redundancy. Registering ns1 and ns2 with the same IP, or with two IPs on the same server, satisfies the registry's usual requirement for at least two nameservers, but it gives you no real failover. If that machine goes down, both nameservers go down together. On a single VPS this is often a reasonable trade-off. Just make the choice knowingly, rather than assuming two hostnames mean two independent servers. Timing still matters after the fix. TLD referrals for .com typically carry long TTLs, so a resolver that cached a bad or old delegation may hold it for a while. That's the one part where waiting actually helps. It's a reason to confirm the registry data first, before you start counting hours.

A practical order of checks

When a domain on custom nameservers doesn't resolve, skip the propagation checker sites and ask the TLD servers directly. Run dig +trace to see where the chain breaks. Query the TLD server with +norec and confirm that the AUTHORITY section lists your nameservers and the ADDITIONAL section carries the right IPs for them. Then query your own nameserver by IP and look for an authoritative answer. If the glue is missing, register the child nameservers at the registrar. If it's wrong, correct it there too. If the registry data is right and your server answers properly, then caching is what you're waiting on, and now you know that for certain.