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