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

From: "Joel Barnard" <jbarnard@nwic.ca>

I hope they've considered what will happen if you go to http://localhost/ or http://pcname/

Is that the local networks pcname, or the gTld pcname? Are we going to have to start using a specially reserved .local gTld?

No, of *course* ICANN didn't give any engineering thought to it. Cause the engineers? Are all *here*. And David Conrad's apparently the only guy who's heard about it. :-) 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

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

From: "Zaid Ali" <zaid@zaidali.com>

I have seen many NANOG folks at ICANN meetings discussing this and also active on ALAC so David isn't the only guy. Also do a search on the list and you will find threads dating back.

http://article.gmane.org/gmane.org.operators.nanog/56728/match=gTLDs

Noted. Retracted on that point. 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

i am not learning anything here. well, except maybe that someone who normally has his head up his butt also had it in the sand. what's new? how about the operational technical effects, like data from modeling various resolvers' responses to a large root zone? randy

On Jun 20, 2011, at 2:35 AM, Robert E. Seastrom wrote:

Randy Bush <randy@psg.com> writes:

...

what's new? how about the operational technical effects, like data from modeling various resolvers' responses to a large root zone?

Yep. That is an area that has been identified as needing additional study (see comments by kc, summarized in http://www.icann.org/en/topics/new-gtlds/summary-analysis-root-zone-scaling-...).

Things can get hairy with high update rates, so I'd encourage ICANN to dig in its heels about the 2x per day update rate

I don't know anyone who is pushing to increase the update rate of the root zone.

An interesting question is what the load effects will be on the root.

One of the studies relevant to this was done by DNS-OARC. See http://www.icann.org/en/topics/ssr/root-zone-augementation-analysis-17sep09-.... There was an intent to do some follow-on studies, but from ICANN's perspective the interesting scaling questions turned out to be related to the provisioning side, so focus moved away from impact on the root servers. Regards, -drc

well, crap. That's all I have to say :( On Fri, Jun 17, 2011 at 4:16 PM, mikea <mikea@mikea.ath.cx> wrote:

On Fri, Jun 17, 2011 at 05:04:25PM -0400, Jay Ashworth wrote:

...

Aw, Jeezus.

No. Just, no.

http://tech.slashdot.org/story/11/06/17/202245/

Yeah. Maybe ICANN needs its own special TLD: .idiots?

-- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin

On 06/17/2011 14:23, Jay Ashworth wrote:

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

...

From: "David Conrad"<drc@virtualized.org>

...

On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote:

...

Aw, Jeezus.

No. Just, no.

http://tech.slashdot.org/story/11/06/17/202245/

You just learned about this now?

In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 months or so; where should I have seen it?

More things on heaven and earth Horatio ... -- 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/

On 06/17/2011 11:33 AM, David Conrad wrote:

On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote:

...

...

...

http://tech.slashdot.org/story/11/06/17/202245/ You just learned about this now? In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 months or so; where should I have seen it? New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long....

Regards, -drc I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet.

Paul

On Jun 17, 2011, at 2:44 PM, Paul Graydon wrote:

On 06/17/2011 11:33 AM, David Conrad wrote:

...

On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote:

...

...

...

http://tech.slashdot.org/story/11/06/17/202245/ You just learned about this now? In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 months or so; where should I have seen it? New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long....

Regards, -drc I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet.

Paul

There has been a lot of work put into this. I suggest you start looking at the application guide book http://www.icann.org/en/topics/new-gtlds/dag-en.htm If folks have been debating about this for 10 years then you can be assured the concerns of a messy internet have been brought up. Don't tell me folks will have an existential moment about IDN's and gTLD. Zaid

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

From: "Patrick W. Gilmore" <patrick@ianai.net>

As for calling ICANN stupid, thinking this will help fracture the 'Net, I think you are all confused. I think the NANOG community has become (OK, always was) a bit of an echo chamber. Trust me when I say we are the minority. Most people think very differently, and we better accept that if we hope to affect things outside our little group.

We may be the minority, but my experience is we have a pretty good record at spotting where the pinch points might come up in proposed expansions/ changes. http://apple/ is going to break a bunch of shit. (Ok, it might or might not break actual browsers, but I have seen "require at least one dot or assume it's not a domain name" in *lots* of code; the inability to put sjobs@apple in your address book will not be popular.) Interstate-level traffic engineering types are not a big political bloc, either... but no one ignores them when building Interstates. 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

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

From: "Joel Jaeggli" <joelja@bogus.com>

On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote:

...

http://apple/ is going to break a bunch of shit.

All fully qualified domain names have a trailing dot so that you know where the root is. At least as parsed internally by your resolver...

Sure. And Apple's gonna make sure they put that trailing dot in their ads and links and stuff... and their users will, without fail, remember to type it. :-) Oh, it is Friday night, isn't it? 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

On Jun 17, 2011, at 7:09 PM, David Conrad wrote:

On Jun 17, 2011, at 4:00 PM, Jay Ashworth wrote:

...

...

On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote:

...

http://apple/ is going to break a bunch of shit.

All fully qualified domain names have a trailing dot so that you know where the root is. At least as parsed internally by your resolver...

Sure. And Apple's gonna make sure they put that trailing dot in their ads and links and stuff... and their users will, without fail, remember to type it. :-)

I suspect the folks who spend $185K + yearly fees will be able to afford engineering staff that will point out that a naked TLD is unlikely to work for the great unwashed masses. And if they don't, they'll get exactly what they deserve.

That won't stop them from building zone files that look like this: @ IN SOA ... NS ... ... A ... AAAA ... www A ... AAAA ... Sure, they'll advertise www.apple, but, you better believe that they'll take whatever lands at http://apple and you can certainly count on the fact that any mal-actors that get control of one of these TLDs (whether they paid the $185k or not) will take full advantage of the situation and its security risks.

What I suspect you'll more likely see will be macbook.apple or japan.cisco or copyright-enforcement.universal.

Sure, you'll see all of that, TOO. They're not mutually exclusive.

Maybe.

Almost certainly. Owen

On Jun 17, 2011, at 7:40 PM, Jay Ashworth wrote:

---- Original Message -----

...

From: "Owen DeLong" <owen@delong.com>

...

That won't stop them from building zone files that look like this:

@ IN SOA ... NS ... ... A ... AAAA ... www A ... AAAA ...

Sure, they'll advertise www.apple, but, you better believe that they'll take whatever lands at http://apple and you can certainly count on the fact that any mal-actors that get control of one of these TLDs (whether they paid the $185k or not) will take full advantage of the situation and its security risks.

Not necessarily, Owen. Remember: Since we're *in the TLD space* now, you can't capture the unmodified domain *without adding records to the root*:

You can, actually... It is perfectly valid for example, in COM to have: delong.com. IN NS ns.delong.org. IN NS ns2.delong.org. and have ns/ns2 .delong.org. return the following: delong.com. IN SOA ....... IN NS ns.delong.org. ns2.delong.org. A 192.159.10.2 AAAA 2620:0:930::200:2 www IN A 192.159.10.7 AAAA 2620:0:930::400:7 Why would this not work equally well for APPLE where the root zone would have: apple. IN NS ...... IN NS ...... Where you would then have the detail (as above in the delong.com zone file) contained in the apple. zone file on the specified authoritative nameservers?

apple.com and www.apple.com are in the same zone file

apple and www.apple are in the same zone file to that extent as well. apple.com is a delegation from .com just as apple is a delegation from .

apple. and www.apple. are *not* -- and the root operators may throw their hands up in the air if anyone asks them to have anything in their zone except glue -- rightly, I think; it's not a degree of complexity that's compatible with the required stability of the root zone.

Sir, either you are very confused, or, I am. I am saying that TLDs behave with the same delegation rules as SLDs, which I believe to be correct. You are claiming that TLDs are in some way magical and that the ability to delegate begins at SLDs. I think the fact that there is data in the COM zone separate from the root indicates that I am correct.

Especially since the root zone actually lives in 14 different places.

But the root zone would still only contain delegation and possibly glue. Everything else would still be in the zone file, just like a subdelegation of COM for apple.com, but, this would be a subdelegation of . for apple.

No, anything that requires the root zone to be fluid[1] is going to cause even more fundamental engineering problems than I've been positing so far tonight.

I agree, but, this doesn't require that to happen. It might cause it to happen without root zone operator intervention (which may be worse), but, it doesn't require the root zone operators to cooperate beyond delegating the TLDs which seems pretty much assured by the current announcement. Owen

On Jun 17, 2011, at 8:36 PM, Jay Ashworth wrote:

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

...

From: "Owen DeLong" <owen@delong.com>

...

apple.com is a delegation from .com just as apple is a delegation from .

...

apple. and www.apple. are *not* -- and the root operators may throw their hands up in the air if anyone asks them to have anything in their zone except glue -- rightly, I think; it's not a degree of complexity that's compatible with the required stability of the root zone.

Sir, either you are very confused, or, I am. I am saying that TLDs behave with the same delegation rules as SLDs, which I believe to be correct. You are claiming that TLDs are in some way magical and that the ability to delegate begins at SLDs. I think the fact that there is data in the COM zone separate from the root indicates that I am correct.

I could be wrong--Cricket Liu I am not--but the point I'm trying to make is that the record "apple." does not *live* inside the zone server for the "apple" TLD; it lives in ".".

You are, indeed, wrong. In . lives a pointer to apple. consisting of one or more NS records and possibly some A/AAAA glue for those nameservers if they are within apple. In the apple. zone file lives everything else about apple. including the SOA record for apple. Just as in COM lives one or more NS records for APPLE.COM and possibly some A/AAAA glue for NS that live within APPLE.COM. Inside the APPLE.COM zone file, OTOH, lives everything else about APPLE.COM including the SOA for APPLE.COM.

The people who operate the "apple" zone can apply an A record to "www.apple"...

Oh. Wait.

I'm sorry: you're right. It's been so long since I climbed that far up the tree, I'd forgotten, the TLDs don't *live* in the root servers.

EXACTLY.

So people operating a cTLD like "apple." would have to run their own analog of gtld-servers.net, to which the zone would be delegated, and such fanciness could happen there.

EXACTLY.

Ok; so *this* bit of opposition was a red herring. :-)

