The NTIA issued a new notice to ICANN on Tuesday emphasizing it's desire for "functional separation" of IANA http://www.ntia.doc.gov/frnotices/2011/FR_IANA_<http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf> FurtherNOI_06102011.pdf<http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf> Larry Strickling spoke about it at the INET New York the same day http://bit.ly/inetnyarchive He also mentioned an extra hurdle- "in the global public interest" - for new gTLDs, surely inspired by .xxx j On Sun, Jun 19, 2011 at 12:51 PM, Jay Ashworth <jra@baylink.com> wrote:

----- Original Message -----

...

From: "Paul Vixie" <vixie@isc.org>

...

...

I believe the root server operators have stated (the equivalent of)

David Conrad <drc@virtualized.org> writes: that

...

it is not their job to make editorial decisions on what the root zone contains. They distribute what the ICANN/NTIA/Verisign gestalt publishes.

yes. for one example, see:

http://www.icann.org/en/announcements/announcement-04jan08.htm

other rootops who have spoken about this have said similar/compatible things.

Just to clarify, since I'm responsible for that particular red herring, I had at the time forgotten that the TLD zone don't actually *live* in the root -- I know; silly me, right? -- 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...

which as someone pointed out, a 3-digit RFC forbids for security reasons anyway.

Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

-- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.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

In message <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites:

(Mark:) 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.

I don't see the problem. I'm happily running with a empty search list for the last 25 year or so.

Which is your choice. Lots of others want search lists. I've seen requests for 20+ elements.

jaap

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

In message <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites:

Which is your choice. Lots of others want search lists. I've seen requests for 20+ elements.

So they get what they ask for: Ambiguity in resolving the name space.

jaap

There is no ambiguity if tld operators don't unilaterally add address records causing simple hostnames to resolve. Simple hostnames as, global identifiers, were supposed to cease to work in 1984. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <201106201034.p5KAYZ2e008023@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites:

Simple hostnames as, global identifiers, were supposed to cease to work in 1984.

Can you point out where that is stated?

jaap

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

In message <20110620190517.2242.qmail@joyce.lan>, "John Levine" writes:

...

...

Simple hostnames as, global identifiers, were supposed to cease to work in 1984.

Can you point out where that is stated?

jaap

RFC 897.

I see where it says that all of the hosts that existed in 1984 were supposed to change their names to something with at least two components, as part of the transition to the DNS. I think we can assume that process is now complete.

I don't see where it says that new DNS names can't have a single component. A page and line reference would be helpful.

Heirachical names have 2 or more labels or else they become simple names (one label). They are dis-joint sets. Then you hace RFC 1123 which explictly acknowledges the use of unqualified names. Simple names are indistingishable from unqualified names and unqualified names need to be qualified and the only syntaxically valid way to do that is to add a label. Although RFC-822 allows the local use of abbreviated domain names within a domain, the application of RFC-822 in Internet mail does not allow this. The intent is that an Internet host must not send an SMTP message header containing an abbreviated domain name in an address field. This allows the address fields of the header to be passed without alteration across the Internet, as required in Section 5.2.6. Then you have SUBMISSION, RFC 4409 section 4.2., Ensure All Domains Are Fully-Qualified. This allows simple names on input and says to qualify them. Or do you want more examples of where the use of simple names as global identifiers will cause things to break. Allowing or using address and MX records at the apex of a TLD is stupid, reckless behaviour. Configuring a TLD to behave as if it is a simple host names is stupid, reckless behaviour, i.e. be careful about which SRV records you add. Some are used with host names equivalents as suffixes and some arn't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Mon, 20 Jun 2011 18:39:00 MDT, Joel Maslak said:

I wonder what sort of money .wpad would be worth...

I was thinking .gbmh myself...

On Jun 20, 2011, at 12:14 AM, Mark Andrews wrote:

...

So they get what they ask for: Ambiguity in resolving the name space. There is no ambiguity if tld operators don't unilaterally add address records causing simple hostnames to resolve.

EDU.COM. Regards, -drc

On Jun 20, 2011, at 11:19 AM, Mark Andrews wrote:

do you want to issue a RFC that bans search lists?

Personally, I think search lists are a mistake and don't use them. If you do use them, then you are accepting a certain amount of ambiguity. Naked TLDs will increase that ambiguity and would recommend against their use, however there is no Internet Police to enforce such things (ICANN certainly isn't since ccTLDs can do whatever they like). I have significant doubt that an RFC will magically solve this problem (for any value of "this"). Regards, -drc

In message <20110620223618.2927.qmail@joyce.lan>, "John Levine" writes:

...

...

do you want to issue a RFC that bans search lists?

Personally, I think search lists are a mistake and don't use them.

