DNS delegation and exposure explained

DNS delegation is how the internet knows which servers speak for your domain, and getting it wrong quietly breaks resolution or leaks your whole zone. This guide covers delegation hygiene, open resolvers, and zone transfers.

Every domain leans on a handful of nameservers to answer queries about it, and DNS delegation is the chain that tells the world which servers those are. When delegation is clean, resolution is fast and reliable. When it drifts, you get intermittent failures, stalled changes, and - in the worst case - a nameserver that hands your entire zone to anyone who asks. This guide explains DNS delegation, the exposure risks that ride alongside it, where it commonly breaks, and how SecRift checks yours.

What is DNS delegation?

DNS is a tree. The root delegates .com to the com registry, .com delegates example.com to your nameservers, and your nameservers answer for everything below that point. Each hand-off is a delegation, and it is expressed with NS records that name the servers responsible for the zone below.

There are two copies of that NS list, and they are supposed to agree. The parent zone (your registrar's delegation) holds one copy, and your own zone publishes another at its apex. A resolver starts at the parent to find your nameservers, then trusts the authoritative answers those nameservers give. The apex of a zone is the bare domain name itself - example.com, not www.example.com - and it always carries the SOA and NS records that define the zone.

How delegation works

When a resolver looks up your domain for the first time, it walks down the tree. It asks the root where .com lives, asks .com where example.com lives, and .com responds with a referral - the NS records your registrar published. The resolver then queries one of those nameservers directly and gets an authoritative answer, marked with the AA (authoritative answer) flag.

A few things keep that machinery healthy:

• Redundancy. At least two nameservers on distinct hostnames, so one failing does not take the domain offline.
• Consistency. The NS set at the parent matches the NS set your zone publishes, so every path leads to the same servers.
• Authority. Every listed nameserver is actually configured to serve the zone and answers with the AA flag.
• A sane SOA. The Start of Authority record carries the serial number and the refresh, retry, and expire timers that secondary servers use to stay in sync.

Why it matters

Delegation is invisible until it fails, and then it fails for everyone at once. A single nameserver is a single point of failure for the whole domain. A nameserver listed in the delegation but not actually serving the zone - a lame delegation - makes resolvers wait and retry, slowing every first lookup. A CNAME accidentally placed at the zone apex breaks the zone outright, because a CNAME cannot coexist with the SOA and NS records the apex must have.

Then there is exposure. Delegation decides which servers answer for you, and those same servers can be misconfigured in ways that leak or amplify. An authoritative nameserver that also offers open recursion will resolve names for any stranger on the internet, which turns it into a tool for DNS amplification attacks and cache poisoning. A nameserver that allows an unauthenticated zone transfer hands over every record you have - every subdomain, every internal-looking host - to anyone who asks. Both are configuration mistakes, not design choices, and both are fixable.

Common mistakes

• Only one nameserver. A single NS hostname means one outage takes the entire domain down.
• Parent and child NS mismatch. After moving DNS providers, the registrar delegation and the zone's own NS records drift apart, causing inconsistent resolution.
• Lame delegation. A nameserver is named in the delegation but was never configured to serve the zone, so it answers with REFUSED or without authority.
• Stalled propagation. Secondary servers serve an older SOA serial than the primary, so answers differ depending on which server a resolver reaches.
• Broken SOA timers. Refresh smaller than retry, or expire smaller than refresh, which confuses the primary-secondary sync logic.
• A CNAME at the apex. An alias placed on the bare domain collides with the required SOA and NS records and produces undefined resolver behavior.
• Open recursion or public AXFR. An authoritative server left resolving for strangers or transferring its full zone on demand.

How SecRift checks DNS delegation and exposure

SecRift queries your authoritative nameservers directly - and the parent zone for comparison - and breaks the result into eight findings:

• Nameserver redundancy - confirms the zone is served by at least two nameservers on distinct hostnames, so no single server is a point of failure.
• Delegation consistency - compares the NS set delegated by the parent zone against the NS set your zone publishes and flags any mismatch.
• Authoritative answers - probes every listed nameserver and reports lame ones that do not answer authoritatively for the zone.
• SOA consistency - checks that every responding nameserver serves the same SOA serial, catching stalled or incomplete zone propagation.
• SOA sanity - validates the SOA fields: the refresh, retry, and expire timers, the serial format, and a well-formed MNAME and RNAME.
• Apex CNAME - detects a CNAME published at the zone apex, the heaviest-severity finding here because it breaks the zone.
• Open recursion - tests whether an authoritative nameserver resolves out-of-zone names for arbitrary clients, exposing it to amplification and cache poisoning.
• Zone transfer - attempts an unauthenticated AXFR and flags any nameserver that leaks its full zone contents.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix - for example, aligning the registrar's NS records with the zone, or restricting AXFR to authorized secondaries with allow-transfer ACLs or TSIG. SecRift only reads public DNS, so it sees exactly what any resolver on the internet would.

Clean delegation is also the ground that stronger DNS security stands on: once your zone is served reliably, DNSSEC signs its answers so resolvers can prove they weren't tampered with.

Run a free scan on any domain at secrift.com and see your DNS delegation and exposure in seconds.