Subject: [dns-dir] Fwd: Last Call: <draft-cheshire-dnsext-special-names-01.txt> (Special-Use Domain Names) to Proposed Standard

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Jan 2011 20:46:28 -0800

FYI; review and comment requested...

- Ralph

Begin forwarded message:

From: The IESG <[email-masked]>
Date: January 17, 2011 3:00:48 PM PST
To: IETF-Announce <[email-masked]>
Subject: Last Call: <draft-cheshire-dnsext-special-names-01.txt> (Special-Use Domain Names) to Proposed Standard

The IESG has received a request from an individual submitter to consider
the following document:
- 'Special-Use Domain Names'
 <draft-cheshire-dnsext-special-names-01.txt> as a Proposed Standard

  Abstract

  This document describes what it means to say that a DNS name is
  reserved for special use, when reserving such a name is appropriate,
  and the procedure for doing so.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-02-14. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/

No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 Jan 2011 10:08:48 -0500

> FYI; review and comment requested...

Comments below, in-line.

>                         Special-Use Domain Names
>                  draft-cheshire-dnsext-special-names-01
> 
> Abstract
> 

The acronym DNS should perhaps be expanded upon first use.

> 1.  Introduction
> 
>    Certain individual IP addresses and IP address ranges are treated
>    specially by network implementations, and consequently are not
>    suitable for use as unicast addresses. For example, IPv4 addresses
>    224.0.0.0 to 239.255.255.255 are multicast addresses [RFC2606], with
>    224.0.0.1 being the "all hosts" multicast address [RFC1112]
>    [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host"
>    address [RFC5735].
> 
>    Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
>    concept of reserved names, such as "example.com", "example.net", and
>    "example.org", or any name falling under the top level pseudo-domain
>    "invalid" [RFC2606]. However, "Reserved Top Level DNS Names"
>    [RFC2606] does not state whether implementations are expected to
>    treat such names differently, and if so, in what way.

DNS could be expanded again, upon first use outside the abstract, and a reference to 1034/1035 wouldn't hurt.

I don't think special-use names are a concept of the DNS in the protocol sense, but rather a set of administrative conventions. I think it's fairly clear that 2606 does not specify a protocol restriction (and, consequently, does not specify special handling in implementations); it doesn't update 1034/1035, and the rationale given in section 2 suggests normal handling in DNS software (it wouldn't be much of a test if your test cases were all handled differently from production, non-reserved names).

The idea of creating an IANA registry of special-use names for ease of reference by other documents seems worthwhile, however.

> 2.  Applicability
> 
>    When IP multicast was created [RFC1112], implementations had to be
>    updated to understand what a multicast address means and what to do
>    with it. Adding IP multicast to a networking stack entailed more than
>    merely adding the right routing table entries for those addresses.
>    Moreover, supporting IP multicast entails some level of commonality
>    that is consistent across all conformant hosts, independent of what
>    networks those hosts may be connected to. While it is possible to
>    build a private isolated network using whatever valid unicast IP
>    addresses and routing topology you choose (regardless of whether
>    those unicast IP addresses are already in use by other hosts on the
>    public Internet) the IPv4 multicast address 224.0.0.1 is always the
>    "all hosts" multicast address and that's not a local decision.

The examples above are all those in which special implementation decisions are required for handling special-use addresses. That covers part of the story, but...

>    Similarly, if a domain name has special properties that affect the
>    way hardware and software implementations handle the name, which
>    apply universally regardless of what network the implementation may
>    be connected to, then that may be a candidate for having the IETF
>    declare the name to be a Special-Use Domain Name and specify what
>    special treatment implementations should give to that name. If
>    declaring a given name to be special would result in no change to any
>    implementations, then that suggests that the name may not be special
>    in any material way, and it may be more appropriate to use the
>    existing DNS mechanisms [RFC1034] to provide the desired delegation,
>    data, or lack-of-data for the name in question. Where the desired
>    behaviour can be achieved via the existing domain name registration
>    processes, that process should be used. Reservation of a Special-Use
>    Domain Names is not a mechanism for circumventing normal domain name
>    registration processes.

... I disagree with the characterisation that follows. Just because there is no intended special handling required for INVALID as a TLD doesn't make INVALID less special in the operational sense; implications remain for root zone management (i.e. the label INVALID should not appear) that can't be signalled using resource records. EXAMPLE.COM and friends are delegated, and require no special handling in DNS software, but those names remain special in the sense that they have specific application in documentation.

> 3.  Procedure
> 
>    If it is determined that special handling of a name is required in
>    order to implement some desired new functionality, then an IETF
>    "Standards Action" RFC [RFC5226] needs to be published describing the
>    new functionality, and:

If the criteria for expansion of the IANA registry is a standards action, then that detail belongs in the IANA Considerations section. See below for more on that.

>     o The RFC needs to state how implementations determine that the
>       special handling is required for any given name. This is typically
>       done by stating that any fully-qualified domain names ending in a
>       certain suffix (i.e. falling within a specified parent pseudo-
>       domain) will receive the special behaviour. In effect this carves
>       off a sub-tree of the DNS namespace in which the modified name
>       treatment rules apply, analogous to how IP multicast [RFC1112] or
>       IP link-local addresses [RFC3927] [RFC4862] carve off chunks of
>       the IP address space in which their respective modified address
>       treatment rules apply.

