Subject: Defining the existence of non-existent domains

From: John Levine <[email-masked]>
Date: 28 Dec 2009 01:16:47 -0000

It seems to me that if we think it's a good idea to specify a domain
name that doesn't exist, we're better off clarifying the status of the
ones already specified rather than inventing new ones.  Since the
people who manage .ARPA are the exact same people who manage the root
(IANA, operated by ICANN, in both cases), one is as likely to flake as
the other.

In fact, ICANN is quite aware of the reserved names list.  In the
current draft of the application process, one of the steps is to
check to see if a proposed name is one of the Reserved ones, in which
case the application fails immediately.  Here's their reserved list:

 AFRINIC      IANA-SERVERS NRO
 ALAC         ICANN        RFC-EDITOR
 APNIC        IESG         RIPE
 ARIN         IETF         ROOT-SERVERS
 ASO          INTERNIC     RSSAC
 CCNSO        INVALID      SSAC
 EXAMPLE*     IRTF         TEST*
 GAC          ISTF         TLD
 GNSO         LACNIC       WHOIS
 GTLD-SERVERS LOCAL        WWW
 IAB          LOCALHOST
 IANA         NIC

 *Note that in addition to the above strings, ICANN will reserve
 translations of the terms "test" and "example" in multiple
 languages. The remainder of the strings are reserved only in the form
 included above.

(That's ICANN's footnote.)

Nonetheless, it occurs to me that the set of DNS names that are
reserved or that have special meanings in some protocols are scattered
over a lot of different RFCs. So I wrote a strawman to collect them
all in one place and make a registry of them:

   draft-levine-reserved-names-registry-00.txt

I think I got all the names, I did some greps over all of the text
RFCs looking for things that resembled domain names, and I looked to
see what's actually in .ARPA and the root.

If other people agree that it's a good idea to have a place that IANA
can point to for the reserved names, I'd be happy to move this ahead.
Or if we think the situation is OK as it is, we can forget about it.
But I see little wisdom in adding another does-not-exist name with
semantics not meaningfully different from .INVALID or FOO.INVALID.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Dec 2009 02:21:15 -0500

--On Monday, December 28, 2009 01:16 +0000 John Levine
<[email-masked]> wrote:

> It seems to me that if we think it's a good idea to specify a
> domain name that doesn't exist, we're better off clarifying
> the status of the ones already specified rather than inventing
> new ones.  Since the people who manage .ARPA are the exact
> same people who manage the root (IANA, operated by ICANN, in
> both cases), one is as likely to flake as the other.

While you are presumably right about "flake", .ARPA is rather
clearly under IAB supervision, while the root is under the
supervision of the ICANN Board and ICANN policy-making
processes.  That distinction is fairly significant for some
purposes.  It may or may not be for this one.  FWIW, I'm not
aware of there being an established procedure for adding new
names to the ICANN reserved list: while several of the names are
"ours", I don't recall their being requested in any systematic
way.  Others of the names are of entities who have leverage
within ICANN.  One could make a strong case for other bodies
having their names blocked or reserved on a par with those
listed: IEEE, ISO, and ITU come to mind as examples.

> In fact, ICANN is quite aware of the reserved names list.  In
> the current draft of the application process, one of the steps
> is to check to see if a proposed name is one of the Reserved
> ones, in which case the application fails immediately.  Here's
> their reserved list:
>...
 
> reserved or that have special meanings in some protocols are
> scattered over a lot of different RFCs. So I wrote a strawman
> to collect them all in one place and make a registry of them:
> 
> I think I got all the names, I did some greps over all of the
> text RFCs looking for things that resembled domain names, and
> I looked to see what's actually in .ARPA and the root.

