DNS Delegation Explained: How Parent and Child Zones Work

DNS delegation is how authority for part of the DNS name hierarchy is assigned to another set of nameservers. A domain registrar usually controls the nameserver delegation submitted to the registry, while a DNS hosting provider serves the zone records referenced by that delegation. These are related but separate responsibilities. The registrar does not necessarily host the A, MX, or TXT records, and the DNS provider cannot change the parent delegation unless it also manages the registrar-side settings. When records changed in a dashboard do not appear publicly, an incorrect or unexpected delegation is one of the first things to verify.

Follow authority from parent to child

A recursive resolver begins with trusted root information and follows referrals through the DNS hierarchy. The root points toward a top-level domain, such as .com; the TLD points toward the domain's authoritative nameservers; those nameservers provide the domain's records or further delegations. Each referral identifies who is responsible for the next part. Delegation lets millions of separately managed zones coexist without requiring one global server to hold every record. It also means a mistake in one handoff can make an otherwise correct zone unreachable.

1. Create and populate the target zone at the intended DNS provider.
2. Confirm the provider's assigned authoritative nameserver hostnames.
3. Set the domain's delegation at the registrar or parent control plane.
4. Verify public NS answers and query the authoritative servers directly.
5. Check key website, email, and verification records after cutover.

When a delegated nameserver lives inside the domain it serves, glue records at the parent may be needed so resolvers can find the server's IP without first asking that server. Providers and registrars generally guide customers through this setup, but custom nameserver operators need to understand the dependency. A typo, missing glue, or inconsistent delegation can lead to timeouts or failures even if the DNS server is running. Standard nameserver hostnames supplied by managed providers often avoid the need for customers to manage this low-level detail themselves.

Why the wrong provider can look correct

A DNS dashboard can display a complete zone while that provider is not authoritative for the public domain. Perhaps the domain is still delegated to a previous host, the registrar update has not completed, or a subdomain is delegated separately. In those cases, editing the inactive zone changes nothing that ordinary public resolvers see. Check NS records from outside the provider's dashboard and compare them with the nameservers assigned to the zone. If a subdomain has its own NS delegation, records for that branch may be managed independently from the parent.

During a provider migration, keep the old zone available while delegation and caches transition. Lowering record TTLs ahead of time can help only after the old TTL has had time to age out. Copy mail, validation, and subdomain records, not only the website's address. Once delegation changes, query the new authoritative servers and compare the responses with the prepared zone. A migration is complete when the expected names resolve correctly from the intended authority and dependent services have been tested, not merely when a registrar form reports success.

For further reading, see what an NS record is, nameservers and domain delegation, and how to verify a DNS migration. A public DNS lookup can show answers visible to a resolver, while an authoritative query helps verify the zone itself. Separating registrar delegation from record hosting is the key to diagnosing where a DNS change actually needs to be made.

Create a clear delegation handoff

For a clean delegation handoff, identify the exact date and time when the registrar change is submitted, who can reverse it, and which resolver checks will confirm completion. Keep an authoritative contact at both the old and new DNS providers during the transition. If the domain uses custom nameservers or delegated child zones, include those dependencies in the runbook. A successful registrar update does not prove that each nameserver hostname resolves or that every service record was copied. Verify NS data, representative A and AAAA answers, MX targets, and critical TXT policies from outside the account. This gives the team a checklist that covers authority and the services that rely on the delegated zone. After the transition, remove the old provider only when the team has confirmed the new authority is serving all expected records and the rollback window has closed. Keep the date, delegation values, and verification results in the change ticket so a future administrator can understand which DNS service owns the domain.