Summary

  • RFC 5001, published in August 2007, defined the DNS Name Server Identifier option. A resolver asks with an empty EDNS NSID field; a willing name server puts identifying bytes in the answer it sends.
  • A second query to an anycast address can land on a different node. The NSID attached to the first answer identifies the server claiming to have sent that answer, at that hop. The identifier is an opaque byte string whose meaning and disclosure are chosen by the operator.
  • L-Root’s 2014 operational account says its nodes returned their fully qualified hostnames as NSID. That is a concrete deployment of a protocol that also permits pseudonyms or less revealing values. The IANA DNS registry records NSID as EDNS option code 3.

The second question might reach a different machine

A resolver receives a bad DNS answer from a familiar address. It repeats the query and receives a good one. The address has stayed put, so the neat incident report says the same server changed its mind. Anycast can make that report fiction. Several DNS machines may share the service address while routing decides which one receives each query. A load balancer can produce the same ambiguity inside a site. Two replies from one address need not come from one process, disk, configuration or operator-maintained node.

The 2006 anycast operations guidance treated node identification as a practical part of diagnosing a distributed service. The address gets a client to the service. It does not tell the client which replica performed the work. A technician can issue a special follow-up query for a server name, but the route can change between the suspect answer and the follow-up. The next server may introduce itself politely while the faulty one has already gone home.

RFC 5001 made the identification request part of the original DNS exchange. Its introduction points to anycast, load balancing and other arrangements that put more than one name server behind a single IP address. Since a DNS query has no retained session state, it says the reliable way to identify the responder to a particular query is to have that responder put the information in its response. The timing matters: the label rides on the answer under investigation, rather than on an unrelated answer obtained later.

A request with no name in it

The request is deliberately small. A resolver sends an empty NSID option inside the EDNS OPT pseudo-record. The query must carry no NSID payload. IANA assigns EDNS option code 3 to NSID. A name server that understands the option and chooses to honor the request adds its identifying bytes to an NSID option in the reply. The server must ignore any payload placed in the request, and must never send an NSID response to a resolver that did not ask for one. The recipient can keep the DNS answer, the NSID bytes and the timestamp together as one diagnostic record.

The payload has no mandated hostname format. RFC 5001 calls it an opaque byte string. It could be a machine’s real name or maintenance address. It could be a persistent random value, an identifier derived from another value, a changing token, signed data or encrypted data. The protocol fixes the question and the place where an answer can appear; the operator decides what the disclosed bytes reveal. A readable name makes a trouble ticket easy to route. A pseudonym can distinguish replicas while keeping maintenance addresses out of public view. A changing value can let only the operator correlate repeated observations.

That choice is a real control surface. Publishing every machine’s management address would give outsiders a map of a service deliberately sheltered behind a common address. Publishing a token intelligible only inside the operator’s inventory can still let a customer attach exact evidence to a ticket. The RFC’s security discussion treats NSID as channel signalling outside DNSSEC’s protection of DNS data. A capture of the bytes can show what the answer claimed; authenticity requires channel protection or corroborating operator records for a contested finding.

L-Root chose a legible label

In January 2014, the operators of L-Root published their account of deployed node-identification methods. L-Root used anycast to serve one root-server address from many machines. Its NSID response carried the fully qualified hostname of the node that answered. The document even shows a dig exchange in which the NSID appears as hexadecimal octets and decodes to a node name such as ytz01.l.root-servers.org. Here the opaque field became a public, readable label because that operator chose it.

The same document compares NSID with follow-up queries for HOSTNAME.BIND or ID.SERVER. Those queries can identify the node answering the follow-up; a route change can separate it from the node that produced the problematic response. NSID on the problematic query joins the answer and the claimed node in one exchange. That makes a reported error reproducible as evidence even when a later probe returns a different answer from the same service address.

L-Root’s publication describes a deployment at that date. It gives an original operator example of the design, not a present-day inventory of every root server. The packet itself is still the place to look for a particular reply: query, EDNS request, answer, NSID field, source, transport and timestamp. An operations map can translate the bytes into a physical or logical node if the operator makes that mapping available.

A recursive server answers for itself

NSID stops at the server receiving the request. RFC 5001 says the mechanism is hop by hop. When a stub resolver asks its recursive resolver for NSID, the request asks that recursive resolver to identify itself. The recursive resolver may separately ask an authoritative server for its own NSID, but that second exchange has a different requester and responder. The recursive server must not attach an NSID to its reply to a stub that never requested one. A client cannot treat a recursive server’s NSID as the identity of the authority that supplied an upstream answer.

That boundary prevents a useful troubleshooting mark from becoming a fake end-to-end trace. To identify an upstream authority behind a recursive answer, the operator needs the resolver’s own query log or a captured upstream exchange with its own NSID request. A downstream reply has no built-in chain of every server consulted along the way. Even at one hop, an unverified token names the responder as the responder chose to present itself; a separate health or configuration record is needed to establish why its answer differed.

One reply, one responsible node

RFC 5001 did not need to alter the DNS service address to make the underlying machine visible. It placed an optional label beside the answer that machine produced. IANA keeps the common option number; the operator decides the label; the resolver decides whether to ask and whether to preserve it with the answer. Each participant owns a different piece of the evidence.

The protocol also left room for the operator to refuse the disclosure. A server can understand a request and decline to include an identifier. Extra response bytes can contribute to truncation, although the optional response leaves the server free to omit them. The absence of NSID in one captured answer establishes that no identifier was returned in that exchange. It cannot name the node from silence.

Anycast sold the convenient fiction of one address. The 2007 fix was to let the actual respondent leave a name beside its answer. L-Root chose a readable name; another operator can choose a private token. In both cases the diagnostic advantage comes from coupling the claim to the exact reply. A second query may tell a different story, from a different machine.