To check your domain delegation, compare the nameserver (NS) records the parent TLD hands out with the NS records your own nameservers return, then confirm every one of those nameservers actually answers for the zone. When the parent set and the child set match and all servers respond with the same authoritative data, delegation is healthy. When they disagree, you have a lame or broken delegation that can cause intermittent resolution failures. This guide walks through the exact checks, from the top-level domain down to each nameserver, so you can confirm your delegation in a few minutes.
What domain delegation actually means
Delegation is how the DNS hands responsibility for your zone down the tree. The root servers point to the TLD (for example .com), the TLD stores NS records that point to your authoritative nameservers, and your nameservers hold the real records for your domain. Two separate copies of your NS set exist: the parent copy stored at the registry (the glue and delegation records your registrar publishes) and the child copy stored in your own zone. A correct delegation keeps those two copies in agreement.
If you want the conceptual walkthrough of that root-to-nameserver chain, the guide on tracing DNS delegation from the root to your nameservers covers each hop in detail. This page is the task-focused version: how to actually verify your own delegation right now.
Parent NS versus child NS: what you are comparing
The single most useful check is comparing the parent and child nameserver sets. Here is how the two sources differ and what each one tells you.
| Attribute | Parent NS (at the TLD registry) | Child NS (in your zone) |
|---|---|---|
| Who publishes it | Your registrar, pushed to the registry | Your DNS host, in the zone file |
| How to query it | Ask a TLD server directly (no recursion) | Ask your authoritative nameserver |
| Purpose | Tells resolvers where to go next | Confirms the zone agrees it is authoritative |
| Common failure | Old nameserver left in place after a move | A listed NS that no longer serves the zone |
| Includes glue | Yes, when nameservers are in-domain | Not applicable |
When the parent lists four nameservers but the child lists only three, or the hostnames differ, resolvers may cache a server that does not answer. That mismatch is the root cause of most slow or flaky lookups that come and go depending on which nameserver a resolver happened to pick.
How to check your delegation step by step
- List the parent NS records. Query a TLD nameserver for your domain and read the NS records it returns. This is the delegation as the rest of the internet sees it.
- List the child NS records. Query one of your own authoritative nameservers for the NS record set of your domain. Note the hostnames exactly.
- Compare the two sets. They should contain the same hostnames, with no extras on either side. Order does not matter, but membership does.
- Resolve every nameserver to an IP. Each hostname must resolve to a reachable address. A nameserver that no longer exists is a dead delegation.
- Query each nameserver individually. Ask every server for your SOA record. All of them must answer authoritatively and return the same serial number.
- Check glue if your nameservers are in-domain. If your nameservers live under the domain they serve (for example ns1.yourdomain.com), the registry must publish glue A/AAAA records so resolvers can find them without a chicken-and-egg loop.
You can run all of these checks from one place with the Valla DNS lookup tool, which queries authoritative servers for you, or with the nameserver trace tool that walks the delegation from the root down.
Reading the results: healthy versus broken
A healthy delegation looks boring in the best way. Parent and child NS sets match, every nameserver resolves, every nameserver answers authoritatively, and the SOA serials line up. Nothing stands out.
A broken delegation shows one or more of these signals. A nameserver appears in the parent set but times out. The child set is missing a server the parent still advertises. One nameserver returns a different SOA serial, meaning a zone transfer has not completed. Or a server answers without the authoritative flag, which is the classic signature of a lame delegation. Any of these is worth fixing even if the domain still resolves most of the time, because resolvers choose nameservers unpredictably and users will hit the bad one eventually.
Common delegation problems and how to fix them
Most delegation faults trace back to a nameserver change that was only half finished. After moving DNS hosts, people often update the child zone but forget to update the NS records at the registrar, or vice versa. The fix is always to make the parent and child sets identical and remove any server that no longer serves the zone.
Glue mistakes are the second common cause. If you renamed or re-IPed an in-domain nameserver, update the glue records at your registrar, not just the zone. Stale glue sends resolvers to an address that no longer answers. Finally, watch TTLs: delegation NS records often carry a one or two day TTL, so a correct change can still look broken from cached resolvers until the old records expire.
Frequently asked questions
How do I check domain delegation without any command line tools?
Use a web-based lookup that queries authoritative servers directly. The Valla DNS lookup returns your NS records and lets you compare what the parent and your own nameservers report, with no software to install and nothing to configure.
What is the difference between parent and child nameservers?
The parent nameservers are the NS records stored at the TLD registry by your registrar, telling resolvers where your zone lives. The child nameservers are the NS records stored inside your own zone. A healthy delegation keeps both sets identical.
Why does my domain resolve sometimes but not always?
Intermittent resolution usually means one of your listed nameservers is not answering correctly while the others are. Resolvers pick a nameserver more or less at random, so when they land on the bad one the lookup fails. Checking that every nameserver answers authoritatively uncovers this.
What is a lame delegation?
A lame delegation is when a nameserver is listed for your domain but does not actually serve the zone authoritatively. It may time out, refuse the query, or answer without the authoritative flag. It slows resolution and should be removed or corrected.
How long does a delegation change take to go live?
Delegation NS records commonly carry a TTL of one to two days, so resolvers that cached the old set will keep using it until that TTL expires. Expect up to 48 hours for a change to be fully visible everywhere, even though many resolvers update much sooner.
Ready to confirm your own setup? Run your domain through the Valla DNS lookup tool and compare the parent and child nameserver sets in one pass.