Visual RFC.
ALL RFCs / RFC 2606
Read the RFC ↗
RFC 2606 / RESERVED DOMAIN NAMES

Separate API handling from caching-server handling

04

RFC 6761 updates the reservation with layer-specific handling. A name-resolution API is the application-facing lookup interface; a caching server is a separate DNS role.

DIAGRAMRead RFC section 2 ↗
RFC 2606 · § 2EXAMPLE
3 / 3
Separate API handling from caching-server handlingThree independent examples of RFC6761 SHOULD guidance. A .test query passes API to configured cache, whose default is negative, with private configuration exception noted. A separate .invalid query gets immediate API negative response and a stopped cache path. A separate localhost A/AAAA address query gets local loopback and a stopped cache path. These do not simulate real resolver behavior.Later guidance: RFC 6761app.localhostLookup APICacheSHOULD NOT query cacheA / AAAA: loopbackOther types: negativeAPI behavior here is SHOULD, not MUST
03
A localhost address lookup returns locally.

Separate app.localhost address-query case: the API follows the loopback recommendation. Other query types get negative responses. This models guidance, not an actual lookup or verified behavior of this browser.

Source for this drawing: RFC 2606 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 1034 DNS RFC 1918 Private IPv4 addresses

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC 2606 §§2–4RFC 6761 §§6.2–6.5

RFC 6761 formally updates RFC 2606 and records special-use names with separate user, application, API, caching, authoritative-server and registrar considerations. It does not add another TLD to the four-name list in RFC 2606.

Read the updated RFC section ↗
KEY POINT

For .test, APIs SHOULD use the configured caching server. Caching servers SHOULD generate immediate negative responses by default and SHOULD offer an option, disabled by default, for upstream private-test resolution; explicitly configured authoritative test data can be positive.

  • For .test, APIs SHOULD use the configured caching server. Caching servers SHOULD generate immediate negative responses by default and SHOULD offer an option, disabled by default, for upstream private-test resolution; explicitly configured authoritative test data can be positive.
  • For .invalid, APIs SHOULD return immediate negative responses and SHOULD NOT send queries to the configured cache. Caching servers SHOULD return immediate NXDOMAIN: the DNS response that says the name does not exist.
  • For .localhost, APIs SHOULD return loopback addresses for IPv4/IPv6 address queries and negative responses for other types, and SHOULD NOT query the configured cache. Applications MAY recognize localhost names themselves. These are SHOULD/MAY statements, not invented universal MUSTs.
DETAILS

Updated guidance: RFC 6761 §§6.2–6.5. Users MAY assume .invalid yields NXDOMAIN, while the implementation rules quoted here retain SHOULD. Example domains have ordinary resolution handling rather than the .invalid or .localhost API shortcut. This is a bounded teaching model, not an exhaustive resolver implementation.

Read the RFC section ↗

All chapters in RFC 2606

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