Subject: draft-eastlake-2606bis-00.txt: Suggestions for modifications

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 12:55:36 +0200

Hi,

I couldn't find any discussion of this draft on the mailing list, but the 
draft says that it should be discussed here, so here it goes... WG chairs, 
please rule me out of order if it isn't appropriate (and ask the author to 
update the draft...)

draft-eastlake-2606bis-00, "Reserved Top Level DNS Names", tries to update 
the old RFC that reserved ".test", ".example", ".invalid" and ".localhost".

RFC 2606 is a BCP, so presumably this document aims for the same status.

Summary: This is definitely not a document that I think the IETF should 
publish as-is.

My detailed comments:

1) I believe section 3.1  and 3.4 (reservation of "aso", "gnso", "afrinic", 
"rfc-editor" and so on) is inappropriate for the IETF and should be 
removed. This is ICANN's business.

Optionally, I could argue that it should be reduced to "example", so that 
we could use "example.fr" as well as "example.com" in examples.

I am less sure about section 3.3 (prohibition of single character and two 
letter names). There may be technical justification for these (see the RFC 
describing the "com.com" problem, and how to fix it - the number escapes 
me) - but I know for a fact that multiple registries do hand out two-letter 
domain names today, and are likely to continue to do so no matter what the 
IETF says - so this needs *heavy* justification - my default proposal would 
be "remove".

2) A different conversation led to the (to me) surprising conclusion that 
there is no IETF document that conclusively states that top level domains 
shouldn't be all numeric. I think this is an appropriate thing for the IETF 
to state in a BCP, since 4-component all-numeric domain names are hard to 
tell from IP addresses - a technical consideration in many protocols.

This could be added as a subsection of section 2 - since it's a new reason 
for reserving TLDs.

3) The nature of the reservation of tagged domain names (xn--) in section 
3.3 needs to be explained - the sentence is even grammatically incomplete.

I *think* it's intended to reserve these labels at all levels until a 
normative interpretation is given in an IETF standard. But the para does 
not say.

I believe there might be an IANA registry of those tags somewhere?
If so, this should be mentioned.

                     Harald

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Oct 2005 21:17:34 +1000

> tell from IP addresses - a technical consideration in many protocols.

	RFC 1123 comes close.

           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric
           (see Section 6.1.2.4).  However, a valid host name can never
           have the dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 13:37:41 +0200

--On torsdag, oktober 20, 2005 21:17:34 +1000 Mark Andrews 
<[email-masked]> wrote:

>> 2) A different conversation led to the (to me) surprising conclusion
>> that  there is no IETF document that conclusively states that top level
>> domains  shouldn't be all numeric. I think this is an appropriate thing
>> for the IETF  to state in a BCP, since 4-component all-numeric domain
>> names are hard to  tell from IP addresses - a technical consideration in
>> many protocols.
>
> 	RFC 1123 comes close.
>

Yep - but I'm betting that this will be ruled non-normative eventually, 
because some people want IDNs in TLDs, and Punycode uses numbers in its 
encoding.
It's a long leap from "must be alphabetic" to "can be all-numeric" - but 
I'd prefer to have something explicit somewhere, so that we don't end up 
there by accident.

I *think* it's uncontroversial. But better safe than sorry.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Oct 2005 08:16:39 -0400

>It's a long leap from "must be alphabetic" to "can be all-numeric" - but I'd
>prefer to have something explicit somewhere, so that we don't end up there by
>accident.
>

As many of us have said before, 1123 refers to host names, not domain 
names.  (Host names are a subset of domain names.)  In an NS and MX 
record, you want a host name, not necessarily so in a RRSIG record.

I disagree with the suggestion to bar all-numeric names.  Mostly 
because I don't like "rules" that are unnecessary.  I don't see the 
necessity of such a restriction.

I am not arguing against what 1123 says.  From what I understand, if 
a domain name represents a host, then a numeric label can cause 
confusion for an application like telnet (to pick on an old, tired 
horse).  There is a necessity for that, even if there is a "newer 
version [of the application] out there."

But in general, I don't see the harm of an all numeric label, even a TLD.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story:
Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis
to get home from a conference.  (Cities changed to protect his identity.)

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Oct 2005 14:10:33 +0100

On Thu, 20 Oct 2005, Edward Lewis wrote:
>
> I disagree with the suggestion to bar all-numeric names.  Mostly because I
> don't like "rules" that are unnecessary.  I don't see the necessity of such a
> restriction.
>
> I am not arguing against what 1123 says.  From what I understand, if a domain
> name represents a host, then a numeric label can cause confusion for an
> application like telnet (to pick on an old, tired horse).  There is a
> necessity for that, even if there is a "newer version [of the application] out
> there."
>

