Why a Domain Can Stop Resolving After a DNS Move
Consider a migration to a new VPS: the server is running and branded nameservers are set at the registrar, but the domain still won’t resolve. If those nameservers live under the domain they serve, missing glue can create a circular lookup dependency. Resolvers need the nameservers’ addresses before they can ask them for the zone.
Ever had that moment when your domain won’t resolve after a move, and it feels like the whole web is ignoring you? The fix usually starts with understanding private nameservers and glue records. In this guide, I’ll walk you through what they are, why they matter, and exactly how to set them up without losing a day to DNS mysteries. We’ll go step by step, talk through real-world gotchas, and explain the checks needed to make sure things actually stick. If you’ve been meaning to finally “do it right” with your DNS and brand your own nameservers, this one’s for you.
Private Nameservers and Glue Records: The Story Behind the Jargon
Let’s keep this human. Private nameservers are just nameservers branded on your domain—think ns1.yourdomain.com and ns2.yourdomain.com—instead of using your host’s defaults. It’s tidy, professional, and helpful when you’re hosting multiple projects or acting as a reseller. You get a white-label identity; control over the DNS stack depends on whether you operate the service or use a provider’s branded nameservers.
Now, glue records. Here’s the thing: if your nameserver name lives under the very domain it serves—like ns1.yourdomain.com serving yourdomain.com—resolvers hit a chicken-and-egg problem. They ask the parent zone’s authoritative servers (the TLD servers in this example) “Where’s this domain’s nameserver?” and get the nameserver’s name back. But then they need to resolve that nameserver’s name to an IP, which… needs the zone itself to resolve. Oops.
Glue records are the fix. They’re little pieces of IP information the parent zone hangs onto saying: “By the way, ns1.yourdomain.com is at 203.0.113.10 and ns2.yourdomain.com is at 203.0.113.11.” That gets resolvers through the door without looping. These IPs are documentation examples; use your nameservers’ real public addresses. Think of glue like a handwritten note on the front desk telling couriers which elevator to take when the receptionist’s phone is down.
If you’re curious about the bigger map in the sky, the IANA root servers coordinate the very top of the DNS tree. But for your domain, the real magic happens at your registrar: you “register” your hostnames (ns1, ns2) and give them IPs. That’s glue.
What You Need Before You Start
For a self-hosted setup, you need a domain you own, registrar access, and servers with static public addresses running authoritative DNS for your zones. Provide IPv4 reachability; add IPv6 only where it works end to end. For resilience, use separate servers, ideally on different networks: a second IP on one server does not protect against server failure. Firewall access to allow UDP and TCP 53 is essential.
And just a quick note—reverse DNS (rDNS) on your server IPs is not required for glue or authority. It’s great for mail deliverability. Helpful, sure. Just not part of the glue story.
Step-by-Step: How to Set Up Private Nameservers and Glue Records
Let’s walk through the setup. Prepare and test the new authoritative service before changing delegation, even though the registrar change is described in Step 4. We’ll keep it platform-agnostic so the logic sticks no matter which panel or DNS software you use.
Step 1: Choose your names
Pick your branded hostnames, usually ns1.yourdomain.com and ns2.yourdomain.com. If your registrar and registry allow it, both names can temporarily use one IP, but that provides no redundancy. Two IPs on one server still share a failure point. For long-term sturdiness, I like true diversity: two IPs, two servers, ideally in different networks. But start simple if you need to.
Step 2: Assign IPs
Decide which IPs will power these nameservers. Typically that’s your server’s primary IPv4 and either a secondary IPv4 or an IP on a different machine. If you have IPv6, earmark v6 addresses too so you can add AAAA glue later. Jot them down. You’ll use them twice—once at your registrar and once in your DNS zone.
Step 3: Register glue at your registrar
This happens in a section often called “Host records,” “Child nameservers,” or “Register nameserver.” You’ll create ns1.yourdomain.com → IPv4/IPv6 and ns2.yourdomain.com → IPv4/IPv6. Save. Processing time depends on the registrar and registry; panel confirmation does not mean existing DNS caches have expired. If you haven’t seen this screen before, check your registrar’s docs or look up a vendor’s explanation like what a glue record is and why it exists. It’ll click fast once you see it laid out.
Step 4: Set your domain’s nameservers to your private pair
After completing Steps 5 and 6 and verifying authoritative answers directly from every new server, return to the registrar and switch the domain’s authoritative nameservers to ns1.yourdomain.com and ns2.yourdomain.com. This is the delegation change. Without it, resolvers following the parent delegation will still use the old nameservers. Keep the old service available with matching zone data until cached delegation and address records expire. If a parent DS record already exists, coordinate signing keys and signatures with both DNS operators before the change; a DS that does not authenticate the new zone can cause validation failures.
Step 5: Create the DNS zone on your server and add the right records
On each authoritative server, configure the zone for yourdomain.com, keeping its data synchronized. Include: (1) an SOA record and apex NS records pointing to ns1.yourdomain.com and ns2.yourdomain.com; (2) A records for ns1 and ns2, plus AAAA records only for working IPv6 addresses, matching the glue; (3) your existing service records—A/AAAA for the root domain, a record for www, MX for email, and any other required records. Keep the parent delegation and zone NS records consistent. Address mismatches can cause failures; a lame delegation specifically points to a server that is not authoritative for the zone.
Step 6: Check firewall and service
Before testing, confirm UDP 53 and TCP 53 are reachable externally on every published nameserver address. Allow public authoritative queries, but disable recursion for public clients. Some setups only open UDP and forget TCP, which bites you during large responses and DNSSEC. Before changing delegation, query each new server directly by its real public IP from another network. Check authoritative SOA and NS answers and compare all required service records with the existing zone. Repeat reachability checks over TCP as well as UDP. Also confirm your DNS daemon—BIND, PowerDNS, NSD, or your panel’s embedded service—is running and authoritative for the zone. If your logs say “not authoritative” for queries to your domain, re-check the zone config.
Step 7: Test resolution and delegation
Now run a quick trace from your local machine or a remote box. Something like dig +trace yourdomain.com follows iterative delegation—from root, to your TLD, down to your nameservers. A successful trace can help confirm that the lookup reaches an authoritative answer, but it does not validate every nameserver or necessarily display the parent’s glue addresses. Check the parent’s referral and its additional section directly when verifying glue. If the trace breaks in the middle, possible causes include missing glue, a wrong IP, or an unreachable server. For a browser-based view, use DNSViz to map the chain and highlight weak spots like missing A/AAAA for nameservers or DNSSEC issues.
Timing, TTLs, and Propagation Without Panic
A day or two before a move, lower relevant record TTLs in the old zone, allowing their previous TTLs to expire first. This shortens caching of those records, not the parent zone’s delegation or glue TTLs, which are generally outside your control. A rollback can still take time while cached delegation data expires. For more on timing, see: The TTL Playbook for Zero‑Downtime Migrations. It’s the calm way to handle DNS without refreshing your browser fifty times.
After you switch your domain’s nameservers to your private pair, remember there’s a separate propagation phase for the delegation itself. Caches at resolvers around the world hang on to the old NS set for a while. The transition lasts until the relevant cached delegation and address records expire; monitor both services instead of relying on a fixed propagation time.
Platform Notes: cPanel, Plesk, DirectAdmin, and Plain BIND
Each control panel wraps the same DNS fundamentals with slightly different buttons. In cPanel/WHM, look for “Basic WebHost Manager Setup” to set nameserver defaults. Use Configure Address Records to create matching A/AAAA records for your actual addresses; this does not allocate an IP to a network interface. WHM will also help you generate the A records for ns1/ns2 in your selected DNS zone. Even with that convenience, you still have to register glue at your registrar, which is the part many folks miss.
In Plesk, adjust the DNS Template so new domains pick up the right NS entries, then verify the A/AAAA records for ns1/ns2 exist under the main zone. The DNS service available in Plesk depends on the platform and installed components; make sure it’s listening on the correct IPs and that your firewall permits inbound UDP and TCP 53. Confirm authority by querying each intended server directly and checking its zone answer; DNS service logs can then help investigate a failed query.
With DirectAdmin, nameserver defaults can be set at the relevant admin or reseller level, while per-domain DNS zones carry the actual NS/A/AAAA records. Registrar glue registration is required when the nameserver hostnames are inside the domain being delegated, so the parent can supply their IP addresses without a circular lookup.
If you’re running BIND or PowerDNS by hand, the flow is the same: create the zone with NS records pointing at your ns1/ns2 hostnames, add A/AAAA for those hostnames, and double-check the SOA and serials. Plan relevant record TTLs before the transition and raise them after verification if the expected rate of change permits. This does not control parent delegation or glue TTLs.
IPv6, DNSSEC, and Other Grown‑Up Details
IPv6 isn’t mandatory for glue. If your server has reliable v6 connectivity, check that your registrar supports IPv6 glue before adding AAAA glue alongside your A glue. Then add the corresponding AAAA records for ns1/ns2 in your zone; those zone records do not replace parent-zone glue. Verify authoritative DNS reachability over both UDP and TCP 53 at every published IPv6 address before relying on it.
DNSSEC is separate from glue, but they play in the same arena. Glue gets queries to your nameserver; DNSSEC lets resolvers verify the authenticity of your answers. If you enable DNSSEC, sign the zone and confirm that all authoritative servers serve its DNSKEY records and valid signatures before submitting the matching DS records through your registrar for publication in the parent zone. For a newly signed domain, establish working delegation and authoritative service before activating DNSSEC. For an already signed domain, preserve or coordinate the existing chain of trust during migration; do not treat it as a new, unsigned setup.
Troubleshooting: The Usual Suspects
Start troubleshooting with a chain check. First, dig NS yourdomain.com +trace and watch whether the TLD returns your custom nameservers and their IPs. Missing IPs in the displayed trace alone do not prove glue is absent; check the parent’s referral and its additional section directly. Glue is needed to break the loop for nameservers inside the delegated domain. If the published IPs are correct but the server is unreachable, check routing, the firewall, and the DNS listener. If a direct query to an intended authoritative server lacks the AA flag, check that the correct zone is loaded and available to that client; check the parent delegation separately.
A few “gotchas” to double-check: (1) Did you put A/AAAA records for ns1 and ns2 inside your zone? The glue is just at the parent; your zone must also define these hostnames. (2) Did you change the domain’s nameservers to your private pair? You’d be surprised how often people register glue and forget the delegation. (3) Are you blocking TCP 53? Responses that exceed the usable UDP size, including some DNSSEC responses, need TCP fallback. (4) Are you editing the right zone file? In panel-based clusters, there can be multiple DNS servers. (5) Did you set very long TTLs right before the move? That can make it feel like nothing is happening, even if everything is correct.
If you want a second opinion beyond your terminal, plug your domain into DNSViz. It’s good at spotting missing records, DS mismatches, and overall delegation health. For related DNS terminology, Cloudflare’s DNS glossary is another reference.
Operational Tips: Keeping Your Private Nameservers Happy
Treat live nameservers as foundational infrastructure. Keep them monitored. If you’re running a single box for both ns1 and ns2, plan a second machine when you can; you don’t want a single maintenance reboot to interrupt lookups that cannot be answered from cache. Keep software updated—BIND, PowerDNS, panel patches—because DNS is a favorite playground for the internet’s curious minds.
Think about your zone’s TTLs. For a stable, rarely changing domain, higher TTLs reduce query load and slightly improve perceived responsiveness. For fast-moving apps or frequent migrations, lower TTLs give you agility. If you’re new to that balancing act, the guide to TTL strategies for zero‑downtime moves explains cache timing and transition planning. Short TTLs do not make delegation changes instant.
A final thought: private nameservers are about brand and control. If running DNS starts to feel like the tail wagging the dog, it’s okay to use a managed DNS service that explicitly supports branded nameservers. Follow that provider’s setup requirements for hostnames, glue, and delegation rather than simply pointing your ns hostnames at arbitrary provider IPs. The goal is predictability. You want to be the person who shrugs at DNS changes and says, “Give it a minute, it’ll land.”
A Quick Reality Check: When It Doesn’t Work the First Time
A domain may still resolve through its old nameservers at some resolvers after a delegation change because the previous NS set remains cached. Keep the old DNS service available during the transition and update its website A/AAAA records to the new web server addresses as needed. Already-cached address records still need time to expire. Delegation TTLs are generally controlled by the parent zone, not by your zone’s TTL settings.
That’s the vibe to keep with DNS. Do clean work. Test. Give caches time. Validate with trace and a visualizer. If something feels inconsistent, it’s usually caching, a missing A/AAAA for your nameserver hostnames, or glue not being registered exactly as your DNS zone expects.
Wrap‑Up: Your Nameservers, Your Rules
Private nameservers identify your DNS service under your own domain. For in-bailiwick nameservers, parent-zone glue supplies their addresses to break the lookup dependency. Prepare synchronized authoritative zones, verify all required service records and test both servers over UDP and TCP before changing delegation. Coordinate any existing DNSSEC chain and retain the old DNS service while cached delegation and address records expire.
If you remember just a few things, let them be these: keep your firewall open on UDP and TCP 53; confirm your zone has A/AAAA for the nameserver hostnames; test with dig +trace; and let TTLs work in your favor by planning ahead. Plan a second server on independent infrastructure for resilience rather than treating redundancy as polish. Add IPv6 glue only when IPv6 DNS service works. For a newly signed domain, establish working delegation and authoritative service before activating DNSSEC; for an already signed domain, coordinate the existing chain of trust throughout the migration.
Hope this was helpful! If you’re setting this up today and hit a snag, breathe, trace the path, and check the glue. See you in the next post—where we’ll take this foundation and build something fast, resilient, and a little bit fun.