YES. Have a nice day. Owen

Jay, On Jun 17, 2011, at 4:40 PM, Jay Ashworth wrote:

and the root operators may throw their hands up in the air if anyone asks them to have anything in their zone except glue -- rightly, I think; it's not a degree of complexity that's compatible with the required stability of the root zone.

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.

Especially since the root zone actually lives in 14 different places.

It lives in _far_ more places than that.

No, anything that requires the root zone to be fluid[1] is going to cause even more fundamental engineering problems than I've been positing so far tonight.

http://www.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling... Folks of varying levels of technical, business, and political expertise have been working on the expansion of the root zone for more than a decade. I might suggest that instead of assuming people haven't thought of the issues you are raising, you might want to take the opposite approach and ask for pointers for the analyses.

[1]requiring updates in anything smaller than days. How often does the root zone actually change; anyone got a pointer to stats on that?

The root zone is updated two times a day. Relevant folks have stated this will not be changing. Regards, -drc

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.

That has always been the case in the past. Given the level of public unhappiness that the US Dep't of Commerce has with ICANN's plan to add zillions of new TLDs, and noting that several of the root servers are run by agencies of the US government, who knows what will happen in the future. R's, John

...

run by agencies of the US government, who knows what will happen in the future.

I'm not so sure volunteer root operators are in a position to editorialize and for that to have a positive effect. ICANN could go down the path of stating that this causes internet stability (due to operators publishing a partial root).

It is not my impression that the volunteer root operators have any great love for ICANN. They have carefully avoided making any agreements with ICANN that oblige them to do anything other than notify ICANN if they think something interesting is going on. If the USG operators said "sorry, the DOJ anti-trust rules don't allow us to serve a zone with .HONDA and .BACARDI", why would the the pressure be on them rather than on ICANN? Nobody outside the ICANN bubble cares about more TLDs.

That would then be sufficient justification to remove root server operators from the root zone

How do you propose to do that? The addresses of the roots are hard wired into the config of a million DNS caches around the world. If it came to a fight between ICANN and the root operators, it is hard to see how ICANN could win. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly

On Fri, Jun 17, 2011 at 11:44:07AM -1000, Paul Graydon wrote:

[...] I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet.

Maybe we could demote the commercial ones to live under a single TLD to make things simpler/neater... :-)

Paul Graydon wrote:

I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet.

I don't know about you, but *I* really like to browse to http://google.google or https://yahoo.yahoo or http://microsoft.microsoft (or www.microsoft.microsoft, or www.com.microsoft, or...) instead of their .com equivalents. It makes perfect sense. Except I fear the extra characters transmitted may add to the global CO2 emmissions ;~C In addition, from TFA: ""We're advising people to buy their brands, park them and redirect visitors to their existing site, at the very least," says Hnarakis, whose more than 3,500 customers include Volvo, Lego and GlaxoSmithKline." I for one welcome the increased influx of money to registrars world wide and ICANN in particular. The more money goes to the "those who operate the c0re of the innernets" the more tools they have to improve it. Forward we go, never look back. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html

And no, I had not heard *any noise* that anyone was seriously considering this up until this announcement. Overhere it got mentioned in the local news paper a couple of times. jaap

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

From: "David Conrad" <drc@virtualized.org>

"Finally, because pancakes are calling, the very complainants of squatting and defensive registration (the 1Q million-in-revenue every applicant for an "open", now "standard" registry places in its bizplan), the Intellectual Property Stakeholder Group is also an advocate for trademark TLDs, arguing that possession of $fee and a registry platform contract (there is now a niche industry of boutique ".brand" operators-in-waiting) and a $bond establishes an absolute right to a label in the IANA root.

So, rather than memorizing the digits of Pi, for some later public recitation, one could start reciting brand names, for some later public recitation, for as long as there is a single unified root."

See http://mailman.nanog.org/pipermail/nanog/2011-March/034692.html for full context.

That's an *amazingly* oblique and de minimis reference to the topic on point, couched in Eric's usually opaque language, and buried in a thread I'd long since stopped paying attention to by that point; my apologies to you for not having seen it, since you seem to feel that's material. Cheers, -- jr 'I wouldn't call it a datapoint, though' a -- 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

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

From: "David Conrad" <drc@virtualized.org>

On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote:

...

That's an *amazingly* oblique and de minimis reference to the topic on point, couched in Eric's usually opaque language,

Eric's writing style does take a bit of getting used to, but I usually find it enlightening (albeit occasionally in an existential way) :-).

Nicely put.

...

and buried in a thread I'd long since stopped paying attention to by that point;

It was the third message in the thread.

Yeah, I stopped after the first one.

...

my apologies to you for not having seen it, since you seem to feel that's material.

No need to apologize. As I said, I've been in layer 9 too long so I figured the whole .brand thing was common knowledge. Sounds like ICANN should have a liaison to the NANOG world (perhaps the ARIN region ASO AC members can't do that?).

I enter layers 8 and 9 only at gunpoint. (It's people, and money, ascending, right?) 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

On Jun 17, 2011, at 6:36 PM, David Conrad wrote:

On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote:

...

That's an *amazingly* oblique and de minimis reference to the topic on point, couched in Eric's usually opaque language,

Eric's writing style does take a bit of getting used to, but I usually find it enlightening (albeit occasionally in an existential way) :-).

...

and buried in a thread I'd long since stopped paying attention to by that point;

It was the third message in the thread.

...

my apologies to you for not having seen it, since you seem to feel that's material.

No need to apologize. As I said, I've been in layer 9 too long so I figured the whole .brand thing was common knowledge. Sounds like ICANN should have a liaison to the NANOG world (perhaps the ARIN region ASO AC members can't do that?).

Regards, -drc

I really don't think that namespace issues are part of the role for the ASO AC. This is clearly a problem for ICANN's disaster-ridden domain-name side, and not for the ASO/NRO side of things. Frankly, it hadn't occurred to me that ICANN would actually do this, but, now that it's happening, it doesn't really surprise me. Operationally, it's a horrible idea, but, most of us in layers 1-4 stopped paying much attention to the disasters happening at ICANN for DNS along time ago as we sort of came to believe that we didn't have enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently meaningful way to make our voices heard. Owen

On Jun 17, 2011, at 7:13 PM, David Conrad wrote:

On Jun 17, 2011, at 4:04 PM, Owen DeLong wrote:

