Summary

  • An NSID value can show that one DNS responder attached particular bytes to one response, but the protocol does not prove that the value is a hostname, a physical machine, a location, a software version or a permanent identity.
  • Useful incident evidence therefore has four parts: the original response, the observer’s vantage and time, the operator’s current token mapping, and the operational unit that the evidence is allowed to control.

The address stopped being a machine name

The old diagnostic instinct was simple: send a query to an IP address, note the answer, and treat the address as the identity of the answering server. That shortcut weakened as DNS operators spread one service address across several instances. Anycast makes a stable address reachable from several autonomous locations; routing chooses one of them for a particular packet. A load balancer can create a similar split behind one destination.

The address still matters. It identifies the service destination that the client used. It just no longer names one machine. RFC 4786 calls the address a service address and calls the topological region routed to one node a catchment. Neither the client population of a node nor the route chosen for a particular client is guaranteed to remain static. RFC 3258 made the DNS consequence explicit: two dedicated queries to the same shared address need not reach the same server, while ping, traceroute or a separate TCP connection may be even less likely to reach the process that handled the DNS transaction.

This is the operational problem that Suzanne Woolf and David Conrad framed in RFC 4892. Their document is Informational, not a standard, and its subject is narrower than universal host identity. It asks what a DNS administrator needs when a response is wrong, stale or unexpectedly slow and several servers can legitimately sit behind the address that was queried.

That distinction matters during an incident. “The service at this address returned stale data” is a defensible observation. “This physical machine returned stale data” is a second claim. The first comes from the packet exchange; the second requires a mapping that the DNS response alone may not contain.

Why the second query is the wrong receipt

BIND deployments had already developed a convenient convention. A CHAOS-class TXT query for HOSTNAME.BIND. could return a configured hostname; the more implementation-neutral label ID.SERVER. served a similar purpose. Because the query is DNS, it can traverse the same firewall policy and broadly the same routing system as ordinary DNS traffic. The operator can also choose the returned string and avoid exposing a maintenance address.

But the identifier arrives in a second transaction. That is the convention’s decisive weakness. Between the problematic answer and the diagnostic query, an anycast route can change, a load balancer can choose another backend, or an unhealthy instance can disappear. The investigator then holds two valid receipts from two different responders and may join them into one false story.

The error is subtle because every component looks credible. The original answer really came from the shared service address. The label really came back from that address. The traceroute really ended near the advertised service. Yet none proves that the second responder was the first one. Correlation by address alone is precisely what the distributed topology invalidated.

RFC 4892 therefore asked for identification to be available inside the normal operational response. It still allowed a dedicated query, but refused to treat that query as an equivalent substitute. Same-response association is not ornamental metadata. It is the first evidence boundary.

What RFC 4892 required

Woolf and Conrad did not simply ask for a standardized spelling of ID.SERVER.. They used the failure of the convention to specify the properties of a better mechanism.

It had to be in-band for DNS and capable of accompanying the response being investigated. It could not depend on one server implementation or consume a separate class and pseudo-zone merely for identification. It had to be easy to implement, enable and disable. It should support access controls because an operationally useful label can also reveal private topology. And it had to let an operator distinguish instances without forcing disclosure of a real hostname or unicast maintenance address.

The requirements also separated identification from authentication. A future design should make authenticated data possible, but a string that resembles a hostname does not authenticate itself. That is especially important in DNS, where DNSSEC validates signed DNS data and denial-of-existence statements but does not automatically authenticate every piece of channel metadata attached by a responder.

RFC 4892 stopped at those characteristics and proposed no IANA action. Two months later, RFC 5001, authored by Rob Austein, defined the NSID option. Woolf is acknowledged in that document, but the standards authorship remains Austein’s. Keeping that attribution precise mirrors the article’s broader point: labels are useful only when their scope and provenance are not enlarged by convenience.

What NSID actually proves

NSID uses an EDNS option. A resolver places an empty NSID request in the query, and a server that understands the option and chooses to answer can put identifying bytes in the response. Because the bytes travel with that response, the observer can reliably say that the responder for this transaction supplied them. This repairs the temporal gap created by a follow-up ID.SERVER. query.

The repair is deliberately limited. RFC 5001 defines the payload as an opaque byte string and leaves its syntax and meaning outside the protocol. The operator can use a hostname, a unicast address, a random value, a persistent probabilistic identifier, an encrypted value or arbitrary octets. User interfaces display the data as hexadecimal because exact transport matters more than a pretty but ambiguous rendering.

The label can therefore be a stable machine name, but it need not be. It can name a process, a container, a backend pool or a site. It can be stable across restarts or change at every restart. It can be unique across the fleet or, through misconfiguration, identical everywhere. A token meaningful to the operator may be intentionally meaningless to the public. The protocol provides the envelope; the operator supplies the semantics.

NSID is also non-transitive. If a client asks a recursive resolver for NSID, the value identifies the recursive server that received that query, if the resolver chooses to return one. It does not automatically reveal which authoritative server the recursive resolver consulted. An upstream NSID collected by the resolver is a separate hop and a separate receipt. EDNS itself is hop-by-hop, so this is architectural, not a missing user-interface feature.

Finally, NSID is not automatically authenticated. RFC 5001 treats it as channel signalling outside DNSSEC’s normal protection. A use case that depends on integrity needs explicit channel security such as TSIG and still needs replay-aware design if signed or encrypted blobs are used. Cryptographic-looking bytes do not establish freshness, physical location or operational ownership.

The four receipts

The best way to use a server label is to make its claim smaller and its evidence richer.

The first receipt is response association. Preserve the original query and response, including the raw NSID bytes. A copied text label or a second query cannot replace the packet-level join. If NSID was not requested in the transaction, the investigator should state that the responder identity is unresolved rather than manufacturing certainty later.

The second receipt is vantage and route. Record the observer, target service address, transport and time. An anycast answer describes what one client reached from one point in the network. A second vantage can expose a different catchment without contradicting the first.

The third receipt is the operator mapping. The operator should be able to map a token to an intended operational unit and say when that mapping was valid. A mapping version, activation time and retirement time turn an opaque grouping key into evidence. Without them, a token reused after a rebuild can make two different instances look continuous.

The fourth receipt is action scope. The incident record must state whether the mapped unit is a process, container, host, load-balancer pool, site or anycast node. That determines what an operator may safely drain, restart, quarantine or inspect. A label that identifies a process cannot by itself authorize withdrawal of a whole site’s route.

Together these receipts preserve the useful part of identity without pretending the protocol delivered more. They let operators compare responses, find an outlier and contact the right team. They also make uncertainty visible when a server declines to answer, an intermediary strips the option, or the mapping has expired.

Sources