Put NSID inside an EDNS option
02NSID is an EDNS option with code3, carried inside the OPT pseudo-record in a DNS message’s Additional section.
Separate malformed-client example: query dataDE AD violates the resolver MUST NOT. The server MUST ignore that data; it does not echo or interpret it as a requested ID.
Source for this drawing: RFC 5001 · Read RFC section 2.3 ↗
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.
The requesting resolver MUST NOT include NSID payload data: the NSID query option has OPTION-LENGTH0. The server MUST ignore any NSID payload data present in a query (RFC5001 §§2.1–2.2).
- The requesting resolver MUST NOT include NSID payload data: the NSID query option has OPTION-LENGTH0. The server MUST ignore any NSID payload data present in a query (RFC5001 §§2.1–2.2).
- OPTION-CODE is3. The16-bit OPTION-LENGTH counts only OPTION-DATA octets. Example response0003 0003 4100FF has three payload bytes, not three text characters (RFC5001 §2.3; RFC6891 §6.1.2).
- OPT is type41; NSID code3 is nested inside its RDATA, not a new DNS RR type. An OPT response can exist without this particular optional NSID option.
- The isolated option byte model does not validate a complete OPT RDLEN, DNS packet size, compression, transport or any live server.
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 ↗