Skip to main content

Special-Use Domain Names
RFC 6761

Revision differences

Document history

Date Rev. By Action
2017-03-16
03 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
03 (System) Notify list changed from cheshire@apple.com, marc@apple.com, draft-cheshire-dnsext-special-names@ietf.org to (None)
2013-02-21
03 (System) IANA registries were updated to include RFC6761
2013-02-20
03 (System) RFC published
2013-02-12
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48-DONE
2012-09-19
03 Stuart Cheshire New version available: draft-cheshire-dnsext-special-names-03.txt
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-13
02 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-08-12
02 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-08-12
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-08-10
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-08-10
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-07-06
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-07-02
02 (System) IANA Action state changed to In Progress
2012-06-28
02 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-06-28
02 Cindy Morgan State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2012-06-28
02 Cindy Morgan IESG has approved the document
2012-06-28
02 Cindy Morgan Closed "Approve" ballot
2012-06-28
02 Cindy Morgan Ballot approval text was generated
2012-06-28
02 Cindy Morgan Ballot approval text was generated
2012-06-28
02 Cindy Morgan Ballot writeup was changed
2012-06-28
02 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-06-28
02 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2012-05-11
02 Ralph Droms Ballot comment and discuss text updated for Ralph Droms
2012-05-08
02 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2011-12-20
02 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-12-19
02 Ralph Droms [Ballot comment]
IANA Discuss cleared based on IANA review of rev -02.
2011-12-19
02 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to Yes from Discuss
2011-12-13
02 Stephen Farrell
[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified …
[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified in the introduction:

  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].

Without those entries (or a plan to create those entries), I don't quite see
that this document accomplishes anything.
2011-12-13
02 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-12-11
02 Sean Turner [Ballot discuss]
This updated (based on -02) - I'll retain the #ing.

#4) I'm also going to hold a placeholder discuss for IANA.
2011-12-09
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-09
02 (System) New version available: draft-cheshire-dnsext-special-names-02.txt
2011-03-31
02 Stephen Farrell
[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified …
[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified in the introduction:

  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].

Without those entries (or a plan to create those entries), I don't quite see
that this document accomplishes anything.
2011-03-31
02 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-03-30
02 Ralph Droms
[Ballot discuss]
I'm holding this DISCUSS for IANA.

From IANA Considerations:

  IANA needs to create a new registry of Special-Use Domain Names.

  When …
[Ballot discuss]
I'm holding this DISCUSS for IANA.

From 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.


We strongly feel that IANA should not be the ones “verifying” that the
“Domain Name Reservation Considerations” is in the document and that
it contains the information for the “seven categories”.  It is a
question of who is responsible for verifying the information.  I don’t
think it is IANA.

Since a Standards Action is required to register a special name, this
document should say that the RFC requesting the special-use domain
should contain the domain name reservation considerations section.
The IANA section should just contain the request for the special
domain.
2011-03-30
02 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to Discuss from Yes
2011-02-17
02 Cindy Morgan Removed from agenda for telechat
2011-02-17
02 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-02-17
02 Sean Turner
[Ballot discuss]
This updated - I'll retain the #.

The first one is a DISCUSS-DISCUSS

#2) Use of the word "needs" in Section 3 seems …
[Ballot discuss]
This updated - I'll retain the #.

The first one is a DISCUSS-DISCUSS

#2) Use of the word "needs" in Section 3 seems like it ought to be MUST.  Is there a time when you wouldn't do the items it suggests?

#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?

#4) I'm also going to hold a placeholder discuss for IANA.
2011-02-17
02 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-02-17
02 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded
2011-02-16
02 Tim Polk [Ballot comment]
last sentence of section 2: "reservation of a Special-Use Domain Names" - s/Names/Name/
2011-02-16
02 Tim Polk
[Ballot discuss]
I expected the document to seed the registry with entries (at a minimum) for the special domain names identified in the introduction:

  …
[Ballot discuss]
I expected the document to seed the registry with entries (at a minimum) for the special domain names identified in the introduction:

  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].

Without those entries (or a plan to create those entries), I don't quite see that this document accomplishes anything.
2011-02-16
02 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded
2011-02-16
02 Sean Turner
[Ballot comment]
1) +1 to including values.  Maybe some from http://www.ietf.org/mail-archive/web/dnsext/current/msg10557.html ?

2) There really aren't any security considerations.  Could move the last sentence to …
[Ballot comment]
1) +1 to including values.  Maybe some from http://www.ietf.org/mail-archive/web/dnsext/current/msg10557.html ?

2) There really aren't any security considerations.  Could move the last sentence to section 4.
2011-02-16
02 Sean Turner
[Ballot discuss]
The first one is a DISCUSS-DISCUSS

#1) Is adding a new required section in an RFC done this in way?  It seems like …
[Ballot discuss]
The first one is a DISCUSS-DISCUSS

#1) Is adding a new required section in an RFC done this in way?  It seems like this ought to come from a WG or be part of the style guide?

