Understand which nameserver list does what
A domain’s registrar provides a place to request nameserver changes. The delegation that matters to DNS resolution, however, is published in the parent zone. For a domain under .com, that means the .com zone directs resolvers toward the domain’s nameservers. A registrar dashboard may show a submitted change before the parent zone reflects it, or it may display settings that need closer inspection.
The domain’s authoritative nameservers can also publish NS records for the domain itself. These child-side NS records should generally agree with the parent’s delegation, but they serve a different role. A mismatch does not automatically make the domain unreachable: a resolver first follows the parent delegation, then queries a nameserver it reaches. Still, disagreement can send queries to an old provider, produce inconsistent answers or make later changes harder to diagnose.
Check the parent delegation first
Start with the exact domain name and the nameservers you expect. To see the delegation path, a command such as dig +trace example.com NS can help. Replace example.com with the domain you are checking; the names and results in this article are illustrative. Look for the NS records returned by the parent zone, rather than treating the first answer from a normal DNS lookup as the delegation. If you know a parent-zone nameserver, you can also query it directly with dig @PARENT_SERVER example.com NS, substituting that server’s hostname.
Compare the parent’s list with the registrar’s nameserver setting, checking spelling and the full hostname of each server. If they differ, confirm that the intended change was saved in the registrar’s nameserver controls—not only in a DNS record editor. A record editor changes data at a DNS provider; it does not necessarily change which provider the parent delegates to. If the change was recent, allow for publication and caching before concluding that it failed. Recheck the parent delegation directly to see whether the change has appeared there.
Ask each delegated nameserver directly
Next, query every nameserver listed by the parent. For example, dig @ns1.example.net example.com SOA and dig @ns1.example.net example.com NS request the zone’s start-of-authority and child-side nameserver records. Repeat the queries for each delegated server, replacing the illustrative names. An authoritative response should identify the intended zone and provide consistent answers across the servers. A timeout, refusal or answer for the wrong zone deserves investigation.
Compare the child-side NS records with the parent list. If the parent points to a former DNS provider while the child lists a new one, resolvers may still reach the former provider. If the parent points to the new provider but its servers lack the zone, the handoff may be incomplete. Also compare a relevant website record, such as the domain’s A or AAAA record, on each server. Different answers can explain why visitors see different destinations, although a difference may also be intentional and should be checked against the intended configuration.
Check nameserver addresses and DNSSEC where relevant
A parent may need to publish address information, often called glue, when a delegated nameserver’s hostname is inside the domain it serves. For example, a delegation for example.com to ns1.example.com needs a way to reach ns1.example.com before the resolver can ask it for the zone. If such a server cannot be reached, check that its registered host address and its DNS address record are appropriate. A nameserver under another domain does not use glue for this delegation in the same way.
If ordinary DNS queries work when sent straight to an authoritative server but validating resolvers report failures, check DNSSEC as a separate possibility. A DS record at the parent that no longer matches the child zone’s signing configuration can prevent validation. Do not remove or replace DNSSEC records merely to test a guess; first confirm the intended DNSSEC setup with the DNS provider and registrar.
Make one correction, then verify the path
Before editing anything, note the parent NS records, each authoritative server’s responses and the settings shown by the registrar and DNS provider. That snapshot makes it easier to tell whether a change helped. If the parent delegation is wrong, update the registrar’s nameserver setting. If the parent is right but a delegated server is missing the zone or serving old records, correct the configuration with the DNS provider. If child-side NS records disagree, bring them into line with the intended delegation after confirming which provider should be authoritative.
After a change, repeat the parent and direct-authoritative queries. Finally, check through a normal recursive resolver to see what users may encounter. Recursive results can remain different for a while because they may use cached delegation or record data, so distinguish a lingering cached answer from a parent zone or authoritative server that is still incorrect. Following that order—parent, each delegated server, then recursive resolver—keeps the investigation focused on where the disagreement actually occurs.
