When you query 8.8.8.8, you are not really talking to a server — you are talking to one of hundreds of anycast instances scattered across the planet. They all share the same IP address. So when something goes wrong — a stale record, a lying resolver, a DNSSEC validation failure that only happens "sometimes" — how do you tell the operator which physical box misbehaved? RFC 5001 answers that with a tiny but indispensable mechanism: the NSID option.

The problem. By the mid-2000s, anycast had become the dominant deployment model for DNS. The root servers, TLD servers, and large public resolvers all advertised single IP addresses served by dozens or hundreds of distinct instances. Traditional debugging tools were useless: a traceroute told you the path, not the identity of the endpoint, and the path could change mid-flight. Operators were reduced to guessing — or to running ad-hoc CHAOS-class queries like hostname.bind and id.server, which were unstandardized, frequently disabled, and required separate queries that might hit different instances than your real query.

The design. Rob Austein's solution piggybacks on EDNS(0) (RFC 6891's predecessor, RFC 2671). The client adds an OPT pseudo-RR to its query containing an NSID option with an empty payload — basically asking, "tell me who you are." A server that supports NSID echoes back the same option in its response, populated with an opaque byte string identifying the responding instance. The contents are deliberately unstructured: it might be a hostname, a datacenter code, a serial number, or a cryptic identifier like gpdns-iad. The RFC explicitly refuses to mandate format — operators know what's useful to them.

Why this design is clever:

• Atomicity. The identifier travels with the actual answer, in the same packet. There is no race where you query one instance for an answer and another for its identity.
• Opt-in on both sides. Clients only get NSID if they ask; servers only respond if configured. No bandwidth wasted on uninterested parties.
• Opaque payload. By refusing to standardize the format, the RFC sidesteps decades of bikeshedding and lets each operator encode what they need.
• No privacy leak about the client. The identifier describes the server, not the querier.

Why it matters today. Open up dig and try dig +nsid @1.1.1.1 example.com. You'll see something like NSID: 67 72 64 33 32 ("grd32") — Cloudflare's identifier for whichever PoP answered you. Google, Quad9, the root server operators, and every major authoritative provider supports it. It is the foundation of essentially every modern DNS debugging workflow:

• RIPE Atlas measurements use NSID to map which root-server instance each probe reaches — producing those beautiful global anycast heatmaps.
• DNS-OARC incident analysis relies on NSID to correlate failures to specific instances during outages.
• Resolver operators use it to identify a misbehaving cache node in a cluster behind a load balancer.
• DNSSEC validation failures become tractable: "which of your 47 anycast sites is serving the bogus RRSIG?"

A quirky note. NSID predates and arguably inspired the broader pattern of "let the server identify itself in-band" that you see in HTTP's Server header, TLS server certificates, and even AWS's x-amz-request-id. But unlike those, NSID was designed from the start with anycast and operator privacy in mind — the identifier deliberately conveys operational identity, not necessarily a routable hostname. A server can call itself node-42 and that is fine; the operator decodes the mapping internally.