All-numeric labels are fine, so long as they aren't TLDs.

There is a vast amount of code out there that assumes that a string
containing only dots and digits is an IP address. If you allow TLDs to be
all-numeric then these applications will have to be changed so that they
consult the DNS before treating it as an IP address, which will increase
the number of pointless queries going to the root name servers.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 15:16:21 +0200

Ed,

I must be feeling rather uncharitable today.

--On torsdag, oktober 20, 2005 08:16:39 -0400 Edward Lewis 
<[email-masked]> wrote:

> I disagree with the suggestion to bar all-numeric names.  Mostly because
> I don't like "rules" that are unnecessary.  I don't see the necessity of
> such a restriction.

My opinion:

The distinction between "hostnames" and "domain names" makes sense in many 
places, but this is NOT one of them. Hiding behind that distinction is a 
way to duck the problem that I won't accept; it may be that dnsext is the 
wrong WG to do it, because dnsext has (mostly successfully) stayed out of 
the "meaning" issues, but I think it's an IETF problem, and the IETF should 
solve it.

We (the IETF, which has protocols ranging from layers 2 to 7) have defined 
protocols which break in the presence of all-numeric hostnames; if you can 
put the following record into the DNS:

  129.241.1.99.   A    158.38.152.233

two reasonable interpretations of the HTTP spec can end up querying two 
different webservers for the URL

  http://129.241.1.99/proof-of-concept.html

just to give one example.

That is, in my book, a problem, and should be fixed.

If there is a rule about numeric TLDs not being allowed, this problem is 
fixed once, and for all protocols with this problem.

If not, each and every protocol needs updating with its own "tie-breaker 
rule" - that's stupid.

It's possible to write that rule in many different forms.
But I think it's the IETF's job to pick one.

                 Harald

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Oct 2005 09:30:38 -0400

>I must be feeling rather uncharitable today.

;)

>protocols which break in the presence of all-numeric hostnames; if you can put
>the following record into the DNS:

Maybe we are entering a rat hole - I also agree that all-numeric host 
names are a problem.  It's that generalizing a ban on all-numeric 
domain names isn't justified to me.

>two reasonable interpretations of the HTTP spec can end up querying 
>two different webservers for the URL
>

That's a valid example.  in that case the 129.241.1.99 is occupying a 
place where a host name is expected.  This is a case where a hard 
failure (name error, NXDOMAIN) is desirable.

>If there is a rule about numeric TLDs not being allowed, this problem is fixed
>once, and for all protocols with this problem.

That's akin to an amputation to mend a hangnail.  Okay, something 
more serious that a hangnail because of the hit root servers would 
take (as Mr. Finch pointed out).

Thinking about this for a moment - this is a problem fixed in IPv6, 
huh?  IPv6 text conventions use a different separator than DNS.  That 
makes two reasons to switch to IPv6. ;)

Maybe we(=$some_appropriate_group) can just reserve the labels 0 
through 255 in the root zone.

True story:

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 15:45:05 +0200

--On torsdag, oktober 20, 2005 09:30:38 -0400 Edward Lewis 
<[email-masked]> wrote:

> place where a host name is expected.  This is a case where a hard failure
> (name error, NXDOMAIN) is desirable.

Sorry, I didn't understand that. NXDOMAIN for what, and why?

in fact what's needed for the IPv4 case is a ban on 1-4-component, 
all-numeric domain names where all the numbers are within certain ranges 
(yes, http://12345678/ is a perfectly valid URL, and resolves to a specific 
IP address - and spammers have proved that it works!)

The nice thing about requiring no all-numeric at the root is that there's 
only one operator (no new code, no user education) that needs to agree to 
make it effective - and it breaks exactly zero existing applications to 
make it so. Any other way to achieve the same result seems far more complex 
to me.

Occam's razor....

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 Oct 2005 15:00:16 +0100

On Oct 20, 2005, at 14:30, Edward Lewis wrote:

>> two reasonable interpretations of the HTTP spec can end up  
>> querying two different webservers for the URL

> That's a valid example.  in that case the 129.241.1.99 is occupying  
> a place where a host name is expected.

Is it? Is the glass half-empty or half-full? It could be argued that  
the example above is a domain name that happens to have an A record.  
I don't recall any rule that says only owner-names that happen to be  
valid hostnames are allowed to have A records. RFC2181 implies  
otherwise.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Oct 2005 00:01:42 +1000

> through 255 in the root zone.

	You have to remove all values upto 2^32-1.

	1.16777215 is equivalent to 1.255.255.255

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Oct 2005 10:02:01 -0400

