On 2011-01-17, at 23:46, Ralph Droms wrote:
> FYI; review and comment requested...
Comments below, in-line.
> Special-Use Domain Names
> draft-cheshire-dnsext-special-names-01
>
> 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 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
Network Working Group J. Abley
Internet-Draft ICANN
Intended status: BCP October 18, 2010
Expires: April 21, 2011
Reserved Domain Names
draft-jabley-reserved-domain-names-00
Abstract
The Domain Name System (DNS) makes use of a hierarchical naming
scheme. The validity of a particular name in the DNS is governed by
protocol, operational and policy considerations.
The IETF has identified particular domain names to have special
considerations associated with their use. These domain names have
been identified in various documents in the RFC series. This
document describes the creation of an IANA registry to catalogue such
domain names and provides direction about how this registry should be
maintained.
This document does not identify any new domain name as having special
considerations associated with its use.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Abley Expires April 21, 2011 [Page 1]
Internet-Draft Reserved Domain Names October 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abley Expires April 21, 2011 [Page 2]
Internet-Draft Reserved Domain Names October 2010
1. Introduction
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
The DNS makes use of a hierarchical naming scheme. The validity of a
particular name in the DNS is governed by protocol, operational and
policy considerations.
The IETF has identified particular domain names to have special
considerations associated with their use. Examples of such domain
names are "LOCALHOST" and "EXAMPLE.ORG" which are discussed in
[RFC2606], and "LOCAL" and "254.169.IN-ADDR.ARPA" which are described
in [I-D.cheshire-dnsext-multicastdns].
This document describes the creation of an IANA registry to catalogue
such domain names and provides direction about how this registry
should be maintained.
This document does not identify any new domain name as having special
considerations associated with its use.
Abley Expires April 21, 2011 [Page 3]
Internet-Draft Reserved Domain Names October 2010
2. IANA Considerations
This document directs the IANA to create a registry as follows:
+-------------------------+--------------------------------------+
| Parameter | Value |
+-------------------------+--------------------------------------+
| Registry Name | Reserved Domain Names |
| | |
| Reference | This document (RFCXXXX) |
| | |
| Registration Procedures | Document Published with IAB Approval |
+-------------------------+--------------------------------------+
The initial registry contents should be as follows:
+-------------+-----------------------------------------+-----------+
| Domain Name | Description | Reference |
+-------------+-----------------------------------------+-----------+
| TEST | Recommended for use in testing of | [RFC2606] |
| | current or new DNS related code | |
| | | |
| EXAMPLE | Recommended for use in documentation or | [RFC2606] |
| | as examples | |
| | | |
| INVALID | Recommended for use in documentation or | [RFC2606] |
| | as examples | |
| | | |
| LOCALHOST | Traditionally statically defined in | [RFC2606] |
| | host DNS implementations as having an A | |
| | record pointing to the loop back IP | |
| | address, and reserved for such use | |
| | | |
| EXAMPLE.COM | Available for use as examples | [RFC2606] |
| | | |
| EXAMPLE.NET | Available for use as examples | [RFC2606] |
| | | |
| EXAMPLE.ORG | Available for use as examples | [RFC2606] |
+-------------+-----------------------------------------+-----------+
Abley Expires April 21, 2011 [Page 4]
Internet-Draft Reserved Domain Names October 2010
3. Security Considerations
This document poses no new security issues.
Abley Expires April 21, 2011 [Page 5]
Internet-Draft Reserved Domain Names October 2010
4. Informative References
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-11 (work in progress),
March 2010.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
Abley Expires April 21, 2011 [Page 6]
Internet-Draft Reserved Domain Names October 2010
Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication.
A.1. Change History
00 Initial draft.
Abley Expires April 21, 2011 [Page 7]
Internet-Draft Reserved Domain Names October 2010
Author's Address
Joe Abley
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
USA
Phone: +1 519 670 9327
Email: joe.ab...@icann.org
Abley Expires April 21, 2011 [Page 8]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