...

I really don't think that namespace issues are part of the role for the ASO AC.

Why do you think there is an ASO?

To coordinate numberspace issues between the IANA and the RIRs.

...

This is clearly a problem for ICANN's disaster-ridden domain-name side, and not for the ASO/NRO side of things.

Because there is clearly no inter-relation between domains and address and the operation of the Internet.

Oh, there is tremendous inter-relation. However, making a mess and then punting it to the ASO is an entirely different matter.

...

Operationally, it's a horrible idea, but, most of us in layers 1-4 stopped paying much attention to the disasters happening at ICANN for DNS along time ago as we sort of came to believe that we didn't have enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently meaningful way to make our voices heard.

Aren't you one of the folks who state that if you don't participate in PPML then you have no reason to criticize ARIN policies?

It doesn't cost anything to participate in PPML. Owen

On Jun 17, 2011, at 9:13 PM, David Conrad wrote:

On Jun 17, 2011, at 4:04 PM, Owen DeLong wrote:

...

I really don't think that namespace issues are part of the role for the ASO AC.

Why do you think there is an ASO?

...

This is clearly a problem for ICANN's disaster-ridden domain-name side, and not for the ASO/NRO side of things.

Because there is clearly no inter-relation between domains and address and the operation of the Internet.

...

Operationally, it's a horrible idea, but, most of us in layers 1-4 stopped paying much attention to the disasters happening at ICANN for DNS along time ago as we sort of came to believe that we didn't have enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently meaningful way to make our voices heard.

Aren't you one of the folks who state that if you don't participate in PPML then you have no reason to criticize ARIN policies?

+1 -- If you haven't bothered to be involved, you have lost the right to kvetch… If enough operational folk had bothered to stay involved, ICANN would be more operational. Claiming that it is all driven by money is a cop out. Yes, it's very political, yes there are LOTS of lawyers and policy folk, yes the atmosphere is not fun, yes the registries and registrars are the big players (because they have bothered to play), but technical folk CAN and DO make a difference… Warren "serves on the SSAC" Kumari

Regards, -drc

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

From: "Fred Baker" <fred@cisco.com>

Yes. Since ICANN was formed, they have periodically come to the IETF to ask how many TLDs we thought the system could support. On the basis of the SLD count (if example.com is a domain name and ".com" is a TLD, "example" is an SLD) within recognized gTLDs like .com, I would have to say that a properly maintained database can handle a very large number of names in a flat name space. That said, that does not imply that the DNS should be replaced with a flat namespace; there's this "scaling" thing that competent people think about.

What I told them, periodically, as IETF Chair, was that the number of TLDs in the network was largely a business discussion. If a potential TLD came forth with a business plan that made sense, fine, and if the business plan didn't pencil out, there was no sense in adding the TLD. Given the number of times they asked, that wasn't a satisfactory response; they wanted a number.

In this case, I would look at it this way. Imagine that ICANN wanted to go into the business of selling SLDs in competition with .com etc. How would they go about it? There are two obvious ways: they could create a new TLD such as ".icann" and sell names like "example.icann". Or, the could start selling TLDs on the open market. The really nice thing from their perspective would be that they don't need to maintain the database, bandwidth, or putzpower needed to supply the service - they already have a set of root zone operators that have volunteered to do so. So, they make money on the names and deliver the service for free.

And that's fine... but it still doesn't forsee the idea that a registry *could be it's own -- and only -- client*. For me, the engineering problem remains *single-component FQDNs*. I can't itemize the code they'll break, but I'm quite certain there's a lot. 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

The notion of a single-component FQDN would be quite a breakage for the basic concept of using both FQDNs and Unqualified names.

Well, you know, there's a guy whose email address has been n@ai for many years. People have varying amounts of success sending him mail. R's, John

Now I'm tempted to be the guy that gets .mail On Fri, Jun 17, 2011 at 20:47, Jay Ashworth <jra@baylink.com> wrote:

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

...

From: "John Levine" <johnl@iecc.com>

...

...

The notion of a single-component FQDN would be quite a breakage for the basic concept of using both FQDNs and Unqualified names.

Well, you know, there's a guy whose email address has been n@ai for many years. People have varying amounts of success sending him mail.

My Zimbra UI says it "might be invalid"; the default postfix config inside it tries to send it to n@ai.baylink.com, and complains because the domain won't resolve.

If I'm reading 3.2.4 of 2822 properly (that notation is one I'm not entirely familiar with, and should be), that really is a valid 2822 address, as odd as it sounds.

Clearly, it's semantics are unexpected, though. I guess I should go hang a bug on it.

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

Once upon a time, Randy Bush <randy@psg.com> said:

...

Now I'm tempted to be the guy that gets .mail

express that temptation in dollars, and well into two commas.

Imagine the "typo-squating" someone could do with .con. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Jun 19, 2011, at 11:59 AM, David Conrad wrote:

On Jun 19, 2011, at 8:49 AM, Chris Adams wrote:

...

Once upon a time, Randy Bush <randy@psg.com> said:

...

...

Now I'm tempted to be the guy that gets .mail express that temptation in dollars, and well into two commas. Imagine the "typo-squating" someone could do with .con.

See section 2.2.1.1 (and section 2.1.2) of http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf

Regards, -drc

