Keep recursive hops separate
03An NSID request asks the server that receives it to identify itself. A recursive server’s upstream request is an independent transaction.
Separate client query has no NSID request. Even if the recursive server requests upstream NSID and receives A1, its response to this client MUST NOT include NSID.
Source for this drawing: RFC 5001 · Read RFC section 3.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
NSID is strictly hop-by-hop. A stub asking a recursive server for NSID asks for that recursive server’s identifier, not an authoritative server’s identifier (RFC5001 §§2.1–2.2/3.2).
- NSID is strictly hop-by-hop. A stub asking a recursive server for NSID asks for that recursive server’s identifier, not an authoritative server’s identifier (RFC5001 §§2.1–2.2/3.2).
- The recursive resolver MAY separately request an upstream server’s NSID in its own query. An upstream request does not require or authorize an NSID option in the downstream response.
- A server MUST NOT return an NSID option to a client that did not request it. Normal DNS answer resolution and optional per-hop NSID metadata are separate.
Fictional identifiers and documentation addresses. NSID is an optional, opaque, hop-by-hop debugging signal, not authentication or a DNS transaction ID. Diagrams are schematic; the byte model is not a complete DNS implementation.
Read the RFC section ↗