You're in good company. It's hard to find a modern mail system that allows abbreviated domain names in addresses. I just checked the mail at AOL, Yahoo, Gmail, and Hotmail, and the one at Tucows which is used by a lot of large corporate mail systems, and none of them will let you send a message to an address like foo@bar. Note that Yahoo and Hotmail each handle mail for many large ISPs.

Abbreviated names make perfect sense within a company be they mail (submission), ssh or telnet or within the home.

There's a lot of advice that made sense in 1989 which is irrelevant now. Programming around mail systems that rewrite partially qualified addresses is in that category. It may not be possible for people to send mail to addresses like n@ai, but that's a very different problem from it going to the wrong place.

R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <B568F14D-2D30-4501-BAC9-FB3B4125ADE8@virtualized.org>, David Conrad writes:

On Jun 20, 2011, at 11:19 AM, Mark Andrews wrote:

...

do you want to issue a RFC that bans search lists?

Personally, I think search lists are a mistake and don't use them. If you do use them, then you are accepting a certain amount of ambiguity. Naked TLDs will increase that ambiguity and would recommend against their use, however there is no Internet Police to enforce such things (ICANN certainly isn't since ccTLDs can do whatever they like). I have significant doubt that an RFC will magically solve this problem (for any value of "this").

While there are no internet police, they are not supposed to exist and ICANN and the IAB can make statements to that effect. Similarly ICANN could direct Verisign to meet its RFC 1034 requirements by ensuring that regular checks of delegations be made to ensure they both sides of the zone cut are consistent and if not ensure that steps are take to make them constistent. ICANN and Verisign don't pick up the support cost caused by Verisign's and ultimately ICANN's failure to ensure these checks are done. The support costs falls to ISPs and nameserver vendors explaining that lookups are failing because the delegation in broken. Broken delegations that should have been caught and corrected by the regular checks. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <201106202158.p5KLwAxW088140@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites:

(Marka) See RFC 1535. Yes, a mistake was made implementing search lists. A RFC was issued to say don't do search lists this way.

Which RFC? What way?

RFC 1535. A Security Problem and Proposed Correction With Widely Deployed DNS Software It had to do with how search lists are constructed and processed. A wildcard record for *.EDU.COM was added it broke communications from COM sites to EDU sites by creating a unexpected match. It is the unexpected match that is the problem not the wildcard though that made *lots* more unexpected matches. If you want the gory detail I can give them to you. It is the unexpected match that is the problem with simple hostnames as global identifiers. People expect global identifiers to work globally and simple hostnames can't in the presence of search lists as they produce unexpected matches.

It would be nice if you would say what you mean instead keep referring to things the reader has to guess.

jaap

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

On Sun, Jun 19, 2011 at 08:22:17PM -0400, Jay Ashworth wrote:

----- Original Message -----

...

From: "Paul Vixie" <vixie@isc.org>

...

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.

I think it's probably worse than that, since a lot of the companies who might be foolish enough to try that *are companies that make stuff that's on your LAN*... and what are you going to name the *one* Apple server that's on your LAN in your internal DNS?

Of course; you're gonna call it "apple".

And it only gets better from there... how many places have various "cutesy" naming schemes that might include one or more trademarks (or whatever) that someone might want as a TLD? A naming scheme involving fruit would cover your "apple" example, but I'd bet that someone, somewhere, names their servers after fast food restaurants or brands of shoe... and I'm confident in predicting that there are plenty of cartoon characters that some company or another will want to turn into a TLD. - Matt -- When all you have is a nailgun, every problem looks like a messiah. -- Iain Chalmers, ASR

On Jun 19, 2011, at 9:51 AM, Jay Ashworth wrote:

----- Original Message -----

...

From: "Paul Vixie" <vixie@isc.org>

...

David Conrad <drc@virtualized.org> writes:

...

I believe the root server operators have stated (the equivalent of) that it is not their job to make editorial decisions on what the root zone contains. They distribute what the ICANN/NTIA/Verisign gestalt publishes.

yes. for one example, see:

http://www.icann.org/en/announcements/announcement-04jan08.htm

other rootops who have spoken about this have said similar/compatible things.

Just to clarify, since I'm responsible for that particular red herring, I had at the time forgotten that the TLD zone don't actually *live* in the root -- I know; silly me, right? -- 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...

which as someone pointed out, a 3-digit RFC forbids for security reasons anyway.

My point is that there is a relatively small group of root operators and I consider them generally clueful and likely to comply with RFCs other than through accidental violation. OTOH, I can easily see $COMPANY deciding that $RFC is not in their best interests and find the http://microsoft construct not at all unlikely. I realize that no responsible software vendor would ever deliberately do something insecure or contrary to a security-oriented RFC, but, history has shown that not all software vendors are responsible. Now imagine the number of corporate IT departments that can't even spell RFC, but, they run web servers and DNS servers... Yeah, under the coming circumstances, the expectation that said 3-digit RFC will remain anything more than a novel collection of bits on an FTP server somewhere is, well, optimistic at best. Owen