Bind an identity hint to this response
01One shared service address can reach several DNS server instances. A later query need not reach the instance that answered the earlier one.
Record response1→A1 and response2→B2. Treat these as operator-defined observations, not proof of host identity, location or authenticity.
Source for this drawing: RFC 5001 · Read RFC section 1 ↗
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.
A resolver requests NSID in the query so an honoring server can include its own identifier in that same response. A follow-up diagnostic query can reach a different instance.
- A resolver requests NSID in the query so an honoring server can include its own identifier in that same response. A follow-up diagnostic query can reach a different instance.
- Anycast and load balancing are motivations, not requirements for using NSID. NSID is neither the DNS transaction ID nor a universally unique or stable server identity.
- Chosen A1/B2 values are fictional payload bytes. Their meaning and persistence are operator choices, not names or locations inferred by this protocol.
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 ↗