To save others some eye strain (apologies for the format when pasted from PDF): 2.1.2 History of cybersquatting ICANN will screen applicants against UDRP cases and legal databases as financially feasible for data that may indicate a pattern of cybersquatting behavior pursuant to the criteria listed in section 1.2.1. The applicant is required to make specific declarations regarding these activities in the application. Results returned during the screening process will be matched with the disclosures provided by the applicant and those instances will be followed up to resolve issues of discrepancies or potential false positives. If no hits are returned, the application will generally pass this portion of the background screening. and 2.2.1.1 String Similarity Review This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings. Note: In this Applicant Guidebook, “similar” means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity. This similarity review will be conducted by an independent String Similarity Panel. 2.2.1.1.1 Reviews Performed The String Similarity Panel’s task is to identify visual string similarities that would create a probability of user confusion. The panel performs this task of assessing similarities that would lead to user confusion in four sets of circumstances, when comparing:  Applied-for gTLD strings against existing TLDs and reserved names;  Applied-for gTLD strings against other applied-for gTLD strings;  Applied-for gTLD strings against strings requested as IDN ccTLDs; and  Applied-for 2-character IDN gTLD strings against: o Every other single character. o Any other 2-character ASCII string (to protect possible future ccTLD delegations). Module 2 Evaluation ProceduresApplicant Guidebook (30 May 2011) 2-5 Module 2 Evaluation Procedures Similarity to Existing TLDs or Reserved Names – This review involves cross-checking between each applied-for string and the lists of existing TLD strings and Reserved Names to determine whether two strings are so similar to one another that they create a probability of user confusion. In the simple case in which an applied-for gTLD string is identical to an existing TLD or reserved name, the online application system will not allow the application to be submitted. Testing for identical strings also takes into consideration the code point variants listed in any relevant IDN table. For example, protocols treat equivalent labels as alternative forms of the same label, just as “foo” and “Foo” are treated as alternative forms of the same label (RFC 3490). All TLDs currently in the root zone can be found at http://iana.org/domains/root/db/. IDN tables that have been submitted to ICANN are available at http://www.iana.org/domains/idn-tables/. Similarity to Other Applied-for gTLD Strings (String Contention Sets) – All applied-for gTLD strings will be reviewed against one another to identify any similar strings. In performing this review, the String Similarity Panel will create contention sets that may be used in later stages of evaluation. A contention set contains at least two applied-for strings identical or similar to one another. Refer to Module 4, String Contention Procedures, for more information on contention sets and contention resolution. ICANN will notify applicants who are part of a contention set as soon as the String Similarity review is completed. (This provides a longer period for contending applicants to reach their own resolution before reaching the contention resolution stage.) These contention sets will also be published on ICANN’s website. Similarity to TLD strings requested as IDN ccTLDs -- Applied- for gTLD strings will also be reviewed for similarity to TLD strings requested in the IDN ccTLD Fast Track process (see http://www.icann.org/en/topics/idn/fast-track/). Should a conflict with a prospective fast-track IDN ccTLD be identified, ICANN will take the following approach to resolving the conflict. Applicant Guidebook (30 May 2011) 2-6 Module 2 Evaluation Procedures If one of the applications has completed its respective process before the other is lodged, that TLD will be delegated. A gTLD application that has successfully completed all relevant evaluation stages, including dispute resolution and string contention, if applicable, and is eligible for entry into a registry agreement will be considered complete, and therefore would not be disqualified by a newly-filed IDN ccTLD request. Similarly, an IDN ccTLD request that has completed evaluation (i.e., is validated) will be considered complete and therefore would not be disqualified by a newly-filed gTLD application. In the case where neither application has completed its respective process, where the gTLD application does not have the required approval from the relevant government or public authority, a validated request for an IDN ccTLD will prevail and the gTLD application will not be approved. The term “validated” is defined in the IDN ccTLD Fast Track Process Implementation, which can be found at http://www.icann.org/en/topics/idn. In the case where a gTLD applicant has obtained the support or non-objection of the relevant government or public authority, but is eliminated due to contention with a string requested in the IDN ccTLD Fast Track process, a full refund of the evaluation fee is available to the applicant if the gTLD application was submitted prior to the publication of the ccTLD request. Review of 2-character IDN strings — In addition to the above reviews, an applied-for gTLD string that is a 2- character IDN string is reviewed by the String Similarity Panel for visual similarity to: a) Any one-character label (in any script), and b) Any possible two-character ASCII combination. An applied-for gTLD string that is found to be too similar to a) or b) above will not pass this review. 2.2.1.1.2 Review Methodology The String Similarity Panel is informed in part by an algorithmic score for the visual similarity between each applied-for string and each of other existing and applied- for TLDs and reserved names. The score will provide one objective measure for consideration by the panel, as part of the process of identifying strings likely to result in user confusion. In general, applicants should expect that a higher visual similarity score suggests a higher probability Module 2 Evaluation Procedures that the application will not pass the String Similarity review. However, it should be noted that the score is only indicative and that the final determination of similarity is entirely up to the Panel’s judgment. The algorithm, user guidelines, and additional background information are available to applicants for testing and informational purposes.2 Applicants will have the ability to test their strings and obtain algorithmic results through the application system prior to submission of an application. The algorithm supports the common characters in Arabic, Chinese, Cyrillic, Devanagari, Greek, Japanese, Korean, and Latin scripts. It can also compare strings in different scripts to each other. The panel will also take into account variant characters, as defined in any relevant language table, in its determinations. For example, strings that are not visually similar but are determined to be variant TLD strings based on an IDN table would be placed in a contention set. Variant TLD strings that are listed as part of the application will also be subject to the string similarity analysis.3 The panel will examine all the algorithm data and perform its own review of similarities between strings and whether they rise to the level of string confusion. In cases of strings in scripts not yet supported by the algorithm, the panel’s assessment process is entirely manual. The panel will use a common standard to test for whether string confusion exists, as follows: Standard for String Confusion – String confusion exists where a string so nearly resembles another visually that it is likely to deceive or cause confusion. For the likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. Mere association, in the sense that the string brings another string to mind, is insufficient to find a likelihood of confusion. 2.2.1.1.3 Outcomes of the String Similarity Review An application that fails the String Similarity review due to similarity to an existing TLD will not pass the Initial Evaluation, 2 See http://icann.sword-group.com/algorithm/ 3 In the case where an applicant has listed Declared Variants in its application (see subsection 1.3.3), the panel will perform an analysis of the listed strings to confirm that the strings are variants according to the applicant’s IDN table. This analysis may include comparison of applicant IDN tables with other existing tables for the same language or script, and forwarding any questions to the applicant. Applicant Guidebook (30 May 2011) 2-7 Module 2 Evaluation Procedures and no further reviews will be available. Where an application does not pass the String Similarity review, the applicant will be notified as soon as the review is completed. An application for a string that is found too similar to another applied-for gTLD string will be placed in a contention set. An application that passes the String Similarity review is still subject to objection by an existing TLD operator or by another gTLD applicant in the current application round. That process requires that a string confusion objection be filed by an objector having the standing to make such an objection. Such category of objection is not limited to visual similarity. Rather, confusion based on any type of similarity (including visual, aural, or similarity of meaning) may be claimed by an objector. Refer to Module 3, Dispute Resolution Procedures, for more information about the objection process. An applicant may file a formal objection against another gTLD application on string confusion grounds. Such an objection may, if successful, change the configuration of the preliminary contention sets in that the two applied-for gTLD strings will be considered in direct contention with one another (see Module 4, String Contention Procedures). The objection process will not result in removal of an application from a contention set.

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s. Must I be recalling incorrectly?

In message <g339j59ywz.fsf@nsa.vix.com>, Paul Vixie writes:

Adam Atkinson <ghira@mistral.co.uk> writes:

...

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s.

Must I be recalling incorrectly?

