Re: unqualified domains, was ICANN to allow commercial gTLDs

[Mark Andrews <marka () isc org>]

In message <4DFEDB8B.5080301 () dougbarton us>, Doug Barton writes:
> On 06/19/2011 19:31, Paul Vixie wrote:
> > > Date: Sun, 19 Jun 2011 19:22:46 -0700
> > > From: Michael Thomas<mike () mtcc com>
> > >
> > > > that's a good question.  marka mentioned writing an RFC, but i expect
> > > > that ICANN could also have an impact on this by having applicants sign
> > > > something that says "i know that my single-label top level domain name
> > > > will not be directly usable the way normal domain names are and i intend
> > > > to use it only to register subdomain names which will work normally."
> > >
> > > Isn't this problem self regulating? If sufficient things break with a
> > > single label, people will stop making themselves effectively unreachable,
> > > right?
> >
> > alas, no.  if someone adds something to the internet that doesn't work righ
> t
> > but they ignore this and press onward until they have market share, then th
> e
> > final disposition will be based on market size not on first mover advantage
> .
>
> I think you're going to see 2 primary use cases. Those who will do it 
> anyway, either because they are ignorant of the possible downsides, or 
> don't care. The other use case will be the highly risk-averse folks who 
> won't unconditionally enable IPv6 on their web sites because it will 
> cause problems for 1/2000 of their customers.
>
> If it will make $YOU (not nec. Paul or Michael) feel better, sure 
> produce an RFC. Shout it from the housetops, whatever. You're not going 
> to change anyone's mind.
>
> Meanwhile, David is right. Further pontificating on this topic without 
> even reading the latest DAG is just useless nanog-chin-wagging. 
> Completely aside from the fact that the assumption no one in the ICANN 
> world has put any thought into this for the last 10+ years is sort of 
> insulting.
>
>
> Doug
>
> -- 
>
>       Nothin' ever doesn't change, but nothin' changes much.
>                       -- OK Go
>
>       Breadth of IT experience, and depth of knowledge in the DNS.
>       Yours for the right price.  :)  http://SupersetSolutions.com/

Where is the addition of address/mx records at the zone apex prohibited?

B.T.W. Address and mx records are very common, just their *use* at
the apex of a TLD is or should be uncommon.

There is also no such thing as "in-bailiwick glue for the TLD’s DNS
servers".  The root zone contains glue for TLDs.  No TLD zone
contains glue for TLDs.

The agreement explicitly outlaws the use of wildcard records.  It
would not have been hard to explicitly outlaw the addition of address
and MX records at the zones apex.  One can only think that the loose
wording here was done to explictly allow address and MX records at
the apex of a TLD.

Mark

2.2.3.3   TLD Zone Contents

ICANN receives a number of inquiries about use of various 
record types in a registry zone, as entities contemplate 
different business and technical models. Permissible zone 
contents for a TLD zone are: 

* Apex SOA record.  
* Apex NS records and in-bailiwick glue for the TLD’s
  DNS servers. 
* NS records and in-bailiwick glue for DNS servers of 
  registered names in the TLD. 
* DS records for registered names in the TLD. 
* Records associated with signing the TLD zone (i.e., 
  RRSIG, DNSKEY, NSEC, and NSEC3). 

An applicant wishing to place any other record types into 
its TLD zone should describe in detail its proposal in the 
registry services section of the application. This will be 
evaluated and could result in an extended evaluation to 
determine whether the service would create a risk of a 
meaningful adverse impact on security or stability of the 
DNS.  Applicants should be aware that a service based on 
use of less-common DNS resource records in the TLD zone, 
even if approved in the registry services review, might not 
work as intended for all users due to lack of application 
support.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org