Summary

  • DNSOP has an open Call for Adoption on draft-jabley-dnsop-zone-cut-to-nowhere-01, ending 14 September 2026. The Datatracker classifies the document as a running adoption call, not an adopted working-group document or an RFC.
  • The draft lets a parent zone signal that a child exists in another DNS namespace through one NS record with an empty target. The signal does not publish reachable child nameservers, make the child publicly resolvable, or choose the child operator’s resolver and service policy.

An empty target is a precise sentence, not an empty grant of power.

The DNSOP call asks whether the group should take up an individual Internet-Draft called Signalling a Zone Cut to Nowhere in the DNS. The call asks list participants to support or oppose adoption and to explain their view. That is an important process opening. It is not the result of the process. The Datatracker names the present state Call For Adoption By WG Issued and explains that the call is still running while the working group has not reached consensus for adoption. The same document remains an Internet-Draft, marked as work in progress and capable of being updated, replaced or obsoleted.

That sequence matters because a useful technical idea can be made misleading by an oversized institutional description. DNSOP can decide whether to study, revise or ultimately publish a generic DNS mechanism. It does not acquire authority over every enterprise zone, every resolver configuration, every internal application or every customer expectation that might later be associated with the mechanism. A standards discussion is evidence of technical attention. It is not a transfer of operational responsibility.

The draft starts from a familiar topology. A public parent and a private child can share a textual suffix while existing in different DNS namespaces. An employee’s device may resolve a name through an internal resolver at one moment and, after moving networks, ask an Internet-reachable resolver at another. Caches and DNSSEC validation can make those different answers operationally awkward. The proposed signal gives the public-side parent a way to say something narrower than “the child does not exist”: the child exists, but not in this namespace.

The encoding is deliberately spare. In the parent zone, a delegation to nowhere is represented by a single NS record with an empty target, written in the draft’s example as NS .. The draft is just as careful about what this is not. An NS RRSet that also contains ordinary nameserver targets is not a delegation to nowhere merely because one record happens to be empty. The presence of reachable targets carries a different operational meaning; the specification refuses to collapse the two cases into one label.

That restraint should guide the governance reading. A parent administrator can make a parent-side statement. The statement tells a resolver that a boundary exists between namespaces. It does not publish the child zone file. It does not disclose an internal address, authenticate an internal server, promise that a private resolver will answer, or identify the person entitled to change the child. It certainly does not make a corporate intranet accessible to an external user who lacks the local path, credentials, network policy or service authorization.

RFC 1034 helps expose the difference. A conventional DNS referral gives a requester material pointing toward name servers that have the desired information. The proposed empty-target signal supplies no such reachable server set. That is not a defect the proposal accidentally forgot to repair. It is the feature’s limiting condition. It records that the public parent should not be mistaken for a directory of the private child’s operational interface.

The draft’s treatment of DNSSEC makes the same point more sharply. A secure delegation to nowhere may be provisioned when the parent administrator knows the keys used to sign the child zone. In that condition, a DNSSEC-aware recipient can cache a trust anchor for use when it later receives a signed answer from a nameserver that actually includes the child in its namespace. But the draft says such a secure delegation should not be used where children in different namespaces are differently signed or unsigned. A trust anchor can be a bounded cryptographic fact.

It is not a universal declaration that all namespaces, resolvers and relying applications should accept one policy.

This is the proper scale of DNSOP’s remit. Its charter covers DNS deployment and operational considerations, guidance, protocol maintenance, updates and extensions. It welcomes operational experience from DNS operators and other interested parties. That is exactly the forum in which an ambiguity between public and split-horizon DNS deserves close scrutiny. It is not a venue in which a room of contributors can become the principal for the operator that bears an outage, a privacy breach or a failed internal lookup. Participation can reveal an implementation risk. It cannot itself bind a network that was not party to the decision.

The strongest case for the proposal is therefore not that it makes private DNS more public. It is that it prevents a public namespace from over-speaking about private DNS. A mobile resolver may learn that a named child belongs somewhere else without being sent to a fictitious public endpoint. An enterprise can retain a private zone without relying solely on a negative answer that later collides with internal state. A parent can signal a boundary while keeping the child’s administration and reachability where they belong.

The record needed around such a deployment is correspondingly narrow. An operator that chooses this pattern should maintain a local namespace-boundary receipt: the parent zone and version; the child-name class without exposing sensitive internal names; the administrator that approved the public-side signal; the resolver populations affected; whether a secure delegation is present; the key-knowledge condition; the date of review; the rollback authority; and the test used to ensure that outside users are not promised a route that does not exist. That receipt is not a new Internet registry.

It is a way to stop a small public DNS statement from being misread as an invisible service contract.

No current source proves that a particular enterprise has deployed the draft, that public recursive resolvers will treat it uniformly, or that the proposed call will end in adoption. Those are future and local questions. The established fact is narrower and more valuable: DNSOP is considering a mechanism whose entire purpose is to make one namespace boundary legible without pretending to erase it.

Sources

  1. DNSOP Call for Adoption: draft-jabley-dnsop-zone-cut-to-nowhere-01
  2. draft-jabley-dnsop-zone-cut-to-nowhere-01
  3. DNSOP charter
  4. IETF Stream States for Internet-Drafts
  5. RFC 1034: Domain Concepts and Facilities