Display and compare exact bytes
04User interfaces use hexadecimal so every binary octet, including a zero byte, can survive copy and paste.
Raw41 and4100 are unequal payloads. Do not discard the final00, trim bytes, or compare only until the first zero.
Source for this drawing: RFC 5001 · Read RFC section 2.4 ↗
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.
Interfaces MUST read and write NSID as hexadecimal digits, two digits per payload octet. Any comparison MUST use raw binary data, not an inferred hostname, address or text string.
- Interfaces MUST read and write NSID as hexadecimal digits, two digits per payload octet. Any comparison MUST use raw binary data, not an inferred hostname, address or text string.
- Copying MUST NOT assume a null-terminated payload. In example41 00 FF, the zero byte does not end the identifier; FF must survive too.
- Uppercase/lowercase hex glyphs can represent the same bytes. Do not case-fold payload bytes themselves or assume Unicode/text normalization; resemblance to text is only a convenience.
- This strict teaching decoder accepts an even sequence of hex digits, including empty. Tool-specific punctuation/whitespace syntax is not standardized here.
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 ↗