Two quick observations on that draft:  (1) It would be good to
have "domain" explicitly in the title.  We have reserved names
in other places.   (2) While there are reasonable arguments for
gathering a list in one place, having multiple lists under
parallel development in multiple groups presents a
synchronization problem.  Since the RFC-writing process is not
the only way that names can be added to the list and this is a
list of names to not be allocated (i.e., IANA may not know), it
is reasonably likely to diverge from reality even if it doesn't
start that way.   For example, the "new names" allocation
process in ICANN might put another name on the list without
identifying that fact clearly enough to IANA to get the name on
the list.   A clearly non-normative glossary of reserved names
might be a more practical idea.

> If other people agree that it's a good idea to have a place
> that IANA can point to for the reserved names, I'd be happy to
> move this ahead. Or if we think the situation is OK as it is,
> we can forget about it. But I see little wisdom in adding
> another does-not-exist name with semantics not meaningfully
> different from .INVALID or FOO.INVALID.

I see relatively little harm in reserving one subdomain of .ARPA
for protocol use, since doing so would isolate the string from
any ICANN issues.  As I've said before, I think the notion of a
registry process allocating more of those names at the second
level would be a bad idea.  And I'm not sure that the case has
been made for the single reservation: your last sentence above
is an argument that it has not been.

best,
    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 28 Dec 2009 11:38:11 +0100

> Or if we think the situation is OK as it is, we can forget about it.

I'd be happier with some sort of list (I was surprised by its length, 
and IMO that's a sign that the list is needed) and like your document.

(BTW. You mention _proto and _service. Neither is reserved for SRV. SRV 
uses_tcp, _udp and other "_proto" names. I think it would be stupid by 
use them for any other purpose in the DNS, but don't think that 
justifies reserving _ah, _ax25, _ddp, _egp, _eigrp, _encap, _esp, 
_etherip, _fc, _ggp, _gre, _hmp, _icmp, _idpr-cmtp, _idrp, _igmp, _igp, 
_ip, _ipcomp, _ipencap, _ipip, _ipv6, _ipv6-frag, _ipv6-icmp, 
_ipv6-nonxt, _ipv6-opts, _ipv6-route, _isis, _iso-tp4, _l2tp, _ospf, 
_pim, _pup, _rdp, _rspf, _rsvp, _sctp, _skip, _st, _tcp, _udp, _vmtp, 
_vrrp, _xns-idp and_xtp. But we have a fun game of TLA bingo on the 
list and see who uses/remembers most of those!)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 28 Dec 2009 11:46:33 +0100

I seem to have a problem with short words this week ("can", "to" etc.). 
They spontanteously mutate or disappear. Sorry.

Arnt

---

From: Jorge Amodio <[email-masked]>
Date: Mon, 28 Dec 2009 06:01:17 -0600

I think that in regards to the management and supervision of
.ARPA I'd suggest to include RFC3172 and RFC2860 as a reference.

I find that using the word "Registry" will IMHO create some
confusion with ICANNland.

The list of reserved names from ICANN's DAGv3 2.1.1.2 you
included in your message  applies only to potential gTLDs,
this list may become very dynamic and multilingual, how do you
expect to include these names in your draft ?

There are some particular names that based on the criteria
defined in your draft can be listed as "Special" and "Reserved"
like WHOIS, WWW, etc.

