Summary

  • RFC 9704 separates a locally supplied claim about private subdomains from a publicly verifiable token approving it. An internal name inventory need not become a public inventory merely to establish the resolver's authority.
  • The resolver's authentication name is still exposed in the public record. Approval also has a specific scope and lifetime; secrecy, authorization and service access remain different design decisions.
  • Grouping internal services beneath a stable child zone can reduce update work. It also changes how much future naming discretion is covered by one decision.

There is a revealing omission in the public DNS record described by RFC 9704. The record can authorize a local resolver to answer for private names, yet it does not have to display the list of those names. A client on the participating network receives the claim separately and checks it against what the public parent has approved.

That arrangement addresses a practical tension. An enterprise may want a payroll service or an internal project to resolve differently inside its network. A client may already use an external encrypted resolver for ordinary queries. Making every query local restores access to internal services by changing much more of the client's behavior than that access requires. Refusing every local exception preserves the original arrangement but can make those services unavailable through their intended names.

The interesting design space lies between those extremes. A local exception should be narrow enough to explain and sufficiently verifiable to accept, without requiring the organization to advertise its entire internal naming scheme to outside observers.

Publish the approval, not the inventory

Published in January 2025, RFC 9704 describes validated split-horizon DNS for this purpose. Its scope is particular: globally rooted names, authenticated encrypted resolvers and clients able to combine resolution methods. It is not a method for validating ownership of shared special-use names such as local., nor does it give a network permission to filter somebody else's domain.

The participating network supplies a claim identifying the resolver, the public parent and the set of subdomains to be handled locally. The parent approves a salted hash of the canonicalized set through a TXT record. The record's name binds that approval to the resolver's authentication name and the parent. The client, which has the local claim, can compute the expected value and look for the corresponding public approval.

The hash is not an encrypted directory to be unlocked later. Nor is the salt a password withheld from clients receiving the claim. The separation concerns what must be placed in public DNS, not what every participant can know. Local clients and the resolver necessarily have information that an outside observer of the public token need not receive.

This distinction changes the disclosure conversation. A reviewer can ask for evidence that a parent approved an internal arrangement without automatically asking the operator to expose every private service name in a public zone. Accountability does not always require the same information to be visible to every audience.

It also changes what an audit must retain internally. A token without its corresponding claim is a poor explanation of what the organization authorized. The public record can support verification while an access-controlled operating record preserves the meaning: the resolver identity, approved scope, responsible team and intended service. Public opacity should not become internal amnesia.

One name remains on the outside

The exception has a visible representative. The resolver's authentication domain name appears in the public verification record's owner name. RFC 9704 explicitly warns that this can disclose sensitive information if the resolver name contains it.

An organization could therefore protect the private subdomain list and still reveal a project through the name chosen for the resolver. This is an important kind of design failure: the protected payload is handled carefully while its public wrapper says too much.

The remedy is not to promise invisible infrastructure. It is to choose an intentionally nonsensitive public-facing name and review that name as a disclosure in its own right. An opaque internal label copied into the resolver's identity is not necessarily safe; it may be meaningful to people who know the organization's naming conventions.

The broader point is about budgeting disclosure. Some information must be available for outsiders to verify permission. Other information only needs to circulate among the participating network, clients and the approving operator. Identifying those audiences before deployment is more useful than applying one broad label, “private DNS,” to all of them.

There is a further limit. RFC 9463, which defines network discovery of encrypted resolvers, notes that encryption does not reduce the information available to the resolver itself. Protecting a query on its journey does not conceal it from the service selected to answer it. A decision to expose an internal view to a managed service provider therefore remains a decision about that provider's access to information.

ASD's ACSC makes a related operational warning in its gateway technology guidance: organizations should consider their trust and threat models before exposing internal split views to external parties, and should not treat IP-selected split DNS as a security mechanism. Its reference to RFC 9704 is guidance, not evidence that an organization's devices support the protocol or that a particular deployment is safe.

Approval must be checked from outside the claimant's control

The public record only helps if the local network cannot manufacture the answer used to verify its own claim. RFC 9704 permits verification through an already configured external encrypted resolver, retaining the client's normal acceptance checks, or through full local DNSSEC validation of the verification record.

These routes should not be blurred into “another DNS query succeeded.” A timeout on the external path is failed verification. A DNSSEC result that is Bogus or Indeterminate is rejected; an Insecure result calls for a different method or failure if the client does not retry. A useful internal exception does not justify weakening the mechanism that establishes its scope.

Discovery and certificate checking still do their own work. RFC 9463 can supply the resolver's name, addresses and transport parameters. Its certificate checks confirm the endpoint against the supplied name; they do not certify the security of the provisioning channel or the user's trust in the network. RFC 9704 adds permission for particular names rather than converting a valid certificate into permission for everything.

The IANA provisioning-domain registry records the splitDnsClaims vocabulary and its five fields. That shared vocabulary makes implementations able to describe the same kind of claim. It is not an adoption count, a client-conformance report or a record of which enterprise approved which resolver.

The size of the exception determines the work

An internal namespace can be organized under a stable child zone, with new services created beneath it. RFC 9704 recommends that kind of arrangement because it reduces changes to the public verification record. It is not required merely to keep the individual names out of public DNS.

The administrative benefit deserves attention. If every new private name changes the approved set, routine service creation can require coordination between internal DNS administration and public-zone administration. A stable subtree can let ordinary internal changes proceed without reopening the public record each time.

But this convenience has a price in discretion. Approving a subtree means approving more than the small collection of names visible on the day of review. Future names beneath that point fall within the arrangement. The question becomes whether the team controlling those future names should have that room to act.

There is no universally correct granularity. A tightly reviewed set may fit a small, sensitive service. A coherent internal child zone may fit an organization that wants one operating team to manage a changing application estate. An entire-parent claim is a broader decision again. These choices should not be made incidentally by whichever option produces the fewest change tickets.

Updates also have two distribution paths. The new public verification record must appear before the corresponding local claim changes, and the old record remains for clients holding still-valid configuration. Verification is repeated as the record approaches expiry. The underlying RFC 8801 provisioning-domain rules separately govern when additional information is deprecated and refreshed. One successful edit is not a shared instant at which every client acquires a new view.

This article reports the documentary design, not an implementation test. It supplies no fleet-support percentage, incident measurement or estimate of cost savings. Its managerial inference is narrower: an exception that depends on both public approval and local delivery needs owners who can coordinate those two sides without expanding the exception just to avoid the work.

The lasting benefit is not that the internal network becomes unquestionable. It is that an organization can make a particular local arrangement checkable while keeping unnecessary internal detail out of the public record. A name can be resolvable without the service being accessible; a resolver can be authorized without every observer being entitled to its internal inventory.