concept Domains & DNS
Authoritative nameserver
Learn how authoritative nameservers answer for DNS zones and why registrar delegation must point to the zone you edit.
What it means
An authoritative nameserver holds or serves DNS data for one or more zones and responds for those zones from its authoritative data, rather than merely repeating an answer cached from another server. A zone is an administratively managed portion of the DNS name tree. Multiple authoritative servers can serve the same zone for availability. Authority is about the zone served, not whether the operator is the domain registrar, website host or another organization. Zones and authority DNS terms
A parent zone publishes a delegation, typically NS records pointing to the child's nameservers. The child zone also contains its own authoritative information, including SOA and NS records at its apex. Editing a DNS dashboard that is not actually delegated may save a record locally yet have no effect on the public lookup path. Delegation
Try it
Simulation — ask a server about its own zone. Choose the parent, child or unrelated server, a fixed name and an A or AAAA question. Query selected fixture produces a local answer, referral or denial and explains the authority boundary.
Ask an authoritative zone
Move a zone boundary and distinguish an answer, referral and negative answer.
The result comes from the configured role and zone, not from a recursive cache.
| Item | State / result | Why it matters |
|---|---|---|
| Question | www.example.test A | Names and types must match when comparing replies. |
| Zone | example.test | An authoritative zone has a boundary. |
| Result | 192.0.2.20 | Predicted initial example; Query runs it locally. |
| AA | Set in fixture | An authority flag is not cryptographic authentication. |
A small synthetic zone map. AA is not DNSSEC validation. Nothing is queried on the network.
About this model
The parent example.test can delegate lab.example.test. Below that cut it returns a referral, not the child’s A data. A direct query to the child can obtain its answer even if the public delegation is absent; being reachable is different from being on the public resolution path. NODATA keeps the name; NXDOMAIN denies the name in this fixture.
Read the article’s primary sources for protocol rules and implementation-specific limits. This scene has no network access.
Query www.example.test A at the parent to obtain its A data. Then ask the parent for www.lab.example.test A while the child is delegated. The parent points to the child authority rather than claiming the child's A answer. Ask the child directly to obtain that answer. Switching the parent to hold the subtree changes the boundary in the fixture; a direct answer from a server still does not prove that the public delegation leads to it.
| Question at the parent fixture | Result | Why it differs |
|---|---|---|
www.example.test A | Authoritative address answer | The data is inside the parent zone |
www.lab.example.test A, child delegated | Referral | The name is below a child zone cut |
www.example.test AAAA | NOERROR with no requested data | The name exists, but this type is absent |
missing.example.test A | NXDOMAIN | The fixture says this name does not exist |
An unrelated server returns REFUSED in this deliberately declared policy; it is not a universal response for all servers outside a zone. The AA flag in the result means authoritative answering, not verified DNSSEC or a working website. No transport failures are fabricated as negative DNS answers. Reset restores the parent A question and delegated child. Zones and referrals Current DNS terminology
Zone versus domain versus provider
A domain name can contain many descendant labels and even delegated child zones. Changing www.example.com in the parent example.com zone is different from editing an independent shop.example.com child zone if shop has been delegated. The authoritative answer may originate from whichever zone actually covers the record's owner name.
| Item | Question it answers |
|---|---|
| Domain registration | Who manages the registered name? |
| Parent NS delegation | Which servers are designated for this child zone? |
| Authoritative zone | Which DNS records will its nameservers answer for? |
| Recursive cache | Which answers might users still receive temporarily? |
An NS record inside an unrelated DNS panel is not a substitute for correctly configuring the parent delegation. An NS target is meant to name a server with address records, not a CNAME alias. NS target rule
In practice
When verifying a proposed record change, identify the current delegated NS set and inspect each authoritative server for the exact owner name and RR type. Check that the authoritative servers agree on expected records and are reachable. A changed entry in a control panel alone is not a verification result. If parent and child NS data are inconsistent, investigate delegation separately from an ordinary A/AAAA edit; broad nameserver replacements can affect the whole domain, including email.
For the lookup path see DNS resolution; for a read-only decision tree when changes do not appear see DNS change not visible. Connecting a domain covers the wider hosting task.
Key takeaways
Authority has a zone boundary. Identify both the server and the exact question before interpreting its reply. A referral, an answer with no requested RRset and an absent name are different results; a direct authoritative reply is not by itself proof of correct public delegation.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- RFC 1034 — Domain Names: Concepts and Facilities
Sections 2.4, 3.1, 4.3.2 and 5. DNS tree, zones, referrals, resolvers and caching.
Checked .
- RFC 1035 — Domain Names: Implementation and Specification
Sections 3.2, 3.3 and 4. RR formats, TTL, A, NS, SOA, CNAME and MX records.
Checked .
- RFC 9499 — DNS Terminology
Sections 2–7. Terminology for authoritative servers, recursion, caching, and delegation.
Checked .
- RFC 2181 — Clarifications to the DNS Specification
Sections 5 and 10. RRsets, CNAME coexistence, and MX/NS alias restrictions.
Checked .