Visual RFC.
ALL RFCs / RFC 5001
Read the RFC ↗

RFC 5001 / START HERE

DNS server identity hints, before the details

NSID: Name Server Identifier

A DNS resolver can ask the server answering its query for an optional identifier. The server chooses a string of bytes and, if it honors the request, includes it in that same response.

Start the guide See the 6 chapters ↓

The idea in one picture

  1. Ask this responder

  2. Receive opaque bytes

  3. Record this response

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

A shared DNS service address can reach several machines through anycast or load balancing. A later diagnostic query might reach a different machine, so a hint attached to the original response is more useful. NSID does not define a globally unique or authenticated server identity.

A familiar example

An operator sees different answers from a shared DNS address. Response1 carries fictional identifierA1; a later response carriesB2. The operator can interpret those configured values while remembering that each hint identifies its immediate responder and may be omitted.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

DNS wireRFC 1035 · beginner overview ↗EDNSRFC 6891 · beginner overview ↗DNSSECRFC 4033 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Bind an identity hint to this responseOne shared service address can reach several DNS server instances. A later query need not reach the instance that answered the earlier one.
  2. Put NSID inside an EDNS optionNSID is an EDNS option with code3, carried inside the OPT pseudo-record in a DNS message’s Additional section.
  3. Keep recursive hops separateAn NSID request asks the server that receives it to identify itself. A recursive server’s upstream request is an independent transaction.
  4. Display and compare exact bytesUser interfaces use hexadecimal so every binary octet, including a zero byte, can survive copy and paste.
  5. Respect optional replies and size limitsRequesting NSID does not guarantee an identifier. Its optional response data also consumes part of the message size budget.
  6. Limit disclosure and protect the channelAn opaque identifier can still reveal sensitive information. Ordinary DNSSEC validation does not authenticate this channel signal.
Start with chapter one →

This introduction explains RFC 5001 (2007). Read the original RFC ↗