On 8 Jan, 2014, at 10:18, Suzanne Woolf <[email protected]> wrote:
> Colleagues,
>
> This new internet-draft is another request for additions to the RFC 6761
> special names registry, this time motivated by an interest in reserving the
> names most commonly found in recent analysis of TLDs in private name spaces.
> The special names registration would serve to minimize the chances of
> collision between private and public DNS namespaces by keeping these names
> unassigned in the public namespace.
>
> In addition to discussion on the merits of this specific request, I would
> expect the IESG to be interested in any new aspects this request brings up to
> the discussion we were already having on the p2p special names draft, and the
> usability and scalability of the process in RFC 6761.
I think the goal of the draft is worthy, but there are some details to work out:
1. The draft states that eight TLDs are to be designated “Special Use”, but
doesn’t actually say for any of them *what* the special use is. For example, I
know what “localhost” means; I know what it does and how to use it (it’s a
synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use
it? The intent of RFC 6761 is that the seven Domain Name Reservation
Considerations are a required *part* of any specification that is documenting
something that requires some special name use, analogous to how all RFC’s have
a “Security Considerations” section. But you wouldn’t write an RFC that was
only a “Security Considerations” section, and a specification that is *only* a
“Domain Name Reservation Considerations” section is equally lacking. The
“Domain Name Reservation Considerations” section is a *supplement* to the
actual descriptive content of the specification, not a *substitute* for it. I
apologise that RFC 6761 did not set a good precedent in this regard. The
examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly
self-evident and previously documented elsewhere. In retrospect, RFC 6761
should have spelled out more clearly what they are all used for, to set a
better example to future documents.
2. The actual rules specified in the draft are incorrect. For example, for
“.home”:
Authors of name resolution APIs and libraries SHOULD restrict these
names to local resolution and SHOULD NOT allow queries for strings
that use these Special-Use Domain Names to be forwarded to the
public DNS for resolution.
Names like “voyager.home” have been used to refer to a user’s home NAT gateway.
The user can type “voyager.home” into their web browser and connect to their
home NAT gateway’s administration page. If (as the draft advocates) the client
machine’s name resolution library failed to send the “voyager.home” query to
its configured DNS server, then this usage would fail.
If we want to formalise the current usage of “.home” rather than break it, then
I suggest that something more similar to the rules for test names would be more
appropriate:
6.2. Domain Name Reservation Considerations for "test."
The domain "test.", and any names falling within ".test.", are
special in the following ways:
1. Users are free to use these test names as they would any other
domain names. However, since there is no central authority
responsible for use of test names, users SHOULD be aware that
these names are likely to yield different results on different
networks.
2. Application software SHOULD NOT recognize test names as special,
and SHOULD use test names as they would other domain names.
3. Name resolution APIs and libraries SHOULD NOT recognize test
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for test names to their
configured caching DNS server(s).
4. Caching DNS servers SHOULD recognize test names as special and
SHOULD NOT, by default, attempt to look up NS records for them,
or otherwise query authoritative DNS servers in an attempt to
resolve test names. Instead, caching DNS servers SHOULD, by
default, generate immediate negative responses for all such
queries. This is to avoid unnecessary load on the root name
servers and other name servers. Caching DNS servers SHOULD offer
a configuration option (disabled by default) to enable upstream
resolving of test names, for use in networks where test names are
known to be handled by an authoritative DNS server in said
private network.
5. Authoritative DNS servers SHOULD recognize test names as special
and SHOULD, by default, generate immediate negative responses for
all such queries, unless explicitly configured by the
administrator to give positive answers for test names.
6. DNS server operators SHOULD, if they are using test names,
configure their authoritative DNS servers to act as authoritative
for test names.
7. DNS Registries/Registrars MUST NOT grant requests to register
test names in the normal way to any person or entity. Test names
are reserved for use in private networks and fall outside the set
of names available for allocation by registries/registrars.
Attempting to allocate a test name as if it were a normal DNS
domain name will probably not work as desired, for reasons 4, 5,
and 6 above.
Stuart Cheshire
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