Also from the proposed ICANN's Registry Agreement Article 2,
Registry (in ICANN's sense of the word) Operators "may establish
policies concerning the reservation or blocking of additional
character strings within the TLD at its discretion", then
how do you propose to incoporate also those names to the
"reserved list" ?

Who is or should be the "authority" that will be responsible
and assigned the task to keep the "list" updated ?

My .02
Jorge

---

From: "De Zeurkous" <[email-masked]>
Date: Mon, 28 Dec 2009 12:36:48 -0000

Haai,

[not replying to anyone in particular]

I think we should make and maintain a seperation between two classes of
(reserved) symbols according to their fundamentally different origins:

-Required for one or more protocols to correctly function; and
-Reserved for administrative purposes (which may not hold true on another
network).

Examples of the former would include localhost and perhaps arpa; examples of
the latter would include .example, .invalid, and gTLDs not in use (although a
third category might be useful for the latter, to be managed by ICANN).

The former should be encoded in RFCs, although I agree that a composite list
would be useful. The latter should, in my view, be recorded in a seperate
registry, to be maintained in a similar way to the services list (disclaimer:
I have no idea how the latter is presently maintained); in both cases,
subject to approval, anyone should be able to register a reserved TLD resp. a
network service, and in the latter case, be assigned a number.

In all cases, a flat-formatted text file similar to UNIX' services(5) list
should be made available.

Feel free to shoot me if any of the above is deemed heresy.

Baai,

De Zeurkous
-----------

Friggin' Machines!

--
# Proud -net.kook- IRC bot overengineer
% NetBSD, zsh, twm, nvi and roff junkie
>From the fool file:
I don't see why the way people have historically partitioned disks should
dictate which kernels we build and distribute by default in the future.
        --Darren Reed ([email-masked]), NetBSD tech-kern

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Dec 2009 12:12:19 -0500

At 05:38 28/12/2009, Arnt Gulbrandsen wrote:
>John Levine writes:
>>If other people agree that it's a good idea to have a place that 
>>IANA can point to for the reserved names, I'd be happy to move this 
>>ahead. Or if we think the situation is OK as it is, we can forget about it.
>
>I'd be happier with some sort of list (I was surprised by its 
>length, and IMO that's a sign that the list is needed) and like your document.
>
>(BTW. You mention _proto and _service. Neither is reserved for SRV. 
>SRV uses_tcp, _udp and other "_proto" names. I think it would be 
>stupid by use them for any other purpose in the DNS, but don't think 
>that justifies reserving _ah, _ax25, _ddp, _egp, _eigrp, _encap, 
>_esp, _etherip, _fc, _ggp, _gre, _hmp, _icmp, _idpr-cmtp, _idrp, 
>_igmp, _igp, _ip, _ipcomp, _ipencap, _ipip, _ipv6, _ipv6-frag, 
>_ipv6-icmp, _ipv6-nonxt, _ipv6-opts, _ipv6-route, _isis, _iso-tp4, 
>_l2tp, _ospf, _pim, _pup, _rdp, _rspf, _rsvp, _sctp, _skip, _st, 
>_tcp, _udp, _vmtp, _vrrp, _xns-idp and_xtp. But we have a fun game 
>of TLA bingo on the list and see who uses/remembers most of those!)
>
>Arnt
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf
>

See:
http://www.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-00.txt

and older version of that is being split (second half is to contain the
registry cleanups).
http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04

         Olafur

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 28 Dec 2009 11:57:26 -0700

On Dec 28, 2009, at 3:38 AM, Arnt Gulbrandsen wrote:

> I'd be happier with some sort of list (I was surprised by its length, and IMO that's a sign that the list is needed) and like your document.

+1

I can think of all sorts of other use cases for such a list, such as verifying the accuracy of email addresses & URIs before they're collected/clicked/etc.

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Reed Loden <[email-masked]>
Date: Mon, 28 Dec 2009 14:08:52 -0600

On 28 Dec 2009 01:16:47 -0000
John Levine <[email-masked]> wrote:

> Here's their reserved list:
...
>  LOCALHOST

This one caught my eye, as I know for sure that localhost.<tld> seems
to be registered in most TLDs (both gTLDs and ccTLDs) by actual users
(mostly because I recently looked into purchasing one such domain).

Reading through draft-levine-reserved-names-registry-00, you refer to
RFC 2606 for "LOCALHOST"'s addition, but RFC 2606 specifies "TEST",
"EXAMPLE", "INVALID", and "LOCALHOST" as reserved TLDs, not reserved
second-level domains. Only example.{com|net|org} are mentioned as
reserved second-level domains as per that RFC.

Also, in your I-D, you seem to use "Top" as the level for second-level
domains, which seems confusing and technically incorrect. Seems like
the ones that are second-level domains should be classified as
"Second", "Secondary", or maybe your "Leaf" class, though "Leaf"
seems odd here.

