ICANN to allow commercial gTLDs

Paul Vixie vixie at isc.org
Sun Jun 19 23:44:59 UTC 2011


Jay Ashworth <jra at 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.
-- 
Paul Vixie
KI6YSY




More information about the NANOG mailing list