Summary

  • A follow-up query to the same DNS address may reach a different instance. NSID lets the server include a diagnostic identifier in the very response under examination.
  • Its scope is one DNS exchange. A recursive resolver identifies itself to its client, not every authoritative server involved in resolving the name.
  • The common protocol preserves opaque bytes; operators choose their meaning and disclosure policy. An identifier is neither a globally certified identity nor automatic authentication.

The trouble with asking afterwards

The revealing moment comes after the unusual answer. An operator has a DNS response worth investigating and sends another query to the same address: which server are you? A perfectly healthy instance supplies its name. Its logs contain no trace of the original problem.

There need be no missing log and no dishonest server. The second query may have reached a different instance. This is an illustrative diagnostic sequence, not a measured outage. Its importance is that the method can produce a convincing answer to the wrong question. The operator wanted to identify the author of the earlier response, but identified the participant in a later exchange instead.

That distinction drives RFC 4892, the June 2007 requirements document by S. Woolf and D. Conrad. Anycast or load balancing can send successive DNS queries to different servers. Probing with another protocol provides still less assurance that the responding system handled the original query. An address remained useful for reaching a service; it no longer uniquely named the instance performing the work.

A stable address, a variable participant

The operational background was already explicit in RFC 4786, published in December 2006 as BCP 126. An anycast service uses stable addresses announced from multiple independent service nodes. Routing determines which node receives traffic. This does not mean the geographically closest machine always wins, or that every successive packet necessarily goes somewhere new. It means that stability cannot be assumed solely from an unchanged destination address.

This was a useful separation. Clients could use one service address without learning all the maintenance addresses behind it. Operators could distribute service without asking every client to maintain a changing inventory. But diagnostics acquired an extra variable: which node actually answered?

RFC 4786 recommended identification within the service protocol and recording node identity alongside performance and availability from distributed monitoring points. A traceroute might help, yet the network could change before it ran. The document referred to NSID work then in progress; the final NSID RFC did not yet exist. The operational need preceded the finished option.

The old question was useful, but separate

DNS operators already had conventions for asking a server to name itself. A TXT query in the CHAOS class for HOSTNAME.BIND. could return an administrator-selected identifier. ID.SERVER. removed the implementation-specific name. VERSION.BIND. served a different purpose, reporting version information rather than solving the same identity problem.

These mechanisms had practical virtues. They used DNS, were straightforward to configure and left disclosure with the administrator. A new standard did not make them worthless or prohibit their use. The defect was narrower: a separate query could not reliably attach its result to an earlier response from an address shared by several instances.

RFC 4892 therefore sought identification as part of an ordinary operational query, without requiring a separate class or diagnostic namespace. It also sought implementation neutrality and administrative controls. An operator should be able to provide a useful reference without necessarily exposing a private maintenance hostname or unicast address. Better correlation did not require a public directory of the entire installation.

A request with nothing inside it

R. Austein's August 2007 RFC 5001 defined the DNS Name Server Identifier option. A requester adds an empty NSID option to the EDNS OPT pseudo-resource record of its query. The request must not contain NSID payload data; a server must ignore any such data that nevertheless arrives.

The empty request matters. It is not a challenge value that the server must echo, an instruction to select a named machine, or a proposed identity for the other side. It asks the actual recipient to append its own identifier to this response, if it supports the option and chooses to honor the request.

The choice remains real. A server may decline, and it must not send NSID without a request. An ordinary DNS response without NSID is not thereby evidence of failure, absence of anycast or absence of distinct instances. Supported, configured, requested and returned are separate states.

The IANA DNS parameters registry assigns NSID EDNS option code 3. It allocates the shared slot, not the values placed inside that slot. There is no global allocation of individual server identities here. The common agreement concerns how to request and transport an answer; the operator decides what the answer means.

Which server is allowed to say “me”?