>Sorry, I didn't understand that. NXDOMAIN for what, and why?

If a resolver queried for "QNAME=129.241.1.99, QTYPE=A, QCLASS=IN" 
and there wasn't already a negative entry for this, the root would 
look to see if "99." was an existing label.  In short, "99." does not 
exist, so a name error (represented by the letters NXDOMAIN in RFCs 
since at least 2136, longer in code in BIND) is indicated in the 
response code field of the DNS reply message.

(This is from the algorithm described in RFC 1034, section 4.3.2.)

>in fact what's needed for the IPv4 case is a ban on 1-4-component, all-numeric
>domain names where all the numbers are within certain ranges (yes, http://
>12345678/ is a perfectly valid URL, and resolves to a specific IP 
>address - and
>spammers have proved that it works!)

It sounds to me that in hindsight, we should have done better.  But 
that's water under the bridge.

The tradeoff here is (protocol) engineering vs. operations.  You can 
build a system to avoid a problem or to recover from one.  Or you can 
operate a system to avoid problems.  That's where this debate will 
fall into.  What we are asking to do is set up some more operations 
maintained bumper guards.

>The nice thing about requiring no all-numeric at the root is that there's only
>one operator (no new code, no user education) that needs to agree to make it
>effective - and it breaks exactly zero existing applications to make 
>it so. Any
>other way to achieve the same result seems far more complex to me.
>
>Occam's razor....

By the same logic, the root and .arpa should have been signed with 
DNSSEC long ago.

True story:

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Oct 2005 14:13:07 +0000

# I must be feeling rather uncharitable today.

welcome.

# ...
# We (the IETF, which has protocols ranging from layers 2 to 7) have defined
# protocols which break in the presence of all-numeric hostnames; if you can
# put the following record into the DNS:
# 
#   129.241.1.99.   A    158.38.152.233
# 
# two reasonable interpretations of the HTTP spec can end up querying two
# different webservers for the URL
# 
#   http://129.241.1.99/proof-of-concept.html
# 
# just to give one example.
# 
# That is, in my book, a problem, and should be fixed.

it's a problem, yes.  maybe it should be fixed.  maybe the fix is in dns
rather than in http.  maybe it just needs to be documented and recommended
against?

# If there is a rule about numeric TLDs not being allowed, this problem is
# fixed once, and for all protocols with this problem.

if only that were true.  consider RFC 1535.  this isn't just a TLD problem
unless you think browsers won't use domain-suffix search lists or you think
users will put a "." at the end of the dotted-quad-thing.

# If not, each and every protocol needs updating with its own "tie-breaker
# rule" - that's stupid.
# 
# It's possible to write that rule in many different forms.
# But I think it's the IETF's job to pick one.

when did the ietf community start ruling by law rather than leading by
recommendations?  can't we just say "any application or library which
does DNS lookups to translate presentation-layer endpoint identifiers
into network-layer endpoint identifiers should take care to avoid doing
DNS lookups for presentation-layer content which is syntactically valid
as an IPv4 or IPv6 host name"?  we can leave open the possibility that
the conversion will be done using string arithmetic or not, but what we
really care about is that a DNS lookup not be made for such names.  we
do NOT have to say that the lookup is undefined or invalid, since that
would mean defining which domain names are "hostnames", which i'd regard
as an overspecification.  we just have to recommend that the queries not
be made.

that would also help reduce the unwanted traffic on the root name servers,
assuming that a lot of end systems were upgraded to follow this
recommendation.

note that bind's gethostbyname() has had this logic for some years now:

                                /*
                                 * All-numeric, no dot at the end.
                                 * Fake up a hostent as if we'd actually
                                 * done a lookup.
                                 */
                                if (!inet_aton(name, &host_addr)) {
				   ...

(that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 17:04:31 +0200

--On torsdag, oktober 20, 2005 14:13:07 +0000 Paul Vixie <[email-masked]> 
wrote:

> as an IPv4 or IPv6 host name"?

Except that we've now created a class of names that are OK to register, and 
OK to populate in the DNS, but some applications will never be able to look 
up.... that's kind of bizarre.
I think the "don't register numeric TLDs" is a recommendation too, in the 
sense that everything the IETF produces for external consumption is. And a 
simpler one.

> (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.)

entirely tangential, but illustrates something, I think....

this line of code is mostly responsible for the widely held but erroneous 
belief that [email-masked] is a valid email address.

hta@[129.241.1.99] is a valid email address. [email-masked] isn't.
Some mailers get it right, some don't.

                       Harald

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Oct 2005 17:14:44 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso",
> "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and
> should be removed. This is ICANN's business.

Correct, it is inappropriate (thanks for finding this word, I was
thinking of something much more violent). But it is not ICANN's
business' either. The rules under ".fr" (or any other ccTLD) are not
to be defined by IETF or ICANN, period (unless of course they are
syntactical ruls or rules *necessary* for good interoperability, but
business rules like those of the draft are a no-no).

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 17:22:50 +0200

> business rules like those of the draft are a no-no).

I happen to agree with you in the case of ccTLDs :-) - but that fight too 
is ICANN's business to fight. We (speaking as an IETF participant) 
shouldn't get involved - either in saying "yes" or in saying "no" to such 
restrictions.

                       Harald

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Oct 2005 16:12:01 +0000

