Summary

  • The current DNSOP working-group draft proposes that an NS RRSet containing only NS-dot can mark a child-zone boundary without naming publicly usable authoritative servers.
  • The signal can prevent a public authenticated denial from being mistaken for universal nonexistence when a roaming device later enters a private DNS namespace.
  • Parent publication, private reachability, child authority, DNSSEC validation and application success remain separate receipts; the empty target proves none of the later stages.

An empty target makes a precise admission

Ordinary DNS delegation joins two claims. A parent says a child zone begins here, then names servers from which the child can be reached. Split DNS sometimes needs the first claim without the second. A company may publish example.com globally while serving corp.example.com only through resolvers available on its own network. From outside, there is no honest public nameserver to list.

Revision 00 of the DNSOP working-group draft gives that situation a compact expression: an NS RRSet consisting of one record whose target is the empty name. In zone-file form, CORP 3600 IN NS-dot says that the boundary exists but that the parent's namespace supplies no route to the child. An RRSet mixing ordinary nameserver targets with the empty target is not the proposed signal. The exact shape matters because an empty value is carrying a deliberately bounded meaning.

The convention follows a useful DNS pattern. Null MX says a domain accepts no mail; an SRV target of dot says a service is decidedly unavailable there; AliasMode SVCB uses the empty target for an unavailable or nonexistent service. The draft extends the same honesty to the nameserver function. It does not invent an unreachable server. It says that this namespace cannot supply one.

The problem appears when a device changes vantage point

A laptop can ask the global DNS about an internal-looking name while it is away from the office. A DNSSEC-aware resolver may receive and cache authenticated denial from the public side. When the laptop later joins the private network, an internal nameserver can return a positive answer for the same name. The resolver may treat that answer as bogus because its cache contains cryptographic evidence from a namespace that never acknowledged the private child boundary.

The zone cut to nowhere changes the public statement. Instead of allowing the parent to imply that no lower zone exists, it publishes a referral whose servers cannot be resolved or reached. The draft says no special processing is required: a resolver handles the referral as it would any referral with unreachable child nameservers. Public resolution still stops. What changes is the reason it stops and the cache state that follows.

That distinction is not semantic decoration. “No such name below this public authority” and “a child boundary exists, but not on this path” support different later decisions. The signal keeps a public vantage point from claiming more than it can know.

Five receipts must not collapse into one

The first receipt is parent intent: the administrator placed the exact singleton empty-target NS RRSet in the parent. DNSSEC can add a second receipt by authenticating what the signed parent published. Neither receipt identifies a private nameserver or shows that one is running.

The third receipt is resolver observation. A client actually received and cached the referral, with a particular TTL and validation status. Network middleboxes, stale caches and implementation defects can separate configured data from observed data.

The fourth receipt belongs to the private path. After a network transition, the device selects an internal resolver or forwarding policy that can reach the child. That selection is local operational state; the empty public target neither discovers nor authorizes it.

The fifth receipt is the child's answer and its consumption. A private authoritative server may be unavailable, incorrectly signed or serving a different view. A resolver may validate or reject its response. An application may never use a successful lookup. “The parent admitted a boundary” therefore cannot be reported as “the private service worked.”

A DS record narrows one gap and opens another

The proposal permits a secure delegation to nowhere: the parent may publish DS material alongside the empty NS target when it knows the child signing keys. A roaming validating resolver can then retain a trust relationship for the child it later encounters in the private namespace.

That option is safe only inside its premise. If several private namespaces use differently signed versions of the child, one parent-side DS cannot certify them all. Revision 00 says a secure delegation should not be used when private views are differently signed or unsigned. The key decision is not cosmetic. It is a statement about which authority context the parent is prepared to bind.

DS also does not create reachability. It can help validate a response once the device finds the relevant child and obtains its DNSKEY and signed data. It cannot choose the device's resolver, grant access to a corporate network or make an application healthy.

The draft is evidence of design, not deployment

Revision 00 is an active Standards Track Internet-Draft dated 23 September 2026. It is working-group work, not an RFC or final IETF consensus. Its example of placing INTERNAL with an empty NS target in the root is expressly illustrative and gives IANA no operational direction.

The draft reports experiments and says their results did not suggest widespread operational trouble. It also acknowledges possible software assumptions and harmful traffic toward the root if the pattern became common. Those statements define a testable risk, not a universal compatibility certificate.

One limitation is immediate. An organisation that makes temporary public TXT records beneath the nominally private child for ACME DNS-01 validation cannot simultaneously say that the public child has no usable DNS publication path. Its operational exception breaks the clean model. A minimum signal is valuable only when the surrounding configuration tells the same truth.

Sources