DNS Name Server Identifier (NSID) Option
Extracted elements (17)
NSID is strictly hop-by-hop rather than transitive. A transitive variant allowing stub resolvers to learn which authoritative server answered a recursive query would have more complex semantics and is left for future work.
The NSID payload is defined as an opaque byte string because no single format satisfies all operators: using a real name, real IP, hash, probabilistically unique ID, signed blob, or arbitrary string each has distinct tradeoffs in privacy, debuggability, and operational complexity. Leaving the choice to implementors and operators accommodates all use cases.
The presentation format uses hexadecimal strings rather than text because NSID payloads are binary data, and hex is unambiguous and robust for cut-and-paste into email or web forms, avoiding the complexity of internationalized text handling.
The recommended default NSID payload for operators concerned about disclosing unicast addresses is the raw binary representation of a probabilistically unique random number. Operators unconcerned about disclosure may use the raw binary of a unicast address, but only via explicit configuration.
Adding the NSID option to a response may trigger DNS message truncation. This specification does not change truncation rules; including NSID in a response is always optional, so servers are never required to truncate to include it.
Because a resolver requesting NSID necessarily supports EDNS, it can use the 'sender's UDP payload size' field of the OPT pseudo-RR to signal a large enough receive buffer to make truncation unlikely.
NSID semantics are not transitive: an NSID request in a query asks only the directly queried server to identify itself. A recursive name server receiving an NSID request identifies itself, not the authoritative servers it queries on the client's behalf.
A name server MUST ignore any NSID payload data that might be present in the query message.
A name server MUST NOT send an NSID option back to a resolver which did not request it. The NSID option is not transitive.
A resolver signals its desire for name server identification by sending an empty NSID option in an EDNS OPT pseudo-RR in the query message. The resolver MUST NOT include any NSID payload data in the query message.
Copy operations MUST NOT assume that the raw NSID payload is null-terminated.
User interfaces MUST read and write the contents of the NSID option as a sequence of hexadecimal digits, two digits per payload octet. Any comparison between NSID payloads MUST be a comparison of the raw binary data.
The NSID option is an EDNS OPT pseudo-RR option with OPTION-CODE 3. The OPTION-DATA is an opaque byte string whose semantics are deliberately left outside the protocol.
IANA allocated EDNS option code 3 for the NSID option.
NSID is a channel signaling mechanism outside the scope of DNSSEC. Applications requiring integrity protection for NSID data must use a channel security mechanism such as TSIG. Some NSID payload types (e.g., unicast addresses) are security-sensitive in anycast deployments and operators must choose payloads carefully.
Signed or encrypted NSID payload variants require detailed security analysis beyond the scope of this document. Static encrypted blobs are subject to replay attacks. Implementors should seek competent advice before attempting to use these payload types.
The NSID EDNS option carries OPTION-CODE 3 and an OPTION-DATA field that is an opaque byte string of variable length. In queries the OPTION-DATA is empty (zero length); in responses it contains the server-chosen identifier.