no you need not must be. it would work as long as no dk.this or dk.that would be found first in a search list containing 'this' and 'that', where the default search list is normally the parent domain name of your own hostname (so for me on six.vix.com the search list would be vix.com and so as long as dk.vix.com did not exist then http://dk/ would reach "dk.") -- Paul Vixie KI6YSY

DK should NOT be doing this. DK is *not* a hierarchical host name and the address record should not exist, RFC 897. The Internet stopped using simple host names in the early '80s. In addition to that it is a security issue similar to that described in RFC 1535. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <BANLkTinAZvLc4oQEW5Nq8eTrch=x6HsbJg@mail.gmail.com>, Jeremy writes:

"DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" on

"DK." is NOT a hostname (RFC 952). It is NOT legal in a SMTP transaction. It is NOT legal in a HTTP header.

it's own, many (most? all?) DNS clients will attach the search string/domain name of the local system in order to make it a FQDN. The same happens when you try and resolve a non-existent domain. Such as alskdiufwfeiuwdr3948dx.com, in wireshark I see the initial request followed by alskdiufwfeiuwdr3948dx.com.gateway.2wire.net. However if I qualify it with the trailing dot, it stops after the first lookup. DK. is a valid FQDN and should be considered hierarchical due to the dot being the root and anything before that is a branch off of the root. see RFC1034

You need to write 1000 lines of: RFC 1034 DOES NOT CHANGE WHAT IS A LEGAL HOSTNAME Go READ RFC 1034. "DK." it is NOT a valid heirachical hostname. Just because some random piece of software lets you get away with it does not make it a legal nor does it make it a good idea. Mark

-Jeremy

On Sun, Jun 19, 2011 at 7:08 PM, Mark Andrews <marka@isc.org> wrote:

...

In message <g339j59ywz.fsf@nsa.vix.com>, Paul Vixie writes:

...

Adam Atkinson <ghira@mistral.co.uk> writes:

...

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s.

Must I be recalling incorrectly?

no you need not must be. it would work as long as no dk.this or dk.that would be found first in a search list containing 'this' and 'that', where the default search list is normally the parent domain name of your own hostname (so for me on six.vix.com the search list would be vix.com and so as long as dk.vix.com did not exist then http://dk/ would reach "dk.") -- Paul Vixie KI6YSY

DK should NOT be doing this. DK is *not* a hierarchical host name and the address record should not exist, RFC 897. The Internet stopped using simple host names in the early '80s. In addition to that it is a security issue similar to that described in RFC 1535.

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

--bcaec51f900961620b04a619d97b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

"DK" may not be hierarchical, but "DK." is. If you try = to resolve "DK" on it's own, many (most? all?) DNS clients wi= ll attach the search string/domain name of the local system in order to mak= e it a FQDN. The same happens when you try and resolve a non-existent domai= n. Such as <a href=3D"http://alskdiufwfeiuwdr3948dx.com">alskdiufwfeiuwdr39= 48dx.com</a>, in wireshark I see the initial request followed by =A0<meta h= ttp-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><a href= =3D"http://alskdiufwfeiuwdr3948dx.com.gateway.2wire.net">alskdiufwfeiuwdr39= 48dx.com.gateway.2wire.net</a>. However if I qualify it with the trailing d= ot, it stops after the first lookup. DK. is a valid FQDN and should be cons= idered hierarchical due to the dot being the root and anything before that = is a branch off of the root. see RFC1034<div> <br></div><div>-Jeremy<br><br><div class=3D"gmail_quote">On Sun, Jun 19, 20= 11 at 7:08 PM, Mark Andrews <span dir=3D"ltr"><<a href=3D"mailto:marka@i= sc.org">marka@isc.org</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x;"> <div><div></div><div class=3D"h5"><br> In message <<a href=3D"mailto:g339j59ywz.fsf@nsa.vix.com">g339j59ywz.fsf= @nsa.vix.com</a>>, Paul Vixie writes:<br> > Adam Atkinson <<a href=3D"mailto:ghira@mistral.co.uk">ghira@mistral= .co.uk</a>> writes:<br> ><br> > > It was a very long time ago, but I seem to recall being shown <a = href=3D"http://dk" target=3D"_blank">http://dk</a>,<br> > > the home page of Denmark, some time in the mid 90s.<br> > ><br> > > Must I be recalling incorrectly?<br> ><br> > no you need not must be. =A0it would work as long as no dk.this or dk.= that<br> > would be found first in a search list containing 'this' and &#= 39;that', where<br> > the default search list is normally the parent domain name of your own= <br> > hostname (so for me on <a href=3D"http://six.vix.com" target=3D"_blank= ">six.vix.com</a> the search list would be <a href=3D"http://vix.com" targe= t=3D"_blank">vix.com</a> and<br> > so as long as <a href=3D"http://dk.vix.com" target=3D"_blank">dk.vix.c= om</a> did not exist then <a href=3D"http://dk/" target=3D"_blank">http://d= k/</a> would reach "dk.")<br> > --<br> > Paul Vixie<br> > KI6YSY<br> <br> </div></div>DK should NOT be doing this. =A0DK is *not* a hierarchical host= name<br> and the address record should not exist, RFC 897. =A0The Internet<br> stopped using simple host names in the early '80s. =A0In addition to<br=

...

that it is a security issue similar to that described in RFC 1535.<br> <br> Mark<br> <font color=3D"#888888">--<br> Mark Andrews, ISC<br> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2= 9871 4742</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: <a href=3D"mailto:= marka@isc.org">marka@isc.org</a><br> <br> </font></blockquote></div><br></div>

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

On 6/19/2011 9:24 PM, Paul Vixie wrote:

i think we have to just discourage lookups of single-token names, universally.

Not to mention the folks of the Redmond persuasion with their additionally ambiguous \\hostname single names. (In the absence of a configured search domain, Windows won't even try DNS for a single name through it's own resolver libraries; although nslookup will). Jeff

On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:

i think we have to just discourage lookups of single-token names, universally.

How? Regards, -drc

On 06/19/2011 07:08 PM, Paul Vixie wrote:

...

From: David Conrad<drc@virtualized.org> Date: Sun, 19 Jun 2011 16:04:09 -1000

On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:

...

i think we have to just discourage lookups of single-token names, universally.

How?

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? Mike

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 right but they ignore this and press onward until they have market share, then the 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/

On 06/19/2011 22:47, Paul Vixie wrote:

...

Date: Sun, 19 Jun 2011 22:32:59 -0700 From: Doug Barton<dougb@dougbarton.us>

... 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.

let me just say that if i was making millions of dollars a day and i had the choice of reducing that by 1/2000th or not i would not choose to reduce it. as much as i love the free interchange of ideas i will point out that commerce is what's paid the internet's bills all these years.

I wasn't using that as an example of them doing something wrong. I've spoken several places (including here on NANOG) in support of people doing what they need to do to meet their fiduciary responsibility to their stakeholders. My point was simply that there are 2 schools of thought on this issue, and both are so far out on the poles that meaningful changing of minds is next to impossible (and arguably, totally unnecessary). 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/

On 06/19/2011 23:38, Mike Leber wrote:

On 6/19/11 10:47 PM, Paul Vixie wrote:

...

...

Date: Sun, 19 Jun 2011 22:32:59 -0700 From: Doug Barton<dougb@dougbarton.us>

... 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. let me just say that if i was making millions of dollars a day and i had the choice of reducing that by 1/2000th or not i would not choose to reduce it. as much as i love the free interchange of ideas i will point out that commerce is what's paid the internet's bills all these years.

Fortunately, 1/2000th was just the now proven false boogey man that people substituted as a placeholder for the unknown.

Actually the people using that number had hard facts to back it up, but that was all debated at length already, and I don't see any point going over it again.

What if the risk of you not enabling it was that at some later date you lose 1/10th of your revenue due to either competitive pressures or the inability to provide the next generation service customers want? (Or if you are a non profit, what if it meant that you can't service 10 percent of your user base in the way they want.)

We've already been over this too: A) Users don't want "IPvanything," they want "the Internet." B) The date you propose is so far out in the future as to be not worth discussing at this point. My personal take on B is that long before we reach the tipping point you propose that the switch will have been flipped. I think W6D was a good step in the right direction, and I know that serious people are crunching the numbers from it and are overwhelmingly likely to make the right decisions going forward. hth, 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/

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

In message <3DA313A7-911E-4439-9082-B50844338786@dotat.at>, Tony Finch writes:

On 20 Jun 2011, at 08:43, Mark Andrews <marka@isc.org> wrote:

...

=20 There is also no such thing as "in-bailiwick glue for the TLD=E2=80=99s DN= S servers". The root zone contains glue for TLDs. No TLD zone contains glu= e for TLDs.

"In-bailiwick" means that the nameservers for a zone are under the apex of t= hat zone. So the uk TLD servers are in-bailiwick: they are all of the form n= sX.nic.uk for various X. The com TLD servers are not in-bailiwick since they= are all under gtld-servers.net; similarly the .aero servers are under .de, . = ch, .info, .org. If a zone has in-bailiwick nameservers then it must have gl= ue in the parent zone. It is possible for a TLD to have no glue of its own (= like .com) if all of its nameservers are under other TLDs. It is possible fo= r a TLD to have no glue at all if it shares no nameservers with any other TL= D - so .com has glue (shared with .net) but the .aero nameservers are all un= der other TLDs and are different from those TLDs' servers, so it can work wi= thout glue.

Tony.

I will repeat my assertion. There is no such thing as glue records for the nameservers at the top of the zone within the zone itself be they in-baliwick or not. Glue records live in the parent zone and are there to avoid the catch 22 situation of needing the records to find the records. Now glue records which match the address records of the nameservers for the zone may still be needed but they are glue records for a delegated zone, not the zone's apex. One can add obsured address records for the zone's nameservers to the zone but they are not glue records and are not needed for operational purposes and will cause problems if loaded into old nameservers as they will incorrectly be returned as answers. Even some modern nameservers treat them incorrectly by returning them as additional data. All glue records are obsured records. Not all obsured records are glue records be they address records or otherwise. Obsured records can be of any type. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <4DFEAEF6.70407@mtcc.com>, Michael Thomas writes:

Isn't this problem self regulating? If sufficient things break with a single label, people will stop making themselves effectively unreachable, right?

The failure rate isn't going to be high enough for natural selection to take effect. Remember the protocols we use were designed to work back when there was only a single flat namespace. Simple hostnames will appear to work fine for 99.999% of people. It's just when you get namespace collisions that there will be problems. Unfortunately the nincompoops that decide to use tlds this way don't have to pay the costs of cleaning up the mess they cause. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com>, G eorge Bonser writes:

...

The failure rate isn't going to be high enough for natural selection to take effect. Remember the protocols we use were designed to work back when there was only a single flat namespace. Simple hostnames will appear to work fine for 99.999% of people. It's just when you get namespace collisions that there will be problems.

I would guess that most of these are going to be purchased simply to prevent someone else from getting them

I would agree with this part.

and that most of them will never actually be placed into production.

But not with this part.

So it will basically just be a cash cow for ICANN while people pay their $185K/pop "application fee" to snap up a piece of real estate they don't want anyone else to have.

Adding gtlds and opening up the root to brands effectively requires TM holders to register/bid to protect their TM rights. Now $10 or so is not a lot for a TM.gtld and isn't worth the court costs but $185K/pop is a lot and sooner or later a TM holder will sue ICANN because they don't want to have to pay $185K to protect their TM and it will be interesting to see the results. It will be even more interesting if ICANN looses and has to roll back brand delegations it has made. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org>, David Conrad writes:

On Jun 19, 2011, at 5:46 PM, Mark Andrews wrote:

...

...

I would guess that most of these are going to be purchased simply to prevent someone else from getting them I would agree with this part.

I suspect you underestimate the desires and power of marketing folks at = larger organizations.

...

Adding gtlds and opening up the root to brands effectively requires TM holders to register/bid to protect their TM rights. =20

Not really. You might want to search on "trademark" in = http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf. = There has been a tremendous amount of traffic on that particular issue = and that is reflected in the Applicant Guidebook.

...

It will be even more interesting if ICANN looses and has to roll back brand = delegations it has made.

Really, if you're going to opine on the disasters that will befall ICANN = as a result of the new gTLD program, you might want to actually read = what that program does and doesn't do. Really.

Regards, -drc

I'm curious how anyone that has not signed a agreement with ICANN can be bound to anything in any applicant guide book. Also rfp-clean-30may11-en.pdf basically deals with <tm>.<gtld>. on a brief skimming not <tm> or is ICANN going to have a sunrise period for "."? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org>, David Conrad writes:

On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote:

...

I'm curious how anyone that has not signed a agreement with ICANN can be bound to anything in any applicant guide book. =20

In order to obtain a gTLD, you have to sign a contractual agreement with = ICANN.

David, you are missing the point. The TM holder doesn't want the gtld, they just want to protect their trademark. The TM holder doesn't have a contract with ICANN. They do however have a legitimate right to the name and want to spend $0 keeping the name out of anybodys hands but theirs. $187K is not longer a amount to be sneezed at. Mark

...

Also rfp-clean-30may11-en.pdf basically deals with <tm>.<gtld>.

You might want to re-read pretty much any part of that document (e.g., = the title).

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

From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Mon Jun 20 00:15:32 2011 To: David Conrad <drc@virtualized.org> From: Mark Andrews <marka@isc.org> Subject: Re: unqualified domains, was ICANN to allow commercial gTLDs Date: Mon, 20 Jun 2011 15:14:49 +1000 Cc: NANOG list <nanog@nanog.org>

In message <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org>, David Conrad writes:

...

On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote:

...

I'm curious how anyone that has not signed a agreement with ICANN can be bound to anything in any applicant guide book. =20

In order to obtain a gTLD, you have to sign a contractual agreement with = ICANN.

David, you are missing the point. The TM holder doesn't want the gtld, they just want to protect their trademark. The TM holder doesn't have a contract with ICANN. They do however have a legitimate right to the name and want to spend $0 keeping the name out of anybodys hands but theirs. $187K is not longer a amount to be sneezed at.

Mark

...

...

Also rfp-clean-30may11-en.pdf basically deals with <tm>.<gtld>.

You might want to re-read pretty much any part of that document (e.g., = the title).

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

Adding gtlds and opening up the root to brands effectively requires TM holders to register/bid to protect their TM rights.

If you had read the applicant handbook, you would know that's not true. But I'm glad to see that people are taking my advice and continuing the traditional uninformed nanog wankage rather than reading the documentation and polluting the discussion with boring facts. R's, John

On Jun 19, 2011, at 7:22 PM, Michael Thomas wrote:

On 06/19/2011 07:08 PM, Paul Vixie wrote:

...

...

From: David Conrad<drc@virtualized.org> Date: Sun, 19 Jun 2011 16:04:09 -1000

On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:

...

i think we have to just discourage lookups of single-token names, universally.

How?

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?

Mike

I suspect that most of the entities in question will put both in to the DNS and the issues will persist. Owen

On Jun 19, 2011, at 4:08 PM, Paul Vixie wrote:

ICANN could also have an impact on this by having applicants sign something

Well, yes, ICANN could have contracted parties (e.g., the new gTLDs) do this. A bit late to get it into the Applicant's Guidebook, but maybe something could be slipped in after the fact. Who is going to lead the contingent from NANOG to raise this in the GNSO? Of course, changing existing contracts tends to be challenging since the contracted parties have to agree to the changes and I wouldn't be surprised if they demanded ICANN give something up in exchange for agreeing to this new restriction. It'll probably take a while. ICANN can respectfully request ccTLD folks do the same, but whether or not the ccTLDs listen is a separate matter. If the ccTLD folks feel they gain benefit from having naked TLDs, they'll tell ICANN to take a hike. Not sure what will happen with the IDN ccTLDs since they appear to be sort of a combination of ccTLDs and contracted parties. You probably know all this, but things in the ICANN world probably don't work the way most folks think. Regards, -drc

i think he's seen RFC 1034 :-). anyway, i don't see the difference between http://sony/ and http://sony./

Neither do any of the browsers I use, which resolve http://bi/ as well as http://dk./ just fine. Whatever problem unqualified TLD names might present to web browsers has been around for a long time and the world hasn't come to an end. The problems with zillions of single-registrant TLDs are more social and economic than technical. R's, John

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

...

i think he's seen RFC 1034 :-). anyway, i don't see the difference between http://sony/ and http://sony./

Neither do any of the browsers I use, which resolve http://bi/ as well as http://dk./ just fine. Whatever problem unqualified TLD names might present to web browsers has been around for a long time and the world hasn't come to an end.

The problems with zillions of single-registrant TLDs are more social and economic than technical.

And your technical solution to ensure "http://apple/" always resolves to "apple." and doesn't break people using "http://apple/" to reach "http://apple.example.net/" is? Similarly for "mail user@apple". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <alpine.BSF.2.00.1106200055140.23147@joyce.lan>, "John R. Levine" wr ites:

...

And your technical solution to ensure "http://apple/" always resolves to "apple." and doesn't break people using "http://apple/" to reach "http://apple.example.net/" is?

Whatever people have been doing for the past decade to deal with http://dk/ and http://bi/.

As I think I said in fairly easy to understand language, this is not a new problem. I am not thrilled about lots of new TLDs, but it is silly to claim that they present any new technical problems.

There is a big difference between a handful of tld breaking the rules, by making simple hostnames resolve to addresses in the DNS, and thousands of companies wanting the rules re-written because they have purchased "<tm>." and want to be able to use "user@tm" reliably. Simple host names, as global identifiers, where phase out in the 1980's for good reasons. Those reasons are still relevant. Mark

Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies ", Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

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

From: "Tony Finch" <dot@dotat.at>

Trailing dots are not permitted on mail domains.

I couldn't believe that, so I went and checked 5322. Tony's right: there is no way to write an email address which is deterministic, unless mail servers ignore the DNS search path. At least, that's what it sounds like to me.

There has been an ongoing argument about the interaction between unqualified domains and TLDs in mail domains. RFC 2821 said single-label mail domains were syntax errors, but this was probably an editorial mistake and RFC 5321 permits them. It's probably safest to assume that a single-label mail domain is a local unqualified domain which will have its qualifying labels appended by the message submission server, and in other contexts all bets are off.

In fact what matters is what the processing rules and code of mail servers *do* with monocomponent RHSs. Do they try to apply the server's DNS search path to them? Or whatever's in their configs? Or do they just try to look them up in DNS, monocomponent. Cheers, -- jr 'Eric Allman, Wietse Venema, DJB; please pick up the courtesy phone' a -- 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

Adam Atkinson wrote:

...

...

...

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s.

DK should NOT be doing this.

Oh, I'm not claiming it does it now. It certainly doesn't.

I should have checked before I wrote that. The _last_ time I tried it it redirected to something else in Denmark but that was also years ago, just not as many as I think I remember being shown http://dk _Now_ I get rend up at http://www.dk.com/ if I don't put a dot on the end, and https://www.dk-hostmaster.dk/ if I do.

Mark Andrews wrote:

...

_Now_ I get rend up at http://www.dk.com/ if I don't

That's your browser "trying" to be helpful. If it is Firefox this can be turned off with about:config and browser.fixup.alternate.enabled to false. The default is true.

Ah, thanks. I imagined it was FF trying to be helpul but wandering around the settings thingy didn't produce anything that seemed relevant.

Appears to now get you a redirect to https://www.dk-hostmaster.dk/ For those arguing that 512+ octet replies don't occur: baikal:owen (14) ~ % dig @a.nic.dk -t any dk. 2011/06/19 17:03:56 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.0-APPLE-P2 <<>> @a.nic.dk -t any dk. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8417 ;; flags: qr aa rd; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 7 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dk. IN ANY ;; ANSWER SECTION: dk. 86400 IN SOA b.nic.dk. tech.dk-hostmaster.dk. 1308524460 600 300 3024000 3600 dk. 86400 IN A 193.163.102.24 dk. 86400 IN RRSIG A 8 1 86400 20110623053818 20110616000559 42220 dk. vWYPal2lEoKjPUsBLjUibPISlij+zHcqJY7k0WP5C86SgHMERArxLD2r VqJwWlXlhDAmSRitX3aTyyZyI+lL1qSh4u1eNns0/9I/ysV+Hn7NbRgC A0Kwkspgc47MbPPPZOvlL37ZmbEN2jwCLckyESzaPpThF/sI5ZwGKr6N +mI= dk. 86400 IN RRSIG NS 8 1 86400 20110627054850 20110619180550 42220 dk. ckianMaLf8ajkiwk+jaPJyG98Ojv4ScDLB6HORiVXSesJEjLV/W2EF0Q CcOy3KeIws8xPCqKiovIESpwMJlP4Rwk+u9vO546/XdKekU5FdoeWhuw ebLoB29ahKcUvXo9s+uzHmUhbb8jEKDEgxyQIfjSLP+E6Op6+LAwKvOp dYw= dk. 86400 IN RRSIG SOA 8 1 86400 20110626220327 20110619220601 42220 dk. AQFNW7TNXsI4ZOAMzNYYYcDeMBO2mbmdmJt5fzKGrttoZDZmVopN9z7D cA9TIGiLERDxfk/lsuUO+QQAK6V4Gi9fawP/rThqTRv/HbI9+eTBDoTa 3RXEmHmnO+c769Hol7fy7ADkpOtFhb9xl4KLVV8sUDU/rL6wIM73kkl/ sGg= dk. 86400 IN RRSIG TXT 8 1 86400 20110626123535 20110619220601 42220 dk. tmrYWviDeeZmd5Jx1cd79IIjTYQL7do3TOomwqVEkCxwkfSR1H1H5r/x ZigoqqY9DApq3Lyyye95bSDRIaiOjKZksbgpj7Fd4AgxrD5SR1GUZTaz uVP+MAW3x6y0Z02YJmCAt6I0OcdaCAHInQHjnGJCiBSkNickbB1+aRu8 cYM= dk. 86400 IN RRSIG DNSKEY 8 1 86400 20110626014930 20110618154633 26887 dk. G67qd6YFu4ezyVYR5R2Jk7+Rb60bFt7siEaKKs2zZllCx5PFWLZtwrxR 4Rpp+FXtJk759XmaXQf0h33mG1nmJ2ReQNflVDnPddpl5YjbiLt2EHbc OuW3630mbNPVWN7G2HucxNZVzKqpApvfjYfo6cyv2DOk4uXNZCuQlPgM CsCizGgq8qtliY80zYFSsL9UEXlzRgQR7e57v7pOhsaZll0FfdUes2dB nfJtG97cFgOpfdct2YmcRFiowWTu4DMPCPZ5MZEGoqx1pwB0hTJ8KcJX gBhgm0n6riIYxZbbPe449tB+IprAQ+H9pdjOYPOZ74lznZjrcRW0IpnI Kb5DBQ== dk. 3600 IN RRSIG NSEC3PARAM 8 1 3600 20110624180533 20110618010606 42220 dk. bgMTmGKNs9M0VVoFIAiOpaAKvkzdV6PWSoCAf+VgFdOC7nJ3SgZG5nkz dubwoebOada+Si1f6kv/sWRUM9WTTY3gnfNFMdv51KLNOq9km2TLPjqG HKmTPTr5nVFSKLj53S5fmI8zfm9nye8fh7GN2WoxW0pdlrZUItCGjCw9 S8E= dk. 86400 IN NS a.nic.dk. dk. 86400 IN NS b.nic.dk. dk. 86400 IN NS c.nic.dk. dk. 86400 IN NS l.nic.dk. dk. 86400 IN NS p.nic.dk. dk. 86400 IN NS s.nic.dk. dk. 86400 IN TXT "DK zone update" "Epoch 1308524460" "localtime Mon Jun 20 01:01:00 2011" "gmtime Sun Jun 19 23:01:00 2011" dk. 86400 IN DNSKEY 256 3 8 AwEAAcRBGC1Fr12DjYvQQPNnOAzq/oDOibyuF61UzTRnmakZ7rV2xsDb WDl1Jp+Yt/BCqKxZ9M1TkrUFMDWynN7vzqJOKg8WLwIZmB6VvyEQvqv0 qu4B2Ss/ADeoYInVflc/iD6bINriRtWzvefOqrhbctCmQIKqT+BBRu0Q Y4y2twTn dk. 86400 IN DNSKEY 256 3 8 AwEAAd2Ny7OFu4XZ9M3NQQDMxdZwIq8WGfz5n0uAbAw8npuPsmHPtp0N xYpwIg1dUJSnf19RhlWUeu1M32w65oRW0pRxRvk8zdihEewW3wywEjRA 9Zp0eDT0X+xUPL3+xE4wWNl3qBZm1JW0hSqS9TAR05XbO5aQ9/W9o4h+ NJ4Q6Rsf dk. 86400 IN DNSKEY 257 3 8 AwEAAcX56/UAMzmxalCMl5KWD5ViYJIRhWI8upQy/KI7HL8rCkltQOY+ MGkdNIndl1m0IrqJ58pbFn3X6CSfXsbas0G0Pg5NyApomTtalw3E4CQH LeXc6aZF97PcE4w1tjucZAtgGmvPEJLPnkQJOrUoqklAUaKUyT4HXyr8 zPwsuT+S0sSJmpTrtQVbZwY0TXr7CrYRtpg/aFjNzRRSQC8RljQjRZi2 KammIx7PocVx8VXy6pzKEWDP4yOCmcJkh0oa3fP0QCIpSlrlPArKbLsA UN62ARflz04TrA0zskvRo4ah+C9Di9Il6KgkdAcUgdNX1FAvoo80GTqb 6rpZFsx7tn0= dk. 3600 IN NSEC3PARAM 1 0 17 96AB3C09C88F066B ;; ADDITIONAL SECTION: b.nic.dk. 86400 IN A 193.163.102.222 c.nic.dk. 86400 IN A 208.76.168.244 l.nic.dk. 86400 IN A 192.38.7.242 p.nic.dk. 86400 IN A 204.61.216.36 s.nic.dk. 86400 IN A 77.72.229.252 b.nic.dk. 86400 IN AAAA 2a01:630:0:80::53 s.nic.dk. 86400 IN AAAA 2a01:3f0:0:303::53 ;; Query time: 554 msec ;; SERVER: 212.88.78.122#53(212.88.78.122) ;; WHEN: Sun Jun 19 17:04:20 2011 ;; MSG SIZE rcvd: 2137 So... dk. does have an A record (in violation of said 3-digit RFC) and it points to 193.163.102.24... And that host responds with a redirect: baikal:owen (15) ~ % telnet 193.163.102.24 80 2011/06/19 17:04:20 Trying 193.163.102.24... Connected to www2.dk-hostmaster.dk. Escape character is '^]'. GET / HTTP/1.0 Host: dk HTTP/1.1 301 Moved Permanently Date: Mon, 20 Jun 2011 00:05:38 GMT Server: Apache Location: https://www.dk-hostmaster.dk/ Vary: Accept-Encoding Content-Length: 237 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.dk-hostmaster.dk/">here</a>.</p> </body></html> Connection closed by foreign host. On Jun 19, 2011, at 12:03 PM, Adam Atkinson wrote:

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s.

Must I be recalling incorrectly?

In message <D066E1C4-CC70-4105-B2ED-A2AF9B1B2A50@delong.com>, Owen DeLong write s:

Appears to now get you a redirect to https://www.dk-hostmaster.dk/

For those arguing that 512+ octet replies don't occur:

I don't think anyone argues that 512+ octet replies don't occur. They have occured for as long as the DNS has existed. Even RFC 1123 said you SHOULD handle them. Unfortunately there are SOHO router vendors (yes I'm talking about you Netgear) that have shipped products that don't even listen on DNS/TCP yet advertise themselves as recursive DNS servers and don't have fixed images that can be installed (yes the box is field upgradable and yes I have looked for updated images). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Florian Weimer wrote:

...

It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s.

Must I be recalling incorrectly?

It must have been before 1996. Windows environments cannot resolve A/AAAA records for single-label domain names.

This would have been May 1995 at the latest. And I don't recall the OS being used at the time. Some flavour of Unix, Windows or MacOS (or "System 7" or whatever it was called at the time) or possibly even an Amiga.

In a message written on Fri, Jun 17, 2011 at 08:25:28PM -0500, Jimmy Hess wrote:

Perhaps we could get an update to the relevant RFCs.. clarifying that only NS records may be dotless in the root namespace?

As in -- No hostnames A, MX, or CNAME at the TLD level.

I suspect some are already eyeing competitive advantage here. After all, if the root can return your A (MX, CNAME, TXT, RP, whatever) you are guaranteed one DNS query to resolve your name, one RTT to a DNS server, etc. Given the roots are well distributed, with several massively anycasted..... Shaving a DNS lookup or two every now and then is key to some peoples business models. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

---- Original Message -----

From: "Zaid Ali" <zaid@zaidali.com>

Just an example, it has hit main stream media http://globalpublicsquare.blogs.cnn.com/2011/03/17/who-runs-the-internet/

The issue we're presently discussing *is not mentioned in that article*.

Or you could have gone to one of the many free iCANN meetings where you can hear about this till your ears go blue. It has only been a topic for discussion for about 10 years :) but of course if it's not on NANOG it can't be true.

Course not. :-) Notwithstanding that, globally resolvable valid DNS names *with no dots in them* are going to break a fair amount of software which assumes that's an invalid case, and that is in fact a *different* situation, not triggered by the expansion of the *generic* gTLD space. So, like DRC, your response isn't to my actual point. :-) 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

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

From: "John Levine" <johnl@iecc.com>

I happen to agree that adding vast numbers of new TLDs is a terrible idea more for administrative and social than technical reasons, but this is the first you've heard about it, you really haven't been paying attention.

John, yes, I've been paying attention to the TLD space since Chris Ambler *first* put in his .web proposal -- what is that; 15 years now? 20? This is the first I've heard of *the possibility of TLD registrars being end-user internal/exclusive*. People have made jokes about company TLDs in the past, sure, but no, I never heard any specific discussion about it actually happening; I invite citations. 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

On Jun 17, 2011, at 5:33 PM, Jay Ashworth wrote:

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

...

From: "John Levine" <johnl@iecc.com>

...

I happen to agree that adding vast numbers of new TLDs is a terrible idea more for administrative and social than technical reasons, but this is the first you've heard about it, you really haven't been paying attention.

John, yes, I've been paying attention to the TLD space since Chris Ambler *first* put in his .web proposal -- what is that; 15 years now? 20?

This is the first I've heard of *the possibility of TLD registrars being end-user internal/exclusive*.

People have made jokes about company TLDs in the past, sure, but no, I never heard any specific discussion about it actually happening; I invite citations.

http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm

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

On Jun 17, 2011, at 2:54 PM, Benson Schliesser wrote:

On Jun 17, 2011, at 4:21 PM, David Conrad wrote:

...

On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote:

...

Aw, Jeezus.

No. Just, no.

http://tech.slashdot.org/story/11/06/17/202245/

You just learned about this now?

On a related topic, the US DoJ recently wrote a letter suggesting that DNS registry/registrar vertical integration might not be a good idea (from an anti-trust perspective).

http://www.icann.org/en/correspondence/strickling-to-dengate-thrush-16jun11-...

Cheers, -Benson

And before that, a need for a comprehensive economic study http://forum.icann.org/lists/5gtld-guide/msg00013.html See a pattern? Zaid

Two additional sticks for the fire: I haven't got around to reading the Jun 14 NTIA FNOI<http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf> but in his talk at INET NY <http://bit.ly/inetnyarchive> the same day Larry Strickling talked about a major review of the IANA functions contract, saying Based on the input of the global Internet community, we are proposing the

following changes in the IANA functions contract. First, we propose a functional separation between DNS policy making wherever it occurs at ICANN or elsewhere in the actual execution of tasks associated with the IANA functions.

Second, we propose enhanced transparency and accountability through the development of documentation processes as well as performance standards and metrics to establish service levels.

Third, we propose that the contractor needs to include documentation that demonstrates how proposed new top level domain strings have received consensus support from relevant stakeholders and are supported by the global public interest.

also, in the "whereas' section of the ICANN motion to approve the new gTLD program <http://isoc-ny.org/icann41/06-20_singapore_gtld_vote.txt> - there is language that would indicate that the Vertical Integration issue is far from settled. WHEREAS ICANN RECEIVED LETTERS FROM THE UNITED STATES DEPARTMENT OF

COMMERCE AND THE EUROPEAN COMMISSION ADDRESSING THE ISSUE OF REGISTRY/REGISTRAR CROSS OWNERSHIP, AND THE BOARD CONSIDERED THE CONCERNS EXPRESSED THEREIN. THE BOARD AGREES THAT THE POTENTIAL ABUSE OF SIGNIFICANT MARKET POWER IS A SERIOUS CONCERN, AND DISCUSSIONS WITH COMPETITION AUTHORITIES WILL CONTINUE.

j -- --------------------------------------------------------------- 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 -------------------------------------------------------------- -

On Sat, Jun 18, 2011 at 12:04 AM, George B. <georgeb@gmail.com> wrote:

I think I will get .payme  and make sure coke.payme, pepsi.payme, comcast.payme, etc. all get registered at the low-low price of $10/year.  All I would need is 100,000 registrations to provide me with a million dollar a year income stream for the rest of my life.

I have read this thread, but certainly not any ICANN garbage. It seems to me that a TLD for a brand, like Coca-Cola, would not be used in the same way as GTLDs. Will George actually be allowed to carve up his own TLD and sell bits of it to anyone who is willing to click a checkbox on GoDaddy.com? Obviously there is not any technical limitation in place to prevent this, but will there be legal / "layer 9" limitations? I kinda figured additional GTLDs is not very useful given that probably every domain registrar drives customers to "protect their brand," avoid phishing attacks against their customers, etc. by buying not only example.com, but also net|org|biz|etc. I imagine that registrars may be really excited about this idea, because it represents additional fees/revenue to them. I can't understand why it is good for anyone else. Does McDonald's really want to print http://mcdonalds/ or www.mcdonalds instead of www.mcdonalds.com on their soft drink cups and TV ads? Is Owen so disconnected from reality that he thinks the chain with the golden arches is spelled "MacDonald's?" I don't particularly care about the intellectual property questions (in the context of NANOG) but if you really want to bang your head against that, I suggest reading about the current trademark status of "Standard Oil." In short, it remains a legally protected mark but has several distinct owners throughout the United States -- a result of the break-up. "Waffle House" is a little complex, too. Somehow the GTLD system continues to function. I imagine the relevant authorities are capable of figuring out who should be allowed to register which brand-TLD. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator  /  Innovative Network Concepts

With a $185,000 application fee this tends to really kill small businesses and conditions the public to favor ecommerce with the giants, not to mention a nice revenue boost for ICANN.

Would love to hear the dirt on backroom conversations that led to this decision...

Hopefully there will be enough public outcry to reverse it... but I'm not optimistic.

Looking at the array of other fees: Registry Services Review Fee - $50,000 Dispute Resolution Filing Fee - $1000 - $5000 per party per filing Community Priority Evaluation Fee - $10,000 It looks like this is a great opportunity for ICANN to staff up and boost salaries all around! I wish there were some other aspect of real estate where I could do something like this. Maybe my town could make a killing by deciding to name streets after famous brands for a low-low fee of only $185,000 plus annual fees ... per street. Maybe McDonalds and Burger King would bid up the price of the name of the main drag where they both have an outlet. Or maybe Sears would fight with Penney's over the name of the entrance road to the mall. Hmmm. The internet is pretty cool because "vital real estate" can be created out of thin air and it can apparently cost a fortune.

Well I just asked the question during the "Getting Ready" panel at the ICANN 41 meeting. Q: How much on top of the $185K is required for a new gTLD Answers: It is hard to say, too many variables, biz plan dependencies, if the string will be contended it can go to a more complex/costly process, but the estimate just for the application could be 2X or 3X the application fee. Another panelist also made reference at the biz plan but stated that you may need to have available 3X the figure of your annual operating budget. Cheers Jorge