I think the description above is largely implicit in the word "domain", which means a sub-tree of the namespace anchored at a particular domain name.

>     o The RFC needs to state, in each of the seven categories below,
>       what special treatment, if any, is to be applied. If the answer in
>       all seven categories is "none", then possibly no special treatment
>       is required and requesting reservation of a Special-Use Domain
>       Name may not be appropriate.

This direction contains vaguely normative-sounding language ("needs") but it's not clear what that means in practice. I think this advice cannot be normative, but really seeks to give guidance much as RFC 3552 and RFC 2434 do. This document would be easier to put in context if it did similarly, I think. If there are hard requirements for updating the IANA registry that this document also specifies be created then they belong in the IANA Considerations section, since in effect they are directions to the IANA for maintaining that registry. The text which follows in section 4 looks like guidance to me, however.

> 4.  Domain Name Reservation Considerations
> 
>    An IETF "Standards Action" RFC specifying some new naming behaviour,
>    which requires a Special-Use Domain Name be reserved to implement
>    this desired new behaviour, needs to contain a "Domain Name
>    Reservation Considerations" section giving answers in the following
>    seven categories:

I am not sure that instantiating a new named document section is practical or necessary, and certainly seems destined to delay this document's progress as there's little recent precedent for it. Modifying the review and publication process for the RFC Editor will likely also require IAB review.

Most of the considerations that are described in the rest of this section look entirely reasonable, but perhaps it's not an exhaustive list. There's no discussion of the applicability of DNSSEC for the domains concerned, for example -- it might be beneficial for some applications to specify that zones not be signed, for some reason, or that the zone in which a definitively non-existent name does not exist is signed in order to provide cryptographic confidence in its non-existence.

This one, however, touches on policy that I might argue is effectively outside the realm of IETF specifications:

>    7. DNS Registrars:
> 
>       How should DNS Registrars treat requests to register this reserved
>       domain name? Should such requests be denied? Should such requests
>       be allowed, but only to a specially-designated entity? (For
>       example, the name "www.example.org" is reserved for documentation
>       examples and is not available for registration; however, the name
>       is in fact registered; and there is even a web site at that name,
>       which states circularly that the name is reserved for use in
>       documentation and cannot be registered!)

EXAMPLE.ORG is in fact reserved as described; the implementation of that reservation is an entry in the ORG registry, but the effect is as intended.

Domain Name:EXAMPLE.ORG
Created On:31-Aug-1995 04:00:00 UTC
Last Updated On:27-Jul-2010 20:57:51 UTC
Expiration Date:30-Aug-2010 04:00:00 UTC
Sponsoring Registrar:Internet Assigned Numbers Authority (IANA) (R193-LROR)
Status:DELETE PROHIBITED
Status:RENEW PROHIBITED
Status:TRANSFER PROHIBITED
Status:UPDATE PROHIBITED

> 5.  Security Considerations
> 
>    This document outlines the circumstances in which reserving a domain
>    name for special-use is appropriate, and the procedure for having
>    that Special-Use Domain Name recorded by IANA. Any document
>    requesting such a Special-Use Domain Name needs to contain an
>    appropriate "Security Considerations" section which describes any
>    security issues relevant to that special use.

This seems like an additional guideline that would more usefully belong in section 4. This document doesn't seem to me to have any security considerations, but a back-reference to guidance in section 4 doesn't seem unreasonable.

> 6.  IANA Considerations
> 
>    IANA needs to create a new registry of Special-Use Domain Names.
> 
>    When IANA receives a request to record a new "Special-Use Domain
>    Name" it should verify that the IETF "Standards Action" RFC [RFC5226]
>    includes the required "Domain Name Reservation Considerations"
>    section stating how the special meaning of this name affects the
>    behaviour of hardware, software, and humans in the seven categories,
>    and if so, record in the registry the Special-Use Domain Name and a
>    reference to the RFC that documents it.

I don't pretend to speak authoritatively for Michelle and her team, but this seems almost unimplementable as-written. It would be much easier for IANA staff to handle this direction if it included more explicit instructions such as specifying the registry name and the circumstances in which entries in the registry are to be added, deleted and changed, and gave clearer instructions (rows, columns) on how the registry was to be created. An initial set of data for the registry to contain would also be useful to mention.

For what it's worth I drafted a document some time ago with similar objectives, but without the useful guidance that this document includes. I've attached a copy to further illustrate my thoughts above. Perhaps it's not unreasonable to split the content of this document into two I-Ds, one which specifies the registry and a second which gives guidance to future document authors who seek to make use of it.

Joe

---

From: Florian Weimer <[email-masked]>
Date: Tue, 18 Jan 2011 15:17:42 +0000

* Joe Abley:

> I don't think special-use names are a concept of the DNS in the
> protocol sense, but rather a set of administrative conventions.

LOCAL. is very much protocol-enshrined, but I think it has been
reserved neither by IETF nor IANA.  Would any other reserved name
share a similar fate?  Then you might be right in the sense that the
IETF cannot set aside names for use at the protocol level.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 Jan 2011 10:20:56 -0500

> IETF cannot set aside names for use at the protocol level.

You're right. I was actually referring to special-use names which have been specified at the IETF to date rather than those that are in the process of being specified, but that wasn't clear in the words I used.

(I appreciate that in the sense of widespread deployment and implementation bonjour is clearly extremely specified, but in an IETF context the work is still ongoing, I think).

Joe