NSID is explicitly non-transitive. A client asking a recursive resolver receives, if anything, the identifier of that resolver. The resolver can independently request NSID when making its own queries to authoritative servers. Those are different exchanges, with different responding parties.

An authoritative identifier is not passed back as though it were the recursive resolver's answer to the client's identity request. Nor does NSID assemble a chain of all servers consulted during resolution. “Hop-by-hop” here describes DNS transaction endpoints, not a procession of IP routers attaching labels to a packet.

The later EDNS specification, RFC 6891 of April 2013, reinforces the boundary. OPT carries control information for a particular question-and-answer transaction, not zone data. It is not to be cached, forwarded or stored in master files as an ordinary record.

Together these rules have a useful consequence: a recursive resolver can return cached resource records while its NSID describes the instance responding now. That identifier is not evidence of which authoritative instance supplied the cached data earlier. The distinction keeps a present diagnostic observation from masquerading as a historical certificate.

An unreadable value that must survive copying

The payload is an opaque byte string. It may resemble a hostname, but clients cannot assume that it is one. It may be random, encoded or meaningful only against an operator's private records. The specification does not require a city code, hardware serial number or common naming grammar.

Instead, RFC 5001 is unusually careful about presentation. Read and write the value as hexadecimal, two digits per octet. Compare the underlying binary data. Do not assume a zero byte ends the string. Leading zeroes and embedded zeroes are part of the evidence, not visual clutter to discard.

An interface may offer a readable preview, but that cannot replace an exact representation. Changing the case of hexadecimal letters can preserve the same bytes; changing case or Unicode normalization within a decoded payload may not. Treating an arbitrary identifier as a DNS name would silently impose rules that the protocol deliberately withheld.

This is a modest but important allocation of work. A user need not understand the identifier to copy it into a support ticket. The operator who receives the ticket can interpret it. Exact transfer allows local naming freedom without making every observer learn every local convention.

Opaque does not mean secret or true

Local choice has costs. A maintenance address can reveal a node the anycast service otherwise obscures. Hashing an IPv4 address does not create a large secret: its input space is still only 32 bits. Predictable hostnames can also be guessed. Persistent random values need a mapping and a continuity policy; a fleet configured with one identical value loses the ability to distinguish its members.

Changing identifiers need not prove a route change or a new machine. Equal identifiers need not establish one enduring physical device. Such conclusions depend on the operator's assignment rules, which are outside the wire format. The protocol carries a diagnostic reference, not an independent guarantee that its author has assigned it sensibly.

RFC 5001 discusses signed or encrypted values without supplying a complete security design. A static blob can still be replayed. It also places NSID outside DNSSEC protection as such: authenticating a resource-record set does not automatically authenticate adjacent channel information. The document mentions channel protection such as TSIG when integrity is required. That historical boundary is not a claim that ordinary NSID exchanges are authenticated.

Two switches, not one chain-wide setting

The captured BIND configuration reference, identifying itself as version 9.20.27, separates server-id from request-nsid. The former controls the local identifier returned through NSID or ID.SERVER and defaults to none; using the hostname is an option. The latter asks for upstream identifiers during iterative queries and defaults to no. Returned upstream values can be logged in the nsid category.

This distinction is the protocol's scope expressed as configuration. Disclosing oneself downstream and asking another server upstream are independent decisions. The BIND manual pages document dig +nsid as a way to include the request. The command neither compels a reply nor makes returned bytes trustworthy. Documentation establishes an implementation path, not a census of enabled production systems.

There is also a physical cost to extra diagnostic bytes. NSID can bring a response up against truncation limits, but it does not change DNS truncation rules or require truncation merely to accommodate the optional identifier. A diagnostic aid should not be confused with a guarantee of delivery or allowed to obscure the ordinary answer's purpose.

NSID's achievement was to make the right evidence travel with the right exchange. It did not unify all server names or certify the network behind them. A smaller promise was enough to remove a consequential ambiguity.