#2) Use of the word "needs" in Section 3 seems like it ought to be MUST.  Is there a time when you wouldn't do the items it suggests?

#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?
2011-02-16
02 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-02-16
02 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-02-16
02 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-02-16
02 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded
2011-02-15
02 Russ Housley [Ballot Position Update] New position, Yes, has been recorded
2011-02-15
02 Robert Sparks
[Ballot comment]
Thanks for this effort - I expect this registry (as long as its registration policy is Standards Action) to be a very useful …
[Ballot comment]
Thanks for this effort - I expect this registry (as long as its registration policy is Standards Action) to be a very useful tool.

Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request registration of .local (pointing to section 23 of that draft?)
2011-02-15
02 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded
2011-02-15
02 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded
2011-02-14
02 Peter Saint-Andre
[Ballot comment]
Although I do not object to publication of this document, I agree that it would be preferable for this document to seed the …
[Ballot comment]
Although I do not object to publication of this document, I agree that it would be preferable for this document to seed the registry with initial registrations.
2011-02-14
02 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-02-14
02 Ralph Droms State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-02-14
02 Dan Romascanu
[Ballot discuss]
The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I would like to see it addressed before approving this document:

o …
[Ballot discuss]
The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I would like to see it addressed before approving this document:

o In section 4, check step 2. Do algorithmically generated
  names fall into this category? If yes, these should be
  mentioned in the draft as well. There are a number of cases
  and deployments where names are generated on fly (by the
  end host application) using available execution/service
  environment context awareness, other information sources like
  certain hardware dongles/smartcards and specific suffixes.
  Those are in most cases treated differently in application
  software and occasionally also by the name resolution APIs
  and libs (reference to check step 3).

  If algorithmically generated names fall into special names
  category I see documenting those as a big challenge.. if
  existing legacy also needs to be documented under the newly
  created IANA registry.
2011-02-14
02 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-02-14
02 Alexey Melnikov
[Ballot comment]
I agree with a comment that this document should register existing special names in the registry, or make a more compelling argument about …
[Ballot comment]
I agree with a comment that this document should register existing special names in the registry, or make a more compelling argument about why the registry is needed.
2011-02-14
02 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-02-07
02 Amanda Baber
IANA understands that a single IANA action is required to be completed
upon approval of this document.

IANA will create a new registry for "Special …
IANA understands that a single IANA action is required to be completed
upon approval of this document.

IANA will create a new registry for "Special Use Domain Names." The
registry will consist of domain names and references to IETF Standards
Action documents that document the special meaning of the name. The
initial registry is empty.
Adding new entries to the registry for Special Use Domain Names requires
Standards Action.

IANA understands that this is the only action required upon approval of
this document.
2011-02-01
02 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Chris Lonvick.
2011-01-28
02 Magnus Westerlund Request for Last Call review by TSVDIR Completed. Reviewer: Magnus Westerlund.
2011-01-19
02 Lars Eggert Request for Last Call review by TSVDIR is assigned to Magnus Westerlund
2011-01-19
02 Lars Eggert Request for Last Call review by TSVDIR is assigned to Magnus Westerlund
2011-01-18
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2011-01-18
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2011-01-17
02 Cindy Morgan Last call sent
2011-01-17
02 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (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'
  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
ietf@ietf.org mailing lists by 2011-02-14. Exceptionally, comments may be
sent to iesg@ietf.org 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/
2011-01-17
02 Ralph Droms Placed on agenda for telechat - 2011-02-17
2011-01-17
02 Ralph Droms Last Call was requested
2011-01-17
02 Ralph Droms State changed to Last Call Requested from AD Evaluation.
2011-01-17
02 Ralph Droms Last Call text changed
2011-01-17
02 Ralph Droms Last Call text changed
2011-01-17
02 Ralph Droms Intended Status has been changed to Proposed Standard from None
2011-01-17
02 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2011-01-17
02 Ralph Droms Ballot has been issued
2011-01-17
02 Ralph Droms Created "Approve" ballot
2011-01-17
02 (System) Ballot writeup text was added
2011-01-17
02 (System) Last call text was added
2011-01-17
02 Ralph Droms
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

This document is being processed as an AD-sponsored individual
submission.  The authors consider the document ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

N/A.  The document will be reviewed by the dnsop and dnsext working
groups during IETF last call.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 
N/A

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?
Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
N/A

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  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.

  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.

    Working Group Summary

N/A.  This document is being processed as an AD-sponsored individual
submission.  The authors consider the document ready for publication.

    Document Quality

The document is short and clearly defines a new IANA registry for DNS
special-use names.
2011-01-17
02 Ralph Droms State changed to AD Evaluation from Publication Requested.
2011-01-17
02 Ralph Droms Draft added in state Publication Requested
2011-01-12
01 (System) New version available: draft-cheshire-dnsext-special-names-01.txt
2010-12-15
00 (System) New version available: draft-cheshire-dnsext-special-names-00.txt