Re: [DNSOP] draft-liman-tld-names-04

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Stephane Bortzmeyer writes:
> On Wed, Nov 17, 2010 at 11:15:04PM +1100,
>  Mark Andrews <[e-mail]> wrote 
>  a message of 41 lines which said:
> 
> > > So, there is no ambiguity: 192.0.2.4 is always an IP address, even if
> > > ICANN delegates ".4".
> > 
> > Except there are plenty of applications that don't do this so it is 
> > a real problem.
> 
> I do not really see what conclusion you draw from that fact. Yes,
> there are broken applications, I do not doubt it.

Actually they are not broken.  Only if you want to support IPv4
literals do you need to check.  The rules in RFC 1123 are designed
to prevent accidental matches when you only want to accept domain
names.

dig is a example of a application that does not check for IPv4
addresses as it is only expecting domain names.  If you want it to
treat the input as a address you have to explicitly tell so.

RFC 952 label rules prevented IPv4 address from ever being matched
even when searching because no label could match a address component.
The two were in different namespaces.  IPv4 address components all
start with a digit in all the forms of IPv4 address that I'm aware
of.  No hostname label could start with a digit.  Two disjoint sets.

RFC 1123 relaxed RFC 952 label rules but attempted to prevent
accidental matches in the multiple label case by assuming that
searches would not occur with multiple labels and by ensuring that
at least one of the labels, the last, would not be a valid address
component.

I would be quite happy to relax TLD labels so that they matched the
unmodified RFC 952 label and to explictly state that TLD labels
starting with a digit are prohibited to prevent accidental matches
against IPv4 address components.

> There are probably
> apps that try to resolve a domain name without checking before that it
> is not an IP address, hereby violating RFC 1123. These apps will have
> problems if ICANN delegates .NNN where NNN is a number.
> 
> But it does not imply that we should hardwire the no-digits rule in
> a RFC. For two reasons:
> 
> 1) There are applications that violate RFC 5322 (typically email
> syntax checkers on Web pages, which reject many valid RFC 5322
> addresses). Yet, we do not modify RFC 5322 to align it on these apps. 
> 
> 2) It may be a wise policy for ICANN to refuse the delegation of
> all-digits TLDs. But it is a policy issue, similar to registries (most
> TLD do so) which delegates only LDH domains (when the DNS would accept
> other names). There is zero technical reason to write down this limit
> in a RFC about the syntax. 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]