Re: ICANN to allow commercial gTLDs

[Mark Andrews <marka () isc org>]

In message <21633.1308527099 () nsa vix com>, Paul Vixie writes:
> Jay Ashworth <jra () baylink com> writes:
>
> > ... and that the root wouldn't be affected by the sort of things that
> > previously-2LD now TLD operators might want to do with their
> > monocomponent names...
>
> someone asked me privately a related question which is, if there's a .SONY
> and someone's web browser looks up http://sony/ and a root name server gets
> a query for SONY./IN/AAAA then what will happen?  the answer is happily that
> the result will be a delegation (no AAAA RR in the answer section even if
> the root name server knows one for some reason).  the answer section will be
> empty, the authority section will have a SONY/IN/NS RRset in it, and the
> additional section will have the nec'y IN/AAAA and IN/A RRsets for those NSs.
>
> this is sometimes called "the BIND9 behaviour" in contrast to BIND8/BIND4
> which would have answered the question if they knew the answer, even if they
> also knew that the qname had been delegated.  BIND9 changed this, and NSD
> does it the same way.  RFC 1034/1035 is pretty clear about this, so to be
> this should not be called "the BIND9 behaviour" but rather simply "correct".
>
> > which as someone pointed out, a 3-digit RFC forbids for security reasons
> > anyway.
>
> three digit?  i was thinking of <http://www.ietf.org/rfc/rfc1535.txt> which
> was written as air cover for me when i added the "ndots:NNN" behaviour to
> BIND4's stub resolver.  and, looking at firefox on my workstation just now:
>
> [58] 2011-06-19 23:27:49.906040 [#4 em1 0] \
>         [24.104.150.12].24003 [24.104.150.2].53  \
>         dns QUERY,NOERROR,57397,rd \
>         1 sony.vix.com,IN,A 0 0 0
> [58] 2011-06-19 23:27:49.909895 [#5 em1 0] \
>         [24.104.150.12].26356 [24.104.150.2].53  \
>         dns QUERY,NOERROR,57398,rd \
>         1 sony.vix.com,IN,AAAA 0 0 0
> [50] 2011-06-19 23:27:49.910489 [#6 em1 0] \
>         [24.104.150.12].23228 [24.104.150.2].53  \
>         dns QUERY,NOERROR,57399,rd \
>         1 sony,IN,A 0 0 0
> [50] 2011-06-19 23:27:49.930022 [#7 em1 0] \
>         [24.104.150.12].37238 [24.104.150.2].53  \
>         dns QUERY,NOERROR,57400,rd \
>         1 sony,IN,AAAA 0 0 0
> [58] 2011-06-19 23:27:49.931059 [#8 em1 0] \
>         [24.104.150.12].17401 [24.104.150.2].53  \
>         dns QUERY,NOERROR,33742,rd \
>         1 www.sony.com,IN,A 0 0 0
> [124] 2011-06-19 23:27:50.112451 [#9 em1 0] \
>         [24.104.150.2].53 [24.104.150.12].17401  \
>         dns QUERY,NOERROR,33742,qr|rd|ra \
>         1 www.sony.com,IN,A \
>         1 www.sony.com,IN,A,600,72.52.6.10 \
>         2 sony.com,IN,NS,172800,pdns1.cscdns.net \
>         sony.com,IN,NS,172800,pdns2.cscdns.net 0
>
> ...i see that the browser's stub is indeed looking at the search list first
> when there are no dots in the name.  that's correct behaviour by the RFC
> and also anecdotally since if i had an internal web server here called
> sony.vix.com i would want my web browser to assume that that was the one i
> wanted when i typed "http://sony/";.  having it go outside my network and
> hit a TLD first would be a dangerous information leak.  (this also shows
> DNS's lack of a formal presentation layer as clearly as anything ever
> could.)
>
> inevitably there will be folks who register .FOOBAR and advertise it as
> "http://foobar/"; on a billboard and then get burned by all of the local
> "foobar.this.tld" and "foobar.that.tld" names that will get reached
> instead of their TLD.  i say inevitable; i don't know a way to avoid it
> since there will be a lot of money and a lot of people involved.

Which just means we need to write yet another RFC saying that
resolvers shouldn't lookup simple host names in the DNS.  Simple
host names should be qualified against a search list.  Resolver can
still lookup simple names against /etc/hosts which covers localhost.

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