In other notes, I'm happy to see you included "LOCAL" and "TLD" in
your list (as reserved TLDs, I assume), as they have been proposed
multiple times in various places for their addition to the reserved
list, yet nobody has actually done that yet (according to a response
I received from IANA in November). Another possible addition would be
the new IDN test TLDs (http://www.iana.org/domains/idn-test/).

With regards,
~reed

-- 
Reed Loden - <[email-masked]>

---

From: John Levine <[email-masked]>
Date: 28 Dec 2009 22:00:24 -0000

>(mostly because I recently looked into purchasing one such domain).

ICANN reserves LOCALHOST as a TLD, not as a second level.

>reserved second-level domains as per that RFC.

Yes, that's what the I-D is intended to say.

>domains, which seems confusing and technically incorrect.

Acually, "Top" means "top level domain".  Is that less confusing?

I think I'll do another version which proposes separate IANA
registries of reserved TLDs, special purpose 2LDs in .ARPA, and
special _names.  I see in namedroppers some effort to identify the
protocol and service names for SRV, which should be coordinated with
the more general list I'm doing.

R's,
John

---

From: John Levine <[email-masked]>
Date: 28 Dec 2009 22:12:38 -0000

> [ re _proto and _service names ]
>See:

Yes, I noticed that.  As far as I can tell, the only _name entries
other than SRV protocols and services are _domainkey, _vouch, and
_adsp.  It would be nice to collect them all in one place.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Tue, 29 Dec 2009 13:02:54 -0500

> (IANA, operated by ICANN, in both cases), one is as likely to flake as

Operational management is not what I was talking about (assuming it was my recent comments that triggered that observation). I was expressing concern over policy. I think the policy that governs the administration of the ARPA zone is far easier to characterise in an IETF context than that of the root zone.

> case the application fails immediately.  Here's their reserved list:

Again, I am not involved in existing or proposed future policy for the root zone, but I'm confused as to what you are attempting to achieve through draft-levine-reserved-names-registry-00.

If you're proposing to ICANN that they cede control over the reserved names list for the root zone to an IANA registry controlled by an IETF process (RFC publication, according to your current text), then this doesn't seem like the venue to propose that.

If you're proposing that the IETF document a list of names that has change control and authorship homed within ICANN, then I'm not sure what the benefit of that is.

If you're making some other proposal, then I am currently missing it.

Could you explain?

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Dec 2009 13:16:29 -0500

On Tue, Dec 29, 2009 at 01:02:54PM -0500, Joe Abley wrote:
> 
> If you're proposing that the IETF document a list of names that has
> change control and authorship homed within ICANN, then I'm not sure
> what the benefit of that is.

Setting aside the mind-bending metaphysical consequences of the
subject line in this thread, I actually think it would be a good idea
if there were, somewhere, a list of undelegated top-level names for
which change control and (policy) authorship nevertheless lie within
ICANN.  At the moment, the canonical list of the reserved names from
ICANN's point of view is buried inside a document that many people
have no reason to consult, because they're not trying to get a new top
level delegation.

It therefore seems to me to be not a bad idea to have an RFC or IANA
registry for the "reserved names", in ICANN parlance.  It would also
be good if some operational rules about what "reserved names" means
were in an RFC somewhere (for instance, are there different classes of
"reserved" names?  Why?  Do they come in and out of existence
depending on other states of the world?  Can they be resolved on the
Internet?  And so on.  Depending on who was speaking, in my
experience, these distinctions were not always made.)

I'm actually indifferent to the publication means for this, though --
an RFC, an ICANN document that stands on its own, whatever -- but
since we have IANA registries already that seems to me to be the
obvious locus for yet another list.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 29 Dec 2009 13:10:42 -0600

> have no reason to consult, because they're not trying to get a new top

I believe that putting together a static list of something that is not
clearly defined when there is no clear policy for adding/removing
items from the list and no clear authority defined to execute the
policy and responsible to keep the list updated will make the list
useless on day D-1.

Not only those "reserved names" are buried in an ICANN's *draft*
document, as I mentioned on a previous message the current policy
under discussion includes language to let registries of new gTLDs to
create at its discretion additional reserved names within their gTLD,
not specifying even at which level in the DNS tree the name might be.

Also each registry agreement may include an specific appendix like in
http://www.icann.org/en/tlds/agreements/verisign/appendix-06-01mar06.htm
which states for each TLD/gTLD what names or particular constructs are
reserved, such as one/two character or tagged domains with hyphens in
the third and fourth char positions that I don't believe the proposed
draft mentions.

Perhaps instead of a static list a more complete fyi document could
describe who has the "authority" to reserve names, how, and where the
pertinent information can be obtained.

I believe there is some work related to EPP about how
registrars/registries exchange info about reserved names but I don't
recall the specifics right now.

My .02
Jorge

---

From: John Levine <[email-masked]>
Date: 29 Dec 2009 19:56:49 -0000

>were in an RFC somewhere (for instance, are there different classes
>of "reserved" names?  Why?

Yes, that's what I'm trying to get at.  As far as I can tell, there
are at least three different kinds of reserved names.  Names like
.INVALID and .TEST are reserved forever and will never be delegated.
Names like .IETF and .RIPE are names of identified Internet
infrastructure organizations who could in principle have the name
delegated to them.  Names like .QQ are reserved until some third party
(ISO 3166 in this case) says something about them. 

There are probably also names that are implicitly reserved like .123
or .XX--ABC (where the two letters in XX-- are anything other than xn)
because of likely technical problems if they were used.  And there
appear to be names like single characters which are reserved until
ICANN decides what to do about them.  There's also one special purpose
TLD, .ARPA, which is more or less delegated to the IAB although
managed by IANA.

For second-level domains, there are the three EXAMPLE names reserved
by RFC2606, a fair number of names reserved by ICANN policy (single
letters in gTLDs other than the few pre-ICANN ones), or by terms in
gTLD contracts.  Other than the EXAMPLEs I don't think any of those
reservations are expected to be permanent.

This is all reasonably well known to people familiar with ICANN
folklore, but it sure would be nice to have it written down in one
place so we can have an idea of what they are.

>obvious locus for yet another list.

IANA seems the most reasonable place to me, too.  The trick is getting
ICANN to agree to maintain its contents or at least contribute their
entries to it.

There's the somewhat separate issue of _foo tags used in SRV and other
non-host records.  That seems politically and technically
straightforward, give or take liason with the group enumerating
service and protocol names for SRV.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Dec 2009 14:59:25 -0500

> policy and responsible to keep the list updated will make the list

Which is why I think setting up an IANA registry makes sense: the
setting up of the registry forces one to define all of that too.

> recall the specifics right now.

AFAIK there is no definition of "reserved names" in any of the EPP
specifications.  Are you referring to some other forum other than the
IETF?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Dec 2009 12:50:45 -0800

Hi,

On Dec 29, 2009, at 11:56 AM, John Levine wrote:
> There's also one special purpose

RFC 3172 is pretty explicit about how ARPA is managed:

   The Internet Architecture Board (IAB), in cooperation with the
   Internet Corporation for Assigned Names and Numbers (ICANN), is
   currently responsible for managing the Top Level Domain (TLD) name
   "arpa". 

and

   As noted in section 3 of this document, the IAB may request the IANA
   to delegate the sub-domains of "arpa" in accordance with the "IANA
   Considerations" section of an IETF Standards Track document.

> ICANN to agree to maintain its contents or at least contribute their

As it would seem to be in ICANN's best interest to ensure the contents of the list are maintained, I don't expect this to be too challenging.  Aside from the list itself, what I personally think would be helpful would be a clear and mutually agreed process by which labels would be added/removed from the list.

Regards,
-drc

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 29 Dec 2009 14:58:05 -0600

> setting up of the registry forces one to define all of that too.

I see your point. We also need to remember that some names are based
on rules and not static strings.

> specifications.  Are you referring to some other forum other than the

Didn't cross reference with any drafts or ietf-wg mailing lists, but
the text of the proposed new registry agreement says (page 197 of
DAGv3):

<quote>
4.5 Object Statuses. RFC 4930 (EPP) and related RFCs, see [1], [2],
[3], [4] indicate permissible status
codes for various registry objects. Additionally the status “reserved”
is allowed for domains; it is used
to indicate a reserved name on behalf of the Registry or ICANN.

4.6 Reserved Name Handling. Registries typically have a set of names
reserved on behalf of themselves
or IANA. Reserved names must be included in the DOMAIN file, and have
the special "reserved"
status associated with them in the DOMSTATUS file to indicate that
they are reserved.
</quote>

For the references 1,2,3,4 the doc says:

<quote>
[1] Extensible Provisioning Protocol (EPP),
http://www.rfc-editor.org/rfc/rfc4930.txt
[2] EPP Domain Name Mapping, http://www.rfc-editor.org/rfc/rfc4931.txt
[3] EPP Host Mapping, http://www.rfc-editor.org/rfc/rfc4932.txt
[4] EPP Contact Mapping, http://www.rfc-editor.org/rfc/rfc4933.txt
</quote>

Jorge

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 29 Dec 2009 15:00:30 -0600

> (ISO 3166 in this case) says something about them.

Remove the leading dots, ICANN and IANA related names are reserved at
2nd and all levels.

Current registry agreement says: "Labels Reserved at All Levels. The
following names shall be reserved at the second level and at all other
levels within the TLD at which Registry Operator makes registrations"

Jorge

---

From: "John R. Levine" <[email-masked]>
Date: 29 Dec 2009 16:20:21 -0500

> Remove the leading dots, ICANN and IANA related names are reserved at

In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, 
who knows?

R's,
John

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 29 Dec 2009 15:34:04 -0600

On Tue, Dec 29, 2009 at 3:20 PM, John R. Levine <[email-masked]> wrote:
> In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, who
> knows?

That's right, ccTLDs are a different dimension.

I've not checked or seen the agreements for the new IDN ccTLDs, can't
remember now any discussions related to reserved names in that
context, but the new IDN ccTLD operators will be now under a
contractual relationship with ICANN so the new agreement may have some
similarities with the new gTLD registry agreement. Again, just
guessing since I've not seen any docs about the IDN ccTLD agreements.
I'll look around.

Jorge

---

From: Alan Barrett <[email-masked]>
Date: Wed, 30 Dec 2009 19:25:34 +0200

> semantics not meaningfully different from .INVALID or FOO.INVALID.

I think the semantics are meaningfully different, in that applications
are allowed to know that .invalid is special, but should not know that
sink.arpa (or nonexistent.arpa) is special.

--apb (Alan Barrett)

---

From: John Levine <[email-masked]>
Date: 30 Dec 2009 19:13:10 -0000

>sink.arpa (or nonexistent.arpa) is special.

Aren't we arguing in circles here?  The original proposal was for an
RFC to mark SINK.ARPA as special.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Wed, 30 Dec 2009 19:51:11 -0500

> RFC to mark SINK.ARPA as special.

To be slightly pedantic, it was a proposal to make a policy decision that the name SINK.ARPA should not be made to exist by those responsible for administration of the ARPA zone as described in 3172.

The proposal did not seek to update the behaviour of protocols or applications to treat SINK.ARPA any differently from any other name in the DNS.

Joe

---

From: "John R. Levine" <[email-masked]>
Date: 30 Dec 2009 22:49:32 -0500

> The proposal did not seek to update the behaviour of protocols or applications to treat SINK.ARPA any differently from any other name in the DNS.

Right.  For all practical purposes, its treatment would be identical to 
.INVALID.  Technically there's nothing special, administratively the 
manager would promise never to delegate it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.