# > when did the ietf community start ruling by law rather than leading by
# > recommendations?  can't we just say "any application or library which
# > does DNS lookups to translate presentation-layer endpoint identifiers
# > into network-layer endpoint identifiers should take care to avoid doing
# > DNS lookups for presentation-layer content which is syntactically valid
# > as an IPv4 or IPv6 host name"?
# 
# Except that we've now created a class of names that are OK to register, and
# OK to populate in the DNS, but some applications will never be able to look
# up.... that's kind of bizarre.

then make a recommendation that IANA not allocate such names as toplevels?

(what people choose to do further down the tree is not up to us to decide.)

# I think the "don't register numeric TLDs" is a recommendation too, in the
# sense that everything the IETF produces for external consumption is. And a
# simpler one.

right.

# > (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.)
# 
# entirely tangential, but illustrates something, I think....
# 
# this line of code is mostly responsible for the widely held but erroneous
# belief that [email-masked] is a valid email address.

worse than that: it's valid for some people some of the time.  the logic in
gethostbyname() was put there because applications could not be depended upon
to say "if it's a valid address, use it, else look it up as a hostname" and
so gethostbyname() became a dual-purpose function.  probably it would've been
better to return an error on the basis of non-RFC952-compliance.  (who knew?)

# hta@[129.241.1.99] is a valid email address. [email-masked] isn't.
# Some mailers get it right, some don't.

really?  i know that mailnames used to have to start with non-numeric, but
3com.com asked for a change and got it.  do the current (2821/2822) railroad
diagrams really say that 129.241.1.99 is not a valid mailname?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 18:40:01 +0200

--On torsdag, oktober 20, 2005 16:12:01 +0000 Paul Vixie <[email-masked]> 
wrote:

># Except that we've now created a class of names that are OK to register,
># and OK to populate in the DNS, but some applications will never be able
># to look up.... that's kind of bizarre.
>

that's exactly what I'd like draft-eastlake-2606bis-00 to do....

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 18:39:17 +0200

Changing the subject on this particular tangent....

--On torsdag, oktober 20, 2005 16:12:01 +0000 Paul Vixie <[email-masked]> 
wrote:

> 3com.com asked for a change and got it.  do the current (2821/2822)
> railroad diagrams really say that 129.241.1.99 is not a valid mailname?

RFC 2821:

3.6 Domains

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
   used.

.............

4.1.2 Command Argument Syntax

      Domain = (sub-domain 1*("." sub-domain)) / address-literal
      sub-domain = Let-dig [Ldh-str]

      address-literal = "[" IPv4-address-literal /
                            IPv6-address-literal /
                            General-address-literal "]"
            ; See section 4.1.3

      Mailbox = Local-part "@" Domain

Here's where the "hostname" charset restriction occurs too - but no text 
there about TLDs.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 20 Oct 2005 13:13:22 -0400

>>railroad diagrams really say that 129.241.1.99 is not a valid mailname?

It should also be pointed out that even though labels may contain numbers,
the entire hostname sequence is expected to contain at least one letter.
This is spelled out in the requirements prior to the relaxation in
rfc1123, but its also confirmed in 1123 itself

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Oct 2005 16:15:16 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> I couldn't find any discussion of this draft on the mailing list,
> but the draft says that it should be discussed here,

Yes, but DNSop would be more adapted, no?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Oct 2005 16:23:15 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> removed. 

3.1 is clearly completely out-of-scope and must be removed. There is
no reason that strings like "iab" or "iana" should be prohibited.

3.4 is a bit different because we no longer talk about "back office"
organisations like IAB or ARIN but about operational uses. "nic" and
"whois" could be seen are reasonable names to reserve to the
infrastructure. I'm more hesitant about "www". While I understand that
http://www.example/ could be seen as a Web site authoritative about
the TLD example, I'm not sure that we should reserve "www" and not
"mail", for instance.

Probably, the logical conclusion will be to drop 3.4 completely,
because I'm not sure we can have a consensus on the list (may be just
on "nic"?)