Summary

  • RFC 6761, published in February 2013, created the IANA Special-Use Domain Names registry and required a new special-use specification to answer seven separate questions about users, software, DNS infrastructure, operators and registrars.
  • The initial register combined earlier reserved names with reverse-mapping zones for private addresses. Their behavior is not uniform: localhost points address queries back to loopback, invalid calls for immediate negative answers, and private reverse names may be answered inside a local network.
  • RFC 8244 recorded the institutional catch in 2017: IETF and ICANN had no formal coordination procedure for these allocations, the boundary of “technical use” was unsettled, and parties could use names without asking either body. An IANA row records a designation; deployed behavior still has to be traced through software and operations.

A stamp is not a resolver

Picture a developer typing a sample hostname into a test program. The name has the shape of a regular DNS name. The program may hand it to a library; the library may send it to a recursive resolver; that resolver may consult an authoritative server. A registrar can meanwhile decide whether the name can be sold. Five different places can make a decision before the developer sees an answer. Printing “special” beside the name in a registry does not make those decisions identical.

This was the gap between RFC 2606 and the next generation of rules. In 1999, RFC 2606 reserved names for testing, examples, failure and local host use. It said why those names should not be ordinary registrations. It did not settle every implementation choice. RFC 6761 came in February 2013 and asked what special treatment meant at each layer. The old question was whether an invented name might collide with a live one. The new one was whose software had to prevent the collision, and how.

The 2013 document created the IANA Special-Use Domain Names registry. Its first entries included the names already reserved by RFC 2606 and private-address reverse-mapping zones. The register was an index to specifications. It did not run a resolver, change a user's browser or reconfigure a server by being published. A row directs the reader to a document where behavior can be defined; the running path begins elsewhere.

Seven desks, seven questions

RFC 6761 required a new special-use name to come through an IETF Standards Action or IESG Approval specification. That specification must identify the names receiving special treatment and include Domain Name Reservation Considerations. The considerations ask seven questions. Should a human recognize the name as special? Should an application? Should the name-resolution API or library? Should a caching DNS server? Should an authoritative DNS server? What must a DNS server operator understand? How should a registry or registrar handle a registration request?

The list is revealing because it does not order seven offices to do the same thing. It asks the future specification to explain which office should do what. An application could pass a name through unchanged while a recursive resolver answers locally. A library might short-circuit a query before it reaches a server. A registry might refuse registration even if a private network uses the same spelling for a local purpose. Those are different controls, at different points, with different evidence of success.

The private-address reverse zones make the distinction concrete. For names such as 10.in-addr.arpa, RFC 6761 says applications and name-resolution APIs should not recognize special handling and should issue ordinary queries to the configured caching server. The caching server, by default, should avoid asking upstream authoritative servers and respond locally; it may offer a configuration option for private networks that have their own authoritative answer. If a packet capture at the application shows a DNS query, that is not a failure of the special-use design. The design placed the decision further along the chain.

Other names put the decision elsewhere. For localhost address queries, RFC 6761 calls for APIs and caching servers to return loopback answers without wandering into the public DNS. For invalid, it calls for immediate negative responses. The familiar words “reserved name” conceal different instructions. They also conceal the point at which an operator can prove an instruction was followed. An IANA entry is one receipt. A local resolver trace is another.

The register accumulated unlike things

The IANA register now lists names as different as localhost, invalid, local, onion, home.arpa and private reverse zones, each with its own defining reference. The common column is designation, not a shared transport route. Some names are handled in DNS with special recursive behavior. Some signal local resolution. Some require a different application context altogether. RFC 6761 never said that every entry must be a top-level domain or that every entry must bypass DNS.

That breadth gave protocol designers a place to put a genuine special case. It also made the boundary attractive to anyone who wanted a name to be treated as special. A standards document can specify the desired behavior and register the name; it cannot, by itself, force every software stack to implement the behavior. Nor can a registry row prevent someone from having used the same string informally in a private system before the formal reservation arrives. The operator who has to debug a leak or collision faces packets and configurations, not the neat order of an IANA table.

The risk is clearest when a name escapes the context that gave it meaning. A developer sends a local name in a message; the recipient's machine has a different local context. The same bytes can lead to a different endpoint or no endpoint. RFC 8244 later used this kind of contextual mismatch to explain why special-use names are operational questions, not merely allocations. The name can travel. Its meaning may stay behind.

The 2017 audit of the naming desk

Four years after the registry was created, RFC 8244 published a problem statement. It did not replace RFC 6761 or offer a finished repair. It listed disputes that practice had exposed. IETF and ICANN had a liaison relationship, but no formal process for coordinating special-use allocations. The scope of “technical use” was not explicitly defined and lacked consensus. Both bodies had nominal roles in the namespace; neither could force an outside developer to seek permission before using a string.

The memo also described more mundane ways the system could get hurt. A locally used name might leak out of its intended network. An informal local use might later meet a formal allocation. Developers might not know a process existed, expect a refusal, or refuse the cost and delay of a different allocation route. The record does not prove which of these motives drove any named deployment. It does show why a registry procedure could be precise on paper and still meet an untidy namespace in the field.

That is the dry joke at the heart of the case. The Internet's name registry could tell a reviewer which names were special. It could not make all the relevant machines agree on what “special” meant, nor could it prevent a party outside the meeting room from using a name first. RFC 6761's seven desks were an attempt to make the consequences explicit before a name was added. RFC 8244 showed the desk arrangement itself had become a governance problem.

The official records establish the procedure, the initial entries and the later problem statement. To judge a named resolver or product, the missing proof is its dated configuration and query trace for a particular special-use name. Without that trace, the register proves designation, not the answer a user got. The next time a name seems to point nowhere, ask which desk was supposed to catch it.