Nameservers and DNS zones: who manages what, and which one wins

The DNS is split into zones

No one organisation could manage every DNS record in the world, so the system is cut into pieces. The DNS terminology standard, RFC 9499, puts it this way: “Authoritative information is organized into units called ZONEs”.

In plain terms:

• A zone is one part of the domain name tree, managed in one place. Your domain’s zone is the list of records from the last lesson.
• A nameserver is a server that publishes a zone and answers questions about it. There are always at least two, so one can fail without taking your domain offline.
• Delegation is one zone handing part of the tree to another. It’s done with NS records in the upper zone that say “for that name, ask those nameservers”.

Follow the delegations down from the top and you get a chain. Each link is a separate zone, run by a different organisation.

Who manages each layer?

IANA’s job at the top, in its own words, includes “assigning managers for these domains, recording technical delegation data in the root zone, and publishing a registry of related information”. Its public record for .au names auDA as the manager, and the one for .com names Verisign. For .au, the registry runs the nameservers for .au itself and for the namespaces inside it, such as com.au and net.au.

The row that matters to you is the second one. The registry holds a short entry for your domain: its name and the nameservers that answer for it. You can’t edit the registry directly. The company you registered with passes your change along. Lesson 6 covers that chain.

Three jobs, often three companies

Most confusion comes from three separate jobs that sound like one.

A typical mix: the domain is registered with one company, the DNS is hosted at Cloudflare, the website is with a web designer’s hosting company and the email is at Google or Microsoft. Each of them has a control panel, and several of those panels have a page called “DNS”.

Which zone is live?

Here’s the catch. Any provider can create a zone for your domain on its own nameservers. Creating one doesn’t make it live. The internet only ever asks the nameservers that the registry lists for your name, so those nameservers’ zone wins, completely. Every other copy is ignored.

This is how people end up saying “I added the record and nothing happened”. The usual ways to get there:

• Your web host created a zone when you added the domain to your hosting account, and you edited that one, but your nameservers point somewhere else.
• You moved DNS to a new provider, and someone later edited the records at the old one out of habit.
• You set up a zone at a new provider and never switched the nameservers over to it.

Which one wins? The other tie-breakers

The registry’s list is the big one. A few smaller rules decide the rest.

The registry’s list and your zone’s own list

Your nameservers are written down twice: once at the registry, and once inside your own zone as NS records. The registry’s copy is how resolvers find your zone in the first place. But RFC 2181 says the NS records at that boundary “are the property of the child zone”, and it ranks an answer from the zone’s own nameservers as more trustworthy than a pointer from the level above. So once a resolver has reached your zone, it may switch to the list your zone gives.

If the two lists differ, some lookups end up at servers you thought you’d retired, and results become patchy. The rule is simple: keep both lists identical. Your DNS host normally looks after its side. You set the registry side where the domain is registered.

A delegated subdomain beats records in the main zone

You can hand one subdomain to different nameservers by adding NS records for it, say for shop.yourname.com.au. From then on, those other nameservers answer for shop and everything beneath it. Any other records you keep for shop in the main zone are no longer used, because, as RFC 1034 has it, the main zone’s NS records at such a cut “are not authoritative”: its authority stops there.

An exact name beats a wildcard

A wildcard record, written *, answers for any subdomain that doesn’t have records of its own. If blog has its own record, the wildcard doesn’t apply to blog. Wildcards also stop at a delegated subdomain; RFC 1034 again: “delegation cancels the wildcard defaults”.

A CNAME can’t share

A name with a CNAME can’t hold any other record, so there’s nothing to rank. If your editor let you save both, the result is unpredictable. Pick one. See the CNAME rules.

The cache beats your change, for a while

A resolver that already holds the old answer keeps using it until the record’s TTL runs out. Your change has taken effect; some people just haven’t been told yet. See why changes don’t show up straight away.

Your own network can overrule the public DNS

Everything so far is about the public DNS. Inside an office, there’s often a private DNS server that answers first, and it can hold its own zone for the company’s domain. Staff inside get the internal answers; everyone else gets the public ones. RFC 9499 calls this split DNS: servers giving different answers depending on where the question comes from.

The classic symptom: a new website works from home and from a phone, but not from the office. The public zone is right; the office’s internal zone is missing the record. Whoever looks after the office network needs to add it there too.

One level further in, every computer has a small “hosts” file that overrides DNS for that one machine. Developers use it for testing. If one computer sees something nobody else does, that file is worth a look.

Quick reference

Moving your DNS to a new provider, safely

Changing nameservers swaps one whole zone for another, so the new zone has to be complete before you switch.

1. Copy every record first. Recreate the full zone at the new provider: website, www, MX, every TXT record, every subdomain. Email records are the ones people forget.
2. If the domain uses DNSSEC, sort that out before anything else. The DS record at the registry refers to the old provider’s keys. Follow your new provider’s migration steps, or remove the DS record and wait a day, or the domain can stop resolving after the switch. Why a broken chain takes you offline.
3. Change the nameservers where the domain is registered. This is the moment the registry starts sending people to the new zone.
4. Leave the old zone running for a couple of days. Some resolvers will still be using the old nameservers until their cached copy expires.
5. Check the result with a lookup, then retire the old zone so nobody edits it by mistake.

A footnote on glue records

If your nameservers are named inside your own domain, such as ns1.yourname.com.au, there’s a chicken-and-egg problem: to find the nameserver you’d need to ask the nameserver. The fix is a glue record, which stores the nameserver’s IP address at the registry alongside the delegation. RFC 9499 describes glue as address records “for the name servers in subzones”. If you use a DNS provider’s nameservers, as nearly everyone does, you’ll never need one.

“I changed a record and nothing happened”

Work through these in order. The first one explains most cases.

1. Am I editing the live zone? Look up the domain’s NS records. If they don’t belong to the provider where you made the change, you’ve found the problem.
2. Has the old answer expired yet? Check the TTL on the record and wait that long.
3. Is something else claiming the name? Look for a CNAME sharing the name, a duplicate record, or a delegated subdomain.
4. Is it just this network? Try from a phone on mobile data. If it works there, look at the office DNS server or the computer’s hosts file.

Terms in this lesson

Zone

One part of the DNS, managed in one place.

Nameserver

A server that publishes a zone and answers questions about it.

Delegation

One zone handing part of the name tree to another set of nameservers, using NS records.

DNS host

The company that runs the nameservers holding your zone.

NS record

A DNS record naming the nameservers in charge of a zone.

Wildcard record

A record written with * that answers for any subdomain without records of its own.

Split DNS

When an office’s own DNS server gives different answers from the public DNS for the same name.

Glue record

A nameserver’s IP address stored at the registry.

Hosts file

A small file on every computer that overrides DNS for that one machine.

Every term, in full, is in the glossary.

Sources

All read on 2 October 2026.

• RFC 9499, DNS Terminology (IETF): zones, delegation, glue records and split DNS.
• RFC 1034, Domain Names: Concepts and Facilities (IETF): how the name space is cut into zones, NS records at a cut, and when wildcards don’t apply.
• RFC 2181, Clarifications to the DNS Specification (IETF): NS records at a zone cut belong to the child zone, and the ranking of authoritative answers over referrals.
• RFC 4034, Resource Records for the DNS Security Extensions (IETF): the DS record is held in the parent zone.
• Root Zone Management (IANA): IANA’s role in managing the root zone.
• Root Servers (IANA): the organisations that operate the root servers.
• Delegation record for .au and for .com (IANA): the manager of each top-level domain.
• The .au registry (auDA): Identity Digital Australia operates the registry, including the .au and second-level nameservers.