Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
[ back on list ] On Mon, Jun 30, 2008 at 05:34:53PM -0400, Jerry B. Altzman wrote: There was a HUGE one about that domain name between Nissan Motors and some computer consultant named Nissan (a Hebrew name) in NC. vis http://www.nissan.com/Lawsuit/The_Story.php I don't know exactly how to quote the ruling and decision. Nissan Motor Co. Ltd v. Nissan Computer Corp Yeah, I vaguely remembered it after you mentioned it. A quick look at the website would imply that he won, which rather makes my point, no? :-) The September ruling speaks directly to my assertion that the mere existence of a mark in a domain name doesn't constitute infringement. The methods by which you can infringe a trademark are pretty bright-line... Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
Re: ICANN opens up Pandora's Box of new TLDs
On Tue, 1 Jul 2008, Stephane Bortzmeyer wrote: On Mon, Jun 30, 2008 at 06:36:06PM +0100, Tony Finch [EMAIL PROTECTED] wrote a message of 15 lines which said: It makes the public suffix list project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/ Well, this list is a bad workaround for cookies specification problems and bad programming practices, so I'm not too concerned if it is perturbed. I don't think bad programming can be blamed in this instance, and cookies are so widely used and so fundamentally broken that a workaround is the best way to improve their security. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER GERMAN BIGHT: SOUTH BACKING SOUTHEAST 4 OR 5, OCCASIONALLY 6 LATER IN FISHER. SLIGHT OR MODERATE. FAIR. GOOD.
Re: ICANN opens up Pandora's Box of new TLDs
Phil Regnauld (regnauld) writes:
John Levine (johnl) writes:
d) 280
# dig @f.root-servers.net axfr . | egrep 'IN[[:space:]]NS' | awk '{ print $1
}' | sort -u |wc -l
281
Interesting extract from a transcript of tICANN board meeting in Paris.
It doesn't say much about what was originally envisioned,
but sheds light on the considerations that were made.
http://isoc-ny.org/wiki/ICANN_-_Paris/Board_meeting
[It's in the first statement from Dave Wodelet:]
I just think it's important for the public record to make some
comments about adding new gTLDs to the root. While conceptually I
agree and see the benefit to the community with adding more TLDs
to the root, there are still some concerns about how scalable in
the long term this will be.
How many can we truly support? Well, from the best guess we have,
and I do stress the word guess, somewhere around 5,000 or so TLDs
seem to be realistic.
But how high can we actually go? We really don't know. There are
both technical and administrative issue limits to the scaling. And
it looks like the administrative issues may be more limiting than
the technical ones.
Certainly, what we do now administratively will certainly need to
change to support even the 5,000 or so that I mentioned earlier.
So how many will we have to support? Well, if we just look at the
number of place names, there seems to be somewhere between 5 and 6
million place names in the world. And if every one of these wanted
a TLD, that might not be possible.
And the 5 to 6 million place names doesn't include the number of
commercial TLDs businesses may want, and this 5 to 6 million doesn't
include the vanity names people may want as well, nor does this 5
to 6 million include what we may need in the future for names of
planets, planetary colonies, which may, indeed, happen within the
life of our Internet.
So I am a bit concerned about spending our TLD name inheritance for
future generations of Internet users. As we know, everything has
limits, like IPv4. We all know that has a limit, and that's why
we're looking at IPv6.
Re: ICANN opens up Pandora's Box of new TLDs
On Mon, 30 Jun 2008, Jay R. Ashworth wrote: On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote: Trailing dots in email addresses are a syntax error. In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header. Postfix corrects many syntax errors rather than rejecting erroneous messages. Tony: what authority were you depending on for your assertion, and in which context do you make it? It has been true of all internet email addresses since before dots were introduced into host names. RFC 2821 section 4.1.2 Command Argument Syntax Domain = (sub-domain 1*(. sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / - ) Let-dig Note that this does not permit a trailing dot. (It also doesn't permit single-component domains, but that's due to an editorial mistake.) Section 4.1.2 of RFC 821 also does not permit trailing dots. RFC 2822 section 3.4.1 Addr-spec specification domain = dot-atom / domain-literal / obs-domain dot-atom= [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *(. 1*atext) This also does not permit trailing dots. RFC 822 section 6 is similar. See also RFC 733, which allows no dots at all. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER WIGHT: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6 IN HUMBER, BECOMING VARIABLE 3 OR 4. SLIGHT OR MODERATE. THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: ICANN opens up Pandora's Box of new TLDs
On Sun, Jun 29, 2008 at 02:45:55PM -0700,
Roger Marquis [EMAIL PROTECTED] wrote
a message of 31 lines which said:
The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}'
If this is a regexp for the current root zone, it is
wrong... (.museum and the test IDNs, whose punycode encoding
contains digits and hyphens.)
Aside from the IP issues it effectively precludes anyone from
defining a hostname that cannot also be someone else's domain
name.
Interesting requirment but one which was never written down, I'm
afraid. You certainly cannot expect ICANN to comply with every
requirment that someone at Nanog may imagine every day.
Will you still think that when someone buys the right to the .nic
tld and starts harvesting your queries and query related traffic?
Be my guest. The DNS is a tree and the existence of nic.de or nic.com
was never a problem. Why should .nic be different?
Re: ICANN opens up Pandora's Box of new TLDs
Terribly stupid question, but one aproppos to this thread. If my company pays for and registers a new TLD, let's call it smtp for grins, and I create an A record for smtp. in my top level zone file, how will users outside my company resolve and reach that address? If they simply use smtp as the hostname, most of the current resolver libraries will append the local domain name, so that instead of reaching my A record for smtp, they'll end up trying to reach smtp.their.domain. Will operating system manufacturers release updated resolver libraries that no longer assume that single token names should have the local domain attached? Or should I always ensure that resolvers reach my domain explicitly by including the trailing dot in all uses, so that my email would be given out as [EMAIL PROTECTED] in the hopes that everyone would correctly remember to add the . at the end when entering my email address into their mail clients? In the past, this wasn't really a concern, as you never had a case of a single entity owning an entire TLD, and as such you'd never see A or MX records showing up for an entire TLD. But now, with private ownership of TLDs possible, that could very well be the case in the future. Google could register .gmail, and decide that they want to have the shortest, easiest to remember addresses, so people can just be [EMAIL PROTECTED] (well, until MSN gets in the business, and decides that their users should have even shorter addresses, and register .msn so that their users can be [EMAIL PROTECTED]. ^_^; ) Or does the current resolver logic already handle these cases (check root, work your way down stopping at the first match found; if you run out of tokens in the string being resolved, append the local domain name to the string and start the process over)? Simply looking to solidify my understanding of how these new names would resolve. Thanks! Matt
Re: ICANN opens up Pandora's Box of new TLDs
Matthew Petach (mpetach) writes: If they simply use smtp as the hostname, most of the current resolver libraries will append the local domain name, so that instead of reaching my A record for smtp, they'll end up trying to reach smtp.their.domain. Actually, that's a good point -- although it will try first with the domains specified in the search list first. So I wouldn't worry too much about this kind of thing. But considering the amount of flag waving and Caution: Wet Floor signs ICANN placed when it rolled out something has harmless as the IDN tests in the root, I'm surprised that they haven't thought about all the non-FQDNs that will suddenly resolve, including all the private TLDs that people use internally. It's bad practice, and isn't recommended anyway, but I do expect it will cause many more fun (read: annoying) calls to helpdesks of the sort where did my mail go ?. And mail won't be the only thing. Will operating system manufacturers release updated resolver libraries that no longer assume that single token names should have the local domain attached? I know a lot of mail clients that won't accept to send mail to [EMAIL PROTECTED], but they certainly will accept [EMAIL PROTECTED] as the outgoing mail name. Luckily, that will match the search list as well first. Or should I always ensure that resolvers reach my domain explicitly by including the trailing dot in all uses, so that my email would be given out as [EMAIL PROTECTED] in the hopes that everyone would correctly remember to add the . at the end when entering my email address into their mail clients? A fair number will barf on this (for now). Or does the current resolver logic already handle these cases (check root, work your way down stopping at the first match found; if you run out of tokens in the string being resolved, append the local domain name to the string and start the process over)? The other way around. And if I ping 'dk', my resolver stops after catpipe.net and my other private domain. It doesn't try dk., even though dk. has an A record associated with it. I get NXDOMAIN. Simply looking to solidify my understanding of how these new names would resolve. Not too many problems, I think, except for resolver libraries that fail to find the name in the domains listed in the search list, and continue to '.'. It's not standard practice though. Phil
Re: ICANN opens up Pandora's Box of new TLDs
John Levine (johnl) writes:
d) 280
# dig @f.root-servers.net axfr . | egrep 'IN[[:space:]]NS' | awk '{ print $1 }'
| sort -u |wc -l
281
(with . itself)
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote: If my company pays for and registers a new TLD, let's call it smtp for grins, and I create an A record for smtp. in my top level zone file, how will users outside my company resolve and reach that address? I suspect the assumption is that no one will actually do this since it would have operational issues (as you note) and it would be challenging to recover costs in the traditional manner (i.e., selling names under the TLD). If someone were to try, perhaps it would demonstrate the quote stupidity, like virtue, is its own reward? Regards, -drc
Re: ICANN opens up Pandora's Box of new TLDs
It seems to me that there are technical reasons to try and block .local, and maybe some other potential TLDs, but that for .exe, .smtp, and other choices that confuse current browser implementations, a warning note is about all the registrant can expect. Of course, it would not surprise me if people are right now going through web logs and search logs and saying, hmm, .smtp and .exe occur so often, they would make GREAT TLDs. Regards Marshall On Jun 30, 2008, at 8:28 AM, David Conrad wrote: On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote: If my company pays for and registers a new TLD, let's call it smtp for grins, and I create an A record for smtp. in my top level zone file, how will users outside my company resolve and reach that address? I suspect the assumption is that no one will actually do this since it would have operational issues (as you note) and it would be challenging to recover costs in the traditional manner (i.e., selling names under the TLD). If someone were to try, perhaps it would demonstrate the quote stupidity, like virtue, is its own reward? Regards, -drc
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 30, 2008, at 1:53 AM, Phil Regnauld wrote: But considering the amount of flag waving and Caution: Wet Floor signs ICANN placed when it rolled out something has harmless as the IDN tests in the root, I'm surprised that they haven't thought about all the non-FQDNs that will suddenly resolve, including all the private TLDs that people use internally. 1) The new gTLD stuff hasn't gotten as far as the point where the testing of IDN stuff started. 2) ICANN (or rather, the technical side of ICANN staff) has thought about this and there is a 'technical evaluation' phase of the application evaluation 3) We've already run into the 'private TLD' thing: lots of global companies (apparently) have internal domains organized on regional/ continental boundaries. When '.asia' was put into the root, the Internet did not break. The other way around. And if I ping 'dk', my resolver stops after catpipe.net and my other private domain. It doesn't try dk., even though dk. has an A record associated with it. I get NXDOMAIN. Your resolver appears to be broken. Works for me: % dig +short dk 193.163.102.23 % traceroute dk. traceroute to dk (193.163.102.23), 64 hops max, 40 byte packets 1 10.0.1.1 (10.0.1.1) 4.484 ms 3.933 ms 1.163 ms 2 * * * 3 * ge-2-14-ur01.santaclara.ca.sfba.comcast.net (68.86.248.65) 13.600 ms 10.250 ms ... 20 netgroup.r2.dk-hostmaster.dk (217.116.254.58) 204.900 ms 200.835 ms 199.208 ms ^C (doesn't appear to answer to pings) Regards, -drc
Re: ICANN opens up Pandora's Box of new TLDs
David Conrad (drc) writes: 1) The new gTLD stuff hasn't gotten as far as the point where the testing of IDN stuff started. Mhh, ok :) 2) ICANN (or rather, the technical side of ICANN staff) has thought about this and there is a 'technical evaluation' phase of the application evaluation Fair enough. 3) We've already run into the 'private TLD' thing: lots of global companies (apparently) have internal domains organized on regional/continental boundaries. When '.asia' was put into the root, the Internet did not break. The other way around. And if I ping 'dk', my resolver stops after catpipe.net and my other private domain. It doesn't try dk., even though dk. has an A record associated with it. I get NXDOMAIN. Your resolver appears to be broken. Works for me: dig doesn't use the resolver the same way other applications do. Try ping dk vs ping dk., or telnet dk vs. telnet dk. Of course, depends on the OS -- but at least on a few BSDs (OS X, FreeBSD), Linuxes (Debian, Ubuntu), it behaves the same way.
Re: ICANN opens up Pandora's Box of new TLDs
In article [EMAIL PROTECTED] you write: Terribly stupid question, but one aproppos to this thread. If my company pays for and registers a new TLD, let's call it smtp for grins, and I create an A record for smtp. in my top level zone file, how will users outside my company resolve and reach that address? In the usual way. Try typing this into your browser's address bar: http://museum/ R's, John
Re: ICANN opens up Pandora's Box of new TLDs
Matthew Petach (mpetach) writes: That was amusing. Firefox very handily took me to a search results page listing results for the word museum, none of which was the actual page in question. ... and Safari took me to www.museum.com. Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^; This is not only about client resolvers, it's equally about the individual applications and their choice of how to handle a single-label domain name, or just domain names (FQDN or not) in particular. Most often you'll see that the regular expressions used to parse what is considered to be a valid domain -- or even the policy that decides whether a given name has a special meaning or not -- will vary wildly. Most of them are wrong, or don't do the expected thing.
Re: ICANN opens up Pandora's Box of new TLDs
In the usual way. Try typing this into your browser's address bar: http://museum/ That was amusing. Firefox very handily took me to a search results page listing results for the word museum, none of which was the actual page in question. Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library. Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^; Too bad. You might try writing the guy whose address is [EMAIL PROTECTED] (yes, his name is Ian) and see what his experience has been. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly.
Re: ICANN opens up Pandora's Box of new TLDs
On Monday 30 June 2008 17:24:45 John Levine wrote: In the usual way. Try typing this into your browser's address bar: http://museum/ That was amusing. Firefox very handily took me to a search results page listing results for the word museum, none of which was the actual page in question. Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library. I think that the following hold ... but I have a headache Since the hostname part of the URI does not contain a dot, RFC1034 section 3.1 applies (according to RFC 2396), the name is treated as relative initially, and the interpretation varies from implementation to implementation. In particular if a museum name exists in your current domain, and/or other searches that may be applied to the lookup that may be correctly returned first. The language implies that . need not be part of the search, so the URL need not work and the implementation could still be RFC conforming. Certainly there is scope for confusion here. My machines resolver is configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm sure the folks who wrote the resolver code considered the default carefully. Clearly an area ICANN need to ponder, if they haven't already, as changing the resolver defaults globally might undermine the stability of the root name servers. And introducing new domains will encourage vendors to change their resolvers default behaviour (even for areas where it is already technically RFC conforming, if not least surprise conforming). Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^; Too bad. You might try writing the guy whose address is [EMAIL PROTECTED] (yes, his name is Ian) and see what his experience has been. Now that is an email address not a URI, so section 5 of RFC 2821 applies, and treating the domain as relative is discouraged. So I'd expect his email address to work (with a few exceptions - just like addresses with apostrophes - some folks will have bad implementations). IE gets to the correct page here. Firefox on Windows did something else again - sigh (I'm sure it is can be corrected in the browser configuration somewhere). There is a squid proxy behind both of them. On the other hand if people need short domain names, my employers may have a couple to sell of the old fashioned variety the same total length as museum but without the added complications, and the ICANN fee is a lot less ;)
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 30, 2008, at 12:54 PM, [EMAIL PROTECTED] wrote: On Sun, 29 Jun 2008 17:55:53 EDT, Tuc at T-B-O-H.NET said: 220 Sending HELO/EHLO constitutes acceptance of this agreement Even in a UCITA state that has onerous rules regarding shrink- wrapped EULA terms, I think you'd have a very hard time getting a court to enforce an alleged contract based on this. And it's different from the usual suggestion to put all activity may be monitored in your telnet/ssh login banners, because there's an expectation that the human will look at a login banner when they login, but there's no expectation that an SMTP server will look at the 220 banner any further than checking the first digit is a '2' (go read the section on SMTP reply codes in RFC2821). Feel free to cite any relevant case law (in fact, even the case law on login banners read by humans is a tad skimpy - in most cases, it does nothing for intruders, but it protects you from your own users complaining their privacy was violated)... I have found the biggest advantage of banners to be the fact that you learn to recognize your own devices *before* typing your password... It you *always* have a banner on *all* of your devices, you quickly learn to expect them... For example: ssh router1.example.net ** * This device belongs to example.net. Don't login if you * are not supposed to be here... Blah blah blah. * * [EMAIL PROTECTED]'s password: versus: ssh router1.exsmple.net [EMAIL PROTECTED]'s password: Having a cute, customized banner (not the default from the standard security templates) helps with this... W -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen
Re: ICANN opens up Pandora's Box of new TLDs
Tony Finch wrote: On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote: I am very curious of what tests a security-aware programmer can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs. It makes the public suffix list project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/ Tony. Assuming O(1k) applications, and the numbers ICANN staff were using in February were 300 to 600, with the determining factors (a) existence of subsequent rounds and their temporal offsets, (b) actual application fee, originally guesstimated in the USD 100k range, now twice that, a sort of self-imposed auction based on pain, or rumor mill run amok, depending on one point of view, and (c) the number of sunspots in the quarter that ICANN actually accepts applications; and application survival rates of 10% to 50% in the evaluation processes; then the root string insertion frequency may be as bounded above by 24 hours on average and below by 168 hours on average. It will be different. I pointed this out in the Registrar Constituency meeting in Paris Tuesday last, that our assumptions about the size of the registrars was already off by more than an order of magnitude, and our assumption about the size of the registries was about to fail as well, and that there were some additional non-scaling reasons to revisit the EPP design. Eric
Re: ICANN opens up Pandora's Box of new TLDs
On Mon, Jun 30, 2008 at 09:05:41AM -0700, Matthew Petach wrote: In the usual way. Try typing this into your browser's address bar: http://museum/ That was amusing. Firefox very handily took me to a search results page listing results for the word museum, none of which was the actual page in question. In order to reach that page, in Firefox 1.5.0.12, I had to actually enter http://museum./ and add the trailing dot to force the browser to *not* treat it as a stub token. FWIW, FF3.0/Win dealt with that properly for me. It also deals properly, on the same machine, with several internal webservers, which I also hit with one-word names, but which actually resolve, of course, by the search list on the machine. So FF3, at least, will try to resolve oneword as oneword., before moving along. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+-+RFC 2100 Ashworth Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ICANN opens up Pandora's Box of new TLDs
On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote: On Mon, 30 Jun 2008, Matthew Petach wrote: Or should I always ensure that resolvers reach my domain explicitly by including the trailing dot in all uses, so that my email would be given out as [EMAIL PROTECTED] in the hopes that everyone would correctly remember to add the . at the end when entering my email address into their mail clients? Trailing dots in email addresses are a syntax error. RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14. STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a standard for domain name literals which appears to expand to a pattern which does not in fact permit a trailing dot. In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header. Tony: what authority were you depending on for your assertion, and in which context do you make it? Cheers, -- jr 'comp.mail.headers lives!' -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
Re: ICANN opens up Pandora's Box of new TLDs
On Mon, Jun 30, 2008 at 4:45 PM, Jay R. Ashworth [EMAIL PROTECTED] wrote: RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14. STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a standard for domain name literals which appears to expand to a pattern which does not in fact permit a trailing dot. In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header. Tony: what authority were you depending on for your assertion, and in which context do you make it? This whole set of arguements is one of the points Bill Manning was bringing up, yes? Clients and OS's and other things make oddball assumptions (museum really is www.museum.com for some versions of FF or IE or ) Without adequate time to fix this in code (properly fix this) support calls and mis-direction are going to be an issue :( Now, lump on IDN foo!!! wee! How fast will IEX be out of normal use? FFY? who runs a largish traffic magnet and can tell when the last Windows 98 IE4 client hit them? Matt Petach, let's nominate him for that stat update :) -Chris
Re: ICANN opens up Pandora's Box of new TLDs
On Mon, Jun 30, 2008 at 8:34 PM, Jean-François Mezei [EMAIL PROTECTED] wrote: With all the phishing shananigans, you'd think the folks outside of microsoft who would strive to avoid features that could bring you to unwanted destinations and they should just stick to feeding your host name string to the resolver and letting resolver decide how to manipulate that string to resolve it. You sure would... hurrah for paxfire/barefruit/... :( enabling phishing one typo at a time. -Chris
Re: ICANN opens up Pandora's Box of new TLDs
Scott Weeks wrote: How'd you do that? I use FF on FreeBSD, but parhaps there're similar settings. Since a few people asked. in the url line: about:config This is the magic incantation that gets you a page with just about all configuration settings. you can serach for a particular setting in the filter. To disable the google searching, look for the string keyword. set keyword.enabled to false. You can alco zap the value of keyword.URL To get a button to easily enable and disable javascript: http://prefbar.mozdev.org/ This allows you to put up a whole series of buttons such as java, images, javascript, kill cache, and a UA selection box to fake other browsers and much more. Another extension is the Web Develoer extension: http://chrispederick.com/work/web-developer/ It gives you plenty of options, including disabling CSS, viewing source etc etc. Good support available in the mozilla.support.* newsgroups (such as mozilla.support.firefox). If you are on an ISP that have cut down NNTP, it is available on the NNTP server: news.mozilla.org
Re: ICANN opens up Pandora's Box of new TLDs
On Tue, 01 Jul 2008 00:02:33 -0400 Jean-François Mezei [EMAIL PROTECTED] wrote: To get a button to easily enable and disable javascript: http://prefbar.mozdev.org/ While I do use prefbar, for dealing with Javascript I much prefer NoScript, since that gives me per-site control. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: ICANN opens up Pandora's Box of new TLDs
On Thu, Jun 26, 2008 at 11:53:06PM +0200, Jeroen Massar [EMAIL PROTECTED] wrote a message of 49 lines which said: not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? This requires serious elaboration. How could you use a domain in .exe to actually attack someone? (No handwaving, please, actual study.) Thank you people doing all the ICANN politics for destroying the Internet. The Internet, until now, resisted to forces much more powerful than ICANN.
Re: ICANN opens up Pandora's Box of new TLDs
On Thu, Jun 26, 2008 at 10:37:34PM -0500, Frank Bulk - iNAME [EMAIL PROTECTED] wrote a message of 37 lines which said: ...which is why it might be a strategy to blacklist all new TLDs (if this proposal gets through) and whitelist just .com, .net, etc. Interesting. I do not know if this strategy will be implemented or not but, if it is, it will be a big change in Internet governance. No longer will the TLDs in the root be decided by ICANN or by its master, the US government, but they will have to be vetted by an informal group of network operators. A boycott by this group could have devastating effects for a business. We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) It will be an interesting turn back to the european cities of the Middle Age, with guilds approving (or, more often, disapproving) every technical or business novelty...
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 29, 2008, at 5:45 AM, Stephane Bortzmeyer wrote: On Thu, Jun 26, 2008 at 11:53:06PM +0200, Jeroen Massar [EMAIL PROTECTED] wrote a message of 49 lines which said: not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? This requires serious elaboration. How could you use a domain in .exe to actually attack someone? (No handwaving, please, actual study.) I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ? Regards Marshall Thank you people doing all the ICANN politics for destroying the Internet. The Internet, until now, resisted to forces much more powerful than ICANN.
Re: ICANN opens up Pandora's Box of new TLDs
This requires serious elaboration. How could you use a domain in .exe to actually attack someone? (No handwaving, please, actual study.) I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ? I think this would be one of the TLDs that they'd refuse. Then again, there are DOS commands that do end in .com (CHOICE, COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : http://support.microsoft.com/kb/72188 Tuc/TBOH
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 01:32:05PM -0700,
Roger Marquis [EMAIL PROTECTED] wrote
a message of 22 lines which said:
Security-aware programmers will now be unable to apply even cursory
tests for domain name validity.
I am very curious of what tests a security-aware programmer can do,
based on the domain name, which will not be possible tomorrow, should
ICANN allow a few more TLDs.
If you test that the TLD exists... it will still work.
If you test that the name matches (com|net|org|[a-z]{2}), then you are
not what I would call a security-aware programmer.
requiring valid domain contacts.
ICANN does require valid contacts. And it requires them to be
published and sold. So, people lie to protect their privacy. In the
world of security, stupid ideas often backfire.
I have to conclude that ICANN has failed, simply failed, and should be
returned to the US government.
It never leaved it.
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, Jun 27, 2008 at 10:24:48AM -0700, Scott Francis [EMAIL PROTECTED] wrote a message of 32 lines which said: what problem is ICANN trying to solve with this proposal? What about the current system that's broken, does this new system fix? ICANN is simply responding to demand. Some people want to create a TLD. The existence of a TLD is not a problem for the other TLDs. If the new TLD is stupid or useless (like .aero or .pro), it will fail. So what? That's the normal life of projects. Why ICANN should evaluate the new TLD applications, apart from some simple technical checks? If something is wanted and causes no harm for the others, then why in hell ICANN should refuse it? I did not suspect that the idea of central regulation of business, with a state-like committee examining business ideas and allowing them or not, was an idea so popular among Nanog members :-)
Re: ICANN opens up Pandora's Box of new TLDs
On Sun, 29 Jun 2008, Tuc at T-B-O-H.NET wrote: This requires serious elaboration. How could you use a domain in .exe to actually attack someone? (No handwaving, please, actual study.) I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ? I think this would be one of the TLDs that they'd refuse. Then again, there are DOS commands that do end in .com (CHOICE, COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : http://support.microsoft.com/kb/72188 What about .stupid? Gadi. Tuc/TBOH
RE: ICANN opens up Pandora's Box of new TLDs
You do have a choice if you're not concerned about the deliverability of your e-mail. Remember, the Internet remains a group of service providers/organizations/subscribers that voluntarily work together and can choose what goes in or out. And so if they decide not to receive traffic from you, for any reason at all, there's no legal requirement. If they require that all e-mail servers that want to send e-mail to them have rDNS entries then persons who want to deliver e-mail to that entity need to comply. Frank -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Sunday, June 29, 2008 11:32 AM To: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs snip We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) snip
Re: ICANN opens up Pandora's Box of new TLDs
Stephane Bortzmeyer [EMAIL PROTECTED] wrote:
I am very curious of what tests a security-aware programmer can do,
based on the domain name, which will not be possible tomorrow, should
ICANN allow a few more TLDs.
The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and
'[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective.
Aside from the IP issues it effectively precludes anyone from defining a
hostname that cannot also be someone else's domain name. It's not too hard
to see the problems with that. An analogous network scenario would be IP
addresses of varying length and without a netmask.
If you test that the TLD exists... it will still work.
Only if A) you are always online with B) reliable access to the tld's
nameserver/s, and C) can deal with the latency. In practice this is
often not the case.
If you test that the name matches (com|net|org|[a-z]{2}), then you are
not what I would call a security-aware programmer.
Will you still think that when someone buys the right to the .nic tld and
starts harvesting your queries and query related traffic? Not that that
doesn't happen now, to a far lesser degree. But it's the extent to which
this presents new opportunities for black hats that should have given ICANN
pause. Odds are that RBLs will be among the first targets.
Bottom line is the decision was made for it's _monetization_ value, not
security, and customer service was just a pretense.
Roger Marquis
Re: ICANN opens up Pandora's Box of new TLDs
You do have a choice if you're not concerned about the deliverability of your e-mail. Remember, the Internet remains a group of service providers/organizations/subscribers that voluntarily work together and can choose what goes in or out. And so if they decide not to receive traffic from you, for any reason at all, there's no legal requirement. If they require that all e-mail servers that want to send e-mail to them have rDNS entries then persons who want to deliver e-mail to that entity need to comply. Frank So can I change my SMTP greeting to be : 220-host.example.com SMTP 220-Company agrees to the following rate chart to accept mail : 220-EHLO - $5.00 220-HELO - $2.50 220-MAIL FROM:* - Free 220-RCPT TO:* - 1-5/$4.00 , 6-10/$6.00, 11-15/$8.00, 15+/$10.00 220-DATA: $.01 per character until final .CR 220-Delivery confirmation (Return-Receipt-To, X-Confirm-Reading-To, Disposition-Notification-To) - $1.50 220 Sending HELO/EHLO constitutes acceptance of this agreement Thanks, Tuc/TBOH
Re: ICANN opens up Pandora's Box of new TLDs
If you test that the TLD exists... it will still work. Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case. Even under the most wildly optimistic scenarios, it's hard to imagine new TLDs being added more than once a month, and I presume that everyone here already knows how easy it is to get copies of the root zone. The reasonable way to validate TLDs is to fetch a copy of the zone every couple of weeks and cache it. By the way, to be sure we're all on roughly the same page, here's a quiz. How many names are there in the root zone right now? a) 11 b) 97 c) 153 d) 280 e) 974 Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly.
Re: ICANN opens up Pandora's Box of new TLDs
* Jeroen Massar: Some people are going to get very rich over this. I hope that they drown in the money just as the Internet will drown in all the crap TLD's, not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) .exe abd .com are equivalent in this regard. Oops. Thank you people doing all the ICANN politics for destroying the Internet. I don't really see how this is substantially different from .me, .mobi, .cat or .eu. Basically, selling TLDs means that ICANN has some sort of implied non-technical obligation of keeping them relatively scarce, which is currently lacking AFAICT.
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote: On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server. After that, other sanity checks (such as matching forward DNS, valid HELO, proper wait for SMTP greeting, etc.) also knock out a good chunk of spam. Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs. Beyond that, blocking of various gTLDs and ccTLDs and network allocations works nicely, depending on what your particular mix of inbound spam/not-spam is. Understanding of your own inbound mail mix is crucial to deciding which ones are viable for your operation. Locally, I've had .cn and .kr along with their entire network allocations blacklisted for years, and this has worked nicely; but clearly it wouldn't work well for, say, a major US research university. Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it. ---Rsk
Re: ICANN opens up Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 08:41:28AM +0900, Randy Bush wrote: this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam. Globally, yes, but anti-spam measures aren't global: they're local. Everyone's mix is different: for example, during the past week, informal comparison of the incidence of pump-and-dumps spams revealed that one correspondent's have dropped to almost nothing, while another's continue to steadily increase. Global generalizations about spam trends are interesting, but not of much use in crafting local policy. The only thing that works for that is log analysis, in order to identify the composition of traffic and thus craft a policy (and then presumably implement it) that attempts to minimize the local FP/FN rates. (Note that FP/FN are always defined locally; there is no such thing as a general definition.) That said, global trends can provide some idea of what to look for in local traffic: for example, given the massive infestation of .info by spammers, phishers, spyware, adware, trojans, typosquatters, link farms, drive-by-downloaders, etc., it's very likely that most people will see a significant reduction in spam by blacklisting the TLD. ---Rsk
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, Jun 27, 2008 at 10:24:48AM -0700, Scott Francis wrote: more to the point ... what problem is ICANN trying to solve with this proposal? Oh, that's quite straightforward: insufficient registrar revenue. ---Rsk
Re: ICANN opens up Pandora's Box of new TLDs
Randy Bush [EMAIL PROTECTED] writes: this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam. The US is also the largest single source of email-that-I-want. Conversely, it's safe to assume that anything encoded in BIG5 format is something I'm totally uninterested in. There are indeed entire countries that I could block with a false positive rate of less than one every five years, which is a lot better than some other antispam technologies. Not that I'm doing this though. RBLs, SA, and greylisting with a carefully crafted list of organizations I've found that don't play well, works well enough, and having everything wired up so it runs at or before the end of the DATA phase means I don't get left holding the bag for anything. -r
Re: ICANN opens up Pandora's Box of new TLDs
Tony Finch wrote: On Thu, 26 Jun 2008, Jeroen Massar wrote: thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) .exe has the same security properties as .com not exactly, as a lot of users know that there is something like a .com domain. they will expect something else from .exe but for automated security, i quite agree. cheers, raoul -- DI (FH) Raoul Bhatia M.Sc. email. [EMAIL PROTECTED] Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email.[EMAIL PROTECTED] 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax.+43 1 3670030 15
Re: ICANN opens up Pandora's Box of new TLDs
Owen DeLong (owen) writes: Whether some choose to do that or not, I believe that the point is that: 1.Nobody is FORCING them to do so. Trademark law is forcing you to - you have to make reasonable attempts to actively defend your trademark. Of course, no-one forces you to trademark your name in the first place. Not that I agree with the practice, either. Phil
Re: ICANN opens up Pandora's Box of new TLDs
Rich Kulawiec (rsk) writes:
Best practice is refuse all mail that comes from any host lacking rDNS,
since that host doesn't meet the minimum requirements for a mail server.
No, that's utterly stupid. You're excluding countries which have
poor infrastructure or clueless ISPs (usually legacy telco operators)
who can't be bothered to administrate IN-ADDR.ARPA delegations for
their customers. It doesn't help, and only encourages people in
these countries to go for @{hotmail|yahoo|gmail}. Millions of botnet
PCs have valid reverses.
Yes, some of these also impact non-spamming but broken mail servers,
however, this is usually the only way to get the attention of their
operators and persuade them to effect repairs.
You're kidding, right ? They don't give a rat's ass.
Locally, .name, .info and .tv are permanently blacklisted, and I recommend
this to others: they're all heavily spammer-infested. .biz is not
blacklisted at the moment, largely because it's been so badly ravaged
that spammers *appear* to be abandoning it.
Bomb the bridge, salt the earth approach ?
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 6:11 PM, Jean-François Mezei wrote:
But my uneducated opinion is that this current project appears to let
the .TLD loose and this will result in top level domains being
meaningless, without any trust.
Given the complexity of the new gTLD process, I think it safe to say
that there will be quite significant vetting of pretty much all
aspects of new TLD applications. The press reports that say 'the
floodgates have been opened' simply aren't true.
There should have been an evolution from a tightly controlled small
set
of TLDs towards alowly growing set of TLDs done fairly and openly.
There has been. There was an initial set of 7 new TLDs (biz, info,
name, museum, coop, aero, pro) back in 2002. There was much
(justifiable IMHO) unhappiness about the process that created these
TLDs. ICANN went back to the drawing board and came up with a new
process ('sponsored' TLDs) which resulted in travel, cat, jobs, mobi,
tel, and post (xxx was in this crowd but was shot down). There was
much (justifiable IMHO) unhappiness about the process that created
these TLDs. ICANN went back to the drawing board and came up with a
new process. And here we are. I'm sure ICANN got it exactly right
this time... (OK, maybe not :-)).
Regards,
-drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 8:59 PM, WWWhatsup wrote: David Conrad wrote: With that said, personally, I agree that more attention should be spent on the welfare of the registrants. Unfortunately, given I work for ICANN, my providing comments in the RAA public consultation along those lines would be a bit ... awkward. Would you agree with Danny Younger (I believe this is his position) then that there should be a properly constituted recognized registrants constituency? Obviously speaking personally, conceptually I agree, but the challenge here has always been how do you properly constitute and recognize registrants in a way that doesn't allow for capture. For example, you could say 'only folks who have domain names can be part of that constituency', but in reality, the majority of domain names are held by registrars. You could add the restriction that 'registrants' must be natural persons, but how would one verify this across the entire planet? It obviously isn't impossible, but people already complain about how big ICANN is -- I can't see how having some mechanism to validate a registrant constituency won't make ICANN _much_ larger... However, lacking this, I personally believe there should be strong explicit registrant protections built into the RAA. But that's just me. Regards, -drc
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 28, 2008, at 4:19 AM, Raoul Bhatia [IPAX] wrote: Tony Finch wrote: On Thu, 26 Jun 2008, Jeroen Massar wrote: thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) .exe has the same security properties as .com not exactly, as a lot of users know that there is something like a .com domain. they will expect something else from .exe I'm not sure I understand the security threat here. Is the theory that someone will click on foo.exe and the fact that it is a URL is somehow worse than if it is an actual executable? If that's not it, can someone explain (small words, with subtitles -- I'm not a security geek). Thanks, -drc
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 28, 2008, at 6:48 AM, Rich Kulawiec wrote: On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote: On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server. After that, other sanity checks (such as matching forward DNS, valid HELO, proper wait for SMTP greeting, etc.) also knock out a good chunk of spam. Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs. Beyond that, blocking of various gTLDs and ccTLDs and network allocations works nicely, depending on what your particular mix of inbound spam/ not-spam is. Understanding of your own inbound mail mix is crucial to deciding which ones are viable for your operation. Locally, I've had .cn and .kr along with their entire network allocations blacklisted for years, and this has worked nicely; but clearly it wouldn't work well for, say, a major US research university. Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it. Hmm. Looking at the recent spam collection plus email archive for the accounts I host for SPAM (recent messages only) 13864 messages - 57 from .info rate = 0.4 % 13864 messages - 8761 from .com rate = 63.1 % Non-SPAM (going back ~ two years) 122846 messages - 607 from .info - rate = 0.5 % 122846 messages - 71888 from .com - rate = 58.5 % I don't see any strong reason to drop .info traffic here. Note, btw, that at least Joe Abley, Andrew Sullivan and Brian Dickson post to NANOG repeatedly from .info Regards Marshall ---Rsk
Re: ICANN opens up Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 01:56:53PM +0200, Phil Regnauld wrote: Rich Kulawiec (rsk) writes: Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server. No, that's utterly stupid. You're excluding countries which have poor infrastructure or clueless ISPs (usually legacy telco operators) who can't be bothered to administrate IN-ADDR.ARPA delegations for their customers. I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server. Millions of botnet PCs have valid reverses. Yes, I'm well aware of this, especially since I was AFAIK one of the first people to document the use of botnet PCs to send spam. And of course That's why this particular measure doesn't work for them, but other best practices do, e.g., rejecting mail from known-dynamic/generic IP space or known-dynamic/generic namespace unless it's your own customer or is being submitted with authentication non-port 25 Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs. You're kidding, right ? They don't give a rat's ass. Then they should not be troubled that their mail is being rejected. Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it. Bomb the bridge, salt the earth approach ? I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide information?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else. I'm not the one responsible for failure to enforce any meaningful requirements on registrars to control abuse by their customers. And so on. I suggest laying blame on the people who are responsible for the current state of affairs, not on the recipients of abuse. ---Rsk
Re: ICANN opens up Pandora's Box of new TLDs
Phil Regnauld wrote: Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. As a practical matter, I've found that sending out email from a host without rDNS doesn't work: too many sites bounce the mail. It will not come as news to anyone on this list that the world of SMTP is hardly well-defined or well-regulated in practice. Like Rowlf the dog, we can't live with it, we can't live without it, but we're stuck until something better comes along: http://www.youtube.com/watch?v=1vvV9LjBsNw Jim Shankland
RE: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
One way to provide protection is too allow those who have the domain portion of any domain.(com|net|org|...) to have first dibs for the domain of any new gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs on nanog.thisisgreatstuff. Or is that too simplistic and fraught with division? Frank -Original Message- From: David Conrad [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2008 7:50 AM To: WWWhatsup Cc: nanog@nanog.org Subject: Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) On Jun 27, 2008, at 8:59 PM, WWWhatsup wrote: David Conrad wrote: With that said, personally, I agree that more attention should be spent on the welfare of the registrants. Unfortunately, given I work for ICANN, my providing comments in the RAA public consultation along those lines would be a bit ... awkward. Would you agree with Danny Younger (I believe this is his position) then that there should be a properly constituted recognized registrants constituency? Obviously speaking personally, conceptually I agree, but the challenge here has always been how do you properly constitute and recognize registrants in a way that doesn't allow for capture. For example, you could say 'only folks who have domain names can be part of that constituency', but in reality, the majority of domain names are held by registrars. You could add the restriction that 'registrants' must be natural persons, but how would one verify this across the entire planet? It obviously isn't impossible, but people already complain about how big ICANN is -- I can't see how having some mechanism to validate a registrant constituency won't make ICANN _much_ larger... However, lacking this, I personally believe there should be strong explicit registrant protections built into the RAA. But that's just me. Regards, -drc
Re: ICANN opens up Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote: Rich Kulawiec (rsk) writes: I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server. Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. There are de jure requirements (e.g., RFCs) and de facto requirements (e.g., best practices). de jure: RFC 1912, I believe, indicates that all Internet hosts should have rDNS. de facto: attempting run a mail server without rDNS is increasingly a losing proposition, as everyone with any clue at all is refusing all mail from such misconfigured/broken/ hijacked hosts. Reverse DNS is not. Not directly, unless delegated, of course. But mail server operators who choose incompetent/lazy/cheap ISPs should not be surprised if they are given incompetent/lazy/cheap service. Quality ISPs are well aware of the de jure and de facto requirements and have no problem meeting them. known-dynamic is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable. There is no such thing as collateral damage because there is no such thing as damage in this context. I explained this in detail on the ietf-asrg mailing list a couple of months ago. And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication. Probably bounces will be the next thing to disappear. Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts. The operators don't care. The customers do. The customers don't have a choice, often. So you're right, the operator is not troubled that their customer's mail is being rejected. Then that's a matter between the customer and the operator. Customers who have chosen poorly are likely to have issues. Customers who have not availed themselves of other options (such as a third-party relay through a host whose operators actually knows what they're doing) will get...what they get. I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide information?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else. Because .org and .com don't do that as well ? I see a fundemental difference here. .org is for organizations, .com for commercial operations, .net for network service operations. I see valid uses for those. I see none for .info. Its main reason for existence is to provide a cash cow to registrars. Don't go preaching it as a best practice, though. shrug It's been a best practice for years. ---Rsk
Re: ICANN opens up Pandora's Box of new TLDs
On 6/28/08, Rich Kulawiec [EMAIL PROTECTED] wrote: On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote: Rich Kulawiec (rsk) writes: ... And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication. Probably bounces will be the next thing to disappear. Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts. Those two statements of yours directly contraindicate each other. If end user systems should use outbound mail relays, then the relay system is the one accepting the mail from the mail client, and will be responsible for sending out to the end system; it cannot make a determination as to whether the mail will be deliverable or not during the SMTP conversation with the client machine; it will only find out if the mail is actually deliverable when it in turn goes to establish an SMTP conversation with the receiving system, at which point if the receiving system indicates the message will not be deliverable, there is no way other than by generating a bounce message for the relay system to notify the original sender that the mail was undeliverable. Or, are you proposing that outbound mail relays hold the *client* connection state in limbo until they establish an outbound connection to the final destination, determine the deliverability of the final recipient, and *only then* acknowledge receipt of the message back to the client machine? If so, I think you may hear the distributed sound of every operator of outbound mail relay systems for ISPs of any scale *plonk*ing you in their clueless bucket. ^_^; In case it wasn't clear, a relay system like that simply won't scale at all, as the number of simultaneous pass-through connections required would increase as the ability to batch-process sending to common recipient systems would drop to near zero, End users would quickly cry foul and abandon operators who attempted such a system, as it would mean a slow-responding MTA box at the recipient end would hang their mail client as it waited to hear back from the relay host as to whether their attempt to send mail had succeeded or not. Until the entire concept of SMTP is replaced with something drastically different, along the lines of a real-time message passing system closer to IRC or IM, bounces are the only means for notifying a sender that a message could not be delivered. Matt
Re: ICANN opens up Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 01:12:39PM -0700, Matthew Petach wrote: Those two statements of yours directly contraindicate each other. No, they don't. Outbound relays (which are presumably used by client systems presenting appropriate authentication) know the identity of user presenting credentials. They can thus return a NDN (or similar) to that user, i.e., there's no concern about outscatter. But worth noting is that this works *because* the mail is being submitted with user authentication -- it won't work for a relay that doesn't do that. That's a very different situation from case where the same outbound relay is talking to a random mail server elsewhere on the 'net. Attempts by such random mail servers to return bounces to their origin (from when they never came) are outscatter, which is why rejects are much preferred. (Yes, I'm aware of various mail authentication proposals. Whatever they are/aren't, they're not the right solution to this specific problem: the solution is to always reject, never bounce.) ---Rsk
RE: ICANN opens up Pandora's Box of new TLDs
Some people are going to get very rich over this. How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. In such a scenario, nobody makes much money unless they somehow link the TLD product to something else which is profitable. --Michael Dillon
RE: ICANN opens up Pandora's Box of new TLDs
And no, companies *aren't* forced to pay for another domain name just because a new TLD appears -- they aren't doing it *now* Oh yes we are Looking at bbc.org and bbc.tv suggests that you are not. --Michael Dillon
RE: ICANN opens up Pandora's Box of new TLDs
There are probably some variations based on the zone, languages, IDN'ability, etc., but it certainly is a good idea to be bankofamerica.* for reasons that I think are obvious to most of us. To make it hard for your customers to figure out whether a URL is legitimately owned by the bank? To make it easier for evil guys to steal from your customers by registering bonkofamerica.*? Back to language examples. It would be perfectly legitimate for BBC.ru to be owned by someone other than the well-known broadcaster because in Russian, BBC is the abbreviation for the air force. Probably this applies even more to BBC.aero. IMHO things work better when you have a home TLD and then only use other TLDs when it relates to your business operations. For instance example.com is the home TLD, example.net is used by their consumer broadband division, example.co.uk by their UK sales branch and example.cn by their manufacturing division in Shanghai. --Michael Dillon
Re: ICANN opens up Pandora's Box of new TLDs
[EMAIL PROTECTED] i'rta: There are probably some variations based on the zone, languages, IDN'ability, etc., but it certainly is a good idea to be bankofamerica.* for reasons that I think are obvious to most of us. To make it hard for your customers to figure out whether a URL is legitimately owned by the bank? To make it easier for evil guys to steal from your customers by registering bonkofamerica.* Maybe somebody start a trusted service under a new TLD, and you can block all the others. Laszlo Balazs
Re: ICANN opens up Pandora's Box of new TLDs
Balazs Laszlo wrote: [EMAIL PROTECTED] i'rta: There are probably some variations based on the zone, languages, IDN'ability, etc., but it certainly is a good idea to be bankofamerica.* for reasons that I think are obvious to most of us. To make it hard for your customers to figure out whether a URL is legitimately owned by the bank? To make it easier for evil guys to steal from your customers by registering bonkofamerica.* Maybe somebody start a trusted service under a new TLD, and you can block all the others. background sound=Darth Vader Breathing.ogg For three seconds I thought it was maybe a nice idea for this DNS thing to be cleansed, just stick everything under this new 'trusted' TLD, but then I realized that it can't work, as who is going to decide on what is 'trusted' or not? There is a root (even per TLD and per domain) where delegations come from, as such, there is a central authority and thus a couple of people who say 'trusted' and 'untrusted', or actually 'good' and 'evil'. This was also the whole point of having ccTLDs, so that every country at least could have their own share of the tree (hoping that the root had truly trusted people who would not just kick a part of the tree out (Russia would like to kick out .es now I guess ;) If you want trust, a trust-metric (eg PGP) could partially work. Still, that is not true trust, as it is only an attestation that at the point you said 'good' or 'evil' you found it to be like that. The internet (un)fortunately has this great dynamics factor, as such, now it might be good, all of a sudden some Russian hackers own www.ipv6.elmundo.es (which will then report on Russian winning and Spain loosing) and even though everybody trusts that site for the purpose of 'good domain' and maybe 'good reporting' it will actually be evil. Countering this is going to be extremely difficult, as you need to get everybody who trusts it to update their opinion. Or how do you get a committee to decide 'that site/side is evil'. Difficult. Currently people just trust Google and Mozilla and a various of other vendors to do this for them. This seems to work in some ways, but still on mostly static lists inside the browser, which only updates once in a while thus not very quick either. And how good is Google in not doing evil in just putting all the Russian sites on the list and blocking them off? You don't know. Evil is just what one perceives, and what is good for you, might not be good for others. If you are 'good', it is just because some people you know like you, while when you are 'evil' it is just because you are on the 'wrong' side. Thus no, I don't see '.trusted' actually being trusted, as it simply will exclude businesses which are not trusted by the other ones who control .trusted and thus will be very nice for the anti-competition laws that exist. Only real solution that I currently see seems to be: - pick a search engine you think you can trust (to degrees of etc) - type in what you are looking for, hit search if the ranking of a site is not high enough then either the site is not trusted enough because there are no links there or because tracking software didn't find enough people going there and all the other factors they use they just fail. - let the search engine warn you that site might be evil - go to the page. Don't care about the URL though, the search engine already and all their trust made sure it is a 'good' site. - Use it. That of course only covers web, but that is what most general population folks are using anyway. Thus DNS is here only used for where it was supposed to, converting a hostname into an IP address, in the background, with the user not caring about what the hostname is. As such the only thing what matters about host/domainnames will be how pretty they look, nothing more, nothing less. I still don't get why ever movie needs their own domainname, which means that there have to be a lot of sites actually referring to that new domain to be actually able to find the movie in the first place, that while the company that produces it could easily put a subpage on their website or eek a subdomain, and it will all work like a charm including keeping ones PageRank intact and local without having to pay any amount of cash. Then again, domaincapers will register it and get a few hits for it, because people apparently still trust in typing in URL's... Greets, Jeroen /background signature.asc Description: OpenPGP digital signature
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 26, 2008, at 9:20 PM, Tuc at T-B-O-H.NET wrote: Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). This all should have been solved by allowing those who wanted/applied for TLDs to be granted them back in 1995 when originally requested : http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html The SNR in the gtld WG was very low, which I think may have been an influencing factor. I do have to wonder, however, what Eugene Kashpureff thinks about this. Regards Marshall There was a procedure, people followed it, and IANA decided to go other ways with it. Now years later there is all this red tape restricting things. And if the powers that be decide to go back to it, you can replace stormking.com with t-b-o-h.net and I look forward to it! ;) Tuc / Scott Ellentuch
RE: ICANN opens up Pandora's Box of new TLDs
See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin
Re: ICANN opens up Pandora's Box of new TLDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shultz wrote: Owen DeLong wrote: On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr =h1Jn -END PGP SIGNATURE-
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shultz wrote: Owen DeLong wrote: On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? They should have been following RFC 2606. Regards Marshall Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr =h1Jn -END PGP SIGNATURE-
Re: ICANN opens up Pandora's Box of new TLDs
R. Irving wrote: /lurk Thank you people doing all the ICANN politics for destroying the Internet. You know, last time someone ( Robert Metcalfe http://en.wikipedia.org/wiki/Robert_Metcalfe) prophesied the death of the Internet, when it didn't come true... we made him eat his words. You up for a repeat ? Wow, you are comparing a nobody like me to a person like Dr. Metcalfe, I am honored, though I don't even start to think that I even compare to him in any way, thus why you come up with that comparison? Just amazing. That said, 'destroying' is not 'death at 11', also I am not so silly to do bets on things. Nice try, but it doesn't work for me. I guess you better stick to the lurking. As for destroying the Internet, it is going to work out that way, as the .com as we know it won't exist any more, and most people only think .com when they think Internet. Then again they also only know WWW and nothing else, which is why I really don't like this DNS change which is already solved with search engines. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: ICANN opens up Pandora's Box of new TLDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marshall Eubanks wrote: On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote: Jeff Shultz wrote: Owen DeLong wrote: On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? They should have been following RFC 2606. Regards Marshall Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause. Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhkxHAACgkQUVxQRc85QlPfmgCgiIUv7KYOz/U2vdk2DyA04D/O 8Q4An2wK8vilUCJne06qIn/67erB2rkt =ih+F -END PGP SIGNATURE-
Re: ICANN opens up Pandora's Box of new TLDs
Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote: See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin
Re: ICANN opens up Pandora's Box of new TLDs
Eric; The only reason I would have supported rejecting the proposal is the 'morality' language related to offensive TLD's. . What's your take on that part of the process? Marty - Original Message - From: Eric Brunner-Williams [EMAIL PROTECTED] To: Martin Hannigan Cc: nanog@nanog.org nanog@nanog.org; [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Fri Jun 27 10:57:15 2008 Subject: Re: ICANN opens up Pandora's Box of new TLDs Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote: See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin
Re: ICANN opens up Pandora's Box of new TLDs
Martin, You know the phrase Paris is worth a mass? Well, we get .paris, as well as .cat, and other reasonable things, plus chaff and clutter. Eric Martin Hannigan wrote: Eric; The only reason I would have supported rejecting the proposal is the 'morality' language related to offensive TLD's. . What's your take on that part of the process? Marty - Original Message - From: Eric Brunner-Williams [EMAIL PROTECTED] To: Martin Hannigan Cc: nanog@nanog.org nanog@nanog.org; [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Fri Jun 27 10:57:15 2008 Subject: Re: ICANN opens up Pandora's Box of new TLDs Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote: See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin
RE: ICANN opens up Pandora's Box of new TLDs
And no, companies *aren't* forced to pay for another domain name just because a new TLD appears -- they aren't doing it *now* Oh yes we are Looking at bbc.org and bbc.tv suggests that you are not. We used not to, bbc.org and others are why we started. We did have bbc.tv for a while, what you see now shows why this is a considered a problem. I tried to stick to just one, I was wrong, legal overuled technical. Now we have thousands such as bbcsathalanalatpaxathipataipaxaxonlao.com but not some obvious ones brandon
Re: ICANN opens up Pandora's Box of new TLDs
Some people are going to get very rich over this. How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. You might enjoy my blog entries about the .TRAVEL domain: http://weblog.johnlevine.com/ICANN/travelcroak.html http://weblog.johnlevine.com/ICANN/travelnotdead.html http://weblog.johnlevine.com/ICANN/traveldrain.html http://weblog.johnlevine.com/ICANN/travelstillnotdead.html
Re: ICANN opens up Pandora's Box of new TLDs
http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html The SNR in the gtld WG was very low, which I think may have been an influencing factor. Yeah, it was dominated by a bunch of small-scale amateur greedy speculators, while the solution was ICANN which is dominated by a bunch of large-scale professional greedy speculators. We did come up with the registrar/registry split, though. http://www.iahc.org/contrib/draft-iahc-levine-shared-00.txt R's, John
Re: ICANN opens up Pandora's Box of new TLDs
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. If only there was a way to get the cruft to move over into the new ones... On Fri, Jun 27, 2008 at 1:05 PM, John Levine [EMAIL PROTECTED] wrote: Some people are going to get very rich over this. How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. You might enjoy my blog entries about the .TRAVEL domain: http://weblog.johnlevine.com/ICANN/travelcroak.html http://weblog.johnlevine.com/ICANN/travelnotdead.html http://weblog.johnlevine.com/ICANN/traveldrain.html http://weblog.johnlevine.com/ICANN/travelstillnotdead.html
Re: ICANN opens up Pandora's Box of new TLDs
On Thu, 26 Jun 2008 17:16:52 PDT, Ken Simpson said: On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc.. Oh - vomit - this is gonna hurt. A cow-orker of mine said: How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot pgpMljApwphZM.pgp Description: PGP signature
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, 27 Jun 2008 00:01:23 EDT, =?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?= said: Finally, will there be any performance impact on DNS servers around the world (thinking of caching issues) ? It should be almost identical to the current performance impact on the second level DNS servers that have to handle 140M .com entries... pgpG8ouS3kLCs.pgp Description: PGP signature
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 27, 2008, at 8:22 AM, Alexander Harrowell wrote: Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. If only there was a way to get the cruft to move over into the new ones... Hey, please don't ignore .tv. No cruft from me, at least. Marshall On Fri, Jun 27, 2008 at 1:05 PM, John Levine [EMAIL PROTECTED] wrote: Some people are going to get very rich over this. How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. You might enjoy my blog entries about the .TRAVEL domain: http://weblog.johnlevine.com/ICANN/travelcroak.html http://weblog.johnlevine.com/ICANN/travelnotdead.html http://weblog.johnlevine.com/ICANN/traveldrain.html http://weblog.johnlevine.com/ICANN/travelstillnotdead.html
Re: ICANN opens up Pandora's Box of new TLDs
Hey, please don't ignore .tv. No cruft from me, at least. The two letter country codes are a swamp all of their own, with no help from ICANN. I hear that Tuvalu approximately doubled its GNP the year they sold the rights to .tv. R's, John
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote: Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? They should have been following RFC 2606. Regards Marshall Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause. .localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The .localhost TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect. If you can think of a list, it probably would... Having had the need to construct a few TLDs for internal use, I hope that some new RFC will address this and reserve some (e.g. .internal, .internal# (where # is any fully numeric string), .local)? I really don't care what they are called, but I do need more than one. Marshall Jon snip -- -=[L]=- Helping to interpret the lives of the animals.
Re: ICANN opens up Pandora's Box of new TLDs
Dear Lou; On Jun 27, 2008, at 12:21 PM, Lou Katz wrote: On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote: Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? They should have been following RFC 2606. Regards Marshall Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause. .localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The .localhost TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect. If you can think of a list, it probably would... Having had the need to construct a few TLDs for internal use, I hope that some new RFC will address this and reserve some (e.g. .internal, .internal# (where # is any fully numeric string), .local)? I really don't care what they are called, but I do need more than one. There are 4 already, .test .example .invalid .localhost . I suspect that .local should also be reserved, which would make 5. It seems that .internal# should just be blocked, not reserved. Before, the feeling was that the best blockage was a reservation, but as I read the ICANN presentation, if .internal was reserved, .internal# could be blocked too without an explicit reservation. Regards Marshall Marshall Jon snip -- -=[L]=- Helping to interpret the lives of the animals.
Re: ICANN opens up Pandora's Box of new TLDs
On 27 Jun 2008, at 02:13, Chris Adams wrote: Once upon a time, Ken Simpson [EMAIL PROTECTED] said: Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc.. Somebody on /. mentioned .dot, so you could tell someone to go to: eych tee tee pee colon slash slash slash dot dot dot Or .dash ...
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 1:57 PM, Bill Nash wrote: On Fri, 27 Jun 2008, Scott Francis wrote: perhaps somebody with more insight can explain the rationale to me (DRC?) - is there a purpose served here aside from corporate/legal interests? It strikes me as fomenting another gold rush. The notion that disputed TLDs go up for auction sounds like a request for a nice, high quality money printing device. I may have skimmed over it, but where does the money from these auctions go? At the risk of invoking Ron Paul, this will turn TLDs into a fiat currency, and devalue the rest of them. A small subset of people will profit, and everyone else loses. Off the top of my head, I can see some high dollar fist fights breaking out for .sex, .porn, .games, .hotel, etc. It'll be like the .alt tree on usenet for people with money. There may also be an actual fist fight over TLDs like .irc, .leet, .goatse, and .krad. Maybe not .krad. The Newdom WG was frequently insane, reaching its peak in the hack for which Eugene Kashpureff went to jail. I for one would not want to go there again. I agree with Scott, I'd rather see ICANN spend time on current problems instead of making new ones. +1 - billn Marshall
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
David Conrad (drc) writes: Other folks believe that anything that reduces the effective monopoly VeriSign has (through .COM and .NET) would be a good thing. This view holds that by increasing the number of top-level domains, you increase the opportunities for consumer (that is, domain registrant) choice, thereby reducing the value of any single top-level domain. The process ensures that too few new TLDs will be created for it being a threat to VeriSign, but sufficiently enough of them will be created that it will bring in lots of cash, if only with application fees, auction, but also because of the perceived rarity. As business models go, it's a fine example of how to build demand without really servicing the community. component of this management was explicitly stated as being the promotion of competition. While one might argue that creating new top-level domains doesn't really promote competition given the cost of changing from one domain name to another, realistically, I figure there aren't many other ways in which additional opportunities for competition can be created. Allowing anyone to register a TLD is one, but I do agree it's not necessarily a trivial model.
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, 27 Jun 2008, Jon Kibler wrote: Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. .local is also used by MDNS. (Nice interop problem there.) Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: ICANN opens up Pandora's Box of new TLDs
On Thu, 26 Jun 2008, Jeroen Massar wrote: thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) .exe has the same security properties as .com Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ TYNE DOGGER FISHER: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 11:44:35AM -0400, Joe Abley wrote: On 27 Jun 2008, at 11:22, [EMAIL PROTECTED] wrote: How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot To my mind, Tony Finch owns you all :-) http://dotat.at/ [EMAIL PROTECTED] Well, I believe the gent whose email is [EMAIL PROTECTED] is tied with him... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+-+RFC 2100 Ashworth Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ICANN opens up Pandora's Box of new TLDs
On Thu, Jun 26, 2008 at 10:49:41PM -0400, Rich Kulawiec wrote: For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing. The irony that MailScanner's domain is mailscanner.info is absolutely deafening. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+-+RFC 2100 Ashworth Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 12:01:23AM -0400, Jean-Fran?ois Mezei wrote: Does anyone know how if the new gTLD system will still give some veto power to some people over some domain names that are morally objectable to some people ? I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI .CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc. .WOMEN-WITH-VISIBLE-FACES? For instance, in the USA ABC is the american broadcasting companies, but in australia, it is the Australian Broadcasting Corporation. Is it fair to hand .ABC to either one of the two ? (highest bidder) or will ICANN lock .ABC out so that neither can get to it ? I am sure there are many such gTLDs around the world that would conflict across countries. Sure, which is why that's not what should be being *done* with GTLDs. But engineering issues will be the very least of anyone's concern here. Cheers, -- jra -- ay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+-+RFC 2100 Ashworth Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, Jun 27, 2008 at 12:23:28PM -0700, Scott Francis wrote: that's exactly my point! it's _not_ reliable, but it's the behavior that the average user has come to expect. If we can't even guarantee reliability with the small handful of TLDs currently in use, when we start introducing arbitrary new ones to anybody that can pay, I'm concerned that it's going to make user support even more of a headache (for those of us unfortunate enough to be involved in that role, professionally or personally :)) That sounds like the gun control will reduce gun crime argument, to me. :-) If there are enough *widely used* (generic) TLDs, then *people will stop believing that .com is the 'real' domain (wasn't that Verisign's sales pitch, once upon a time?). Cheers -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+-+RFC 2100 Ashworth Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
RE: ICANN opens up Pandora's Box of new TLDs
If they assign .local, they will break the default for AD, especially SBS, Apple Rendezvous, anything using mDNS/Zeroconf, and a lot of other local significance only uses of DNS, or, which is more likely, the domains in .local will find themselves unresolvable from a very large portion of the Internet. .local should be reserved. -Original Message- From: Tony Finch [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 12:21 PM To: Jon Kibler Cc: NANOG list Subject: Re: ICANN opens up Pandora's Box of new TLDs On Fri, 27 Jun 2008, Jon Kibler wrote: Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. .local is also used by MDNS. (Nice interop problem there.) Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: ICANN opens up Pandora's Box of new TLDs
Phil Regnauld wrote: As business models go, it's a fine example of how to build demand without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis
Re: ICANN opens up Pandora's Box of new TLDs
Hi, On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Of those messages that have origins (as extracted from the appropriate Received header) that do reverse map, the majority are in com and net. The mail origins of the top 10 TLDs from the last 30K spam messages I've received): unknown: 12487 net: 2586 com: 1664 pl: 1093 ru:917 it:851 br:652 de:479 th:372 fr:226 Biz, info, and name don't show up at all. Looking at the 'From' lines, I get: com: 13432 de: 8819 net: 1959 org: 1902 uk: 256 it: 246 nl: 240 edu: 229 au: 181 ca: 180 What cruft are you filtering using top-level domains? Thanks, -drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: I'd rather see ICANN spend time on current problems instead of making new ones. Out of curiosity, what are the problems you feel ICANN should be spending its time on? Regards, -drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 11:58 AM, Phil Regnauld wrote: The process ensures that too few new TLDs will be created for it being a threat to VeriSign This remains to be seen, at least from my perspective. I have no idea how many TLDs are going to make it through the gauntlet or even how many applicants there will be. If nothing else, I'm sure it'll be 'interesting' (for some value of that variable). Regards, -drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 12:23 PM, Scott Francis wrote: If we can't even guarantee reliability with the small handful of TLDs currently in use, when we start introducing arbitrary new ones to anybody that can pay, I'm concerned that it's going to make user support even more of a headache I might suggest that the assumption that reliability can be guaranteed by TLD (any number), regardless of what the labels might imply, is where things are broken. That ship has sailed (and already crashed into the rocks and sunk). Regards, -drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, Jun 27, 2008 at 1:49 PM, David Conrad [EMAIL PROTECTED] wrote: On Jun 27, 2008, at 12:23 PM, Scott Francis wrote: If we can't even guarantee reliability with the small handful of TLDs currently in use, when we start introducing arbitrary new ones to anybody that can pay, I'm concerned that it's going to make user support even more of a headache I might suggest that the assumption that reliability can be guaranteed by TLD (any number), regardless of what the labels might imply, is where things are broken. That ship has sailed (and already crashed into the rocks and sunk). indeed, TLD provides no assurance of authenticity. However, my concern is that adding add'l TLDs will make this problem worse, not better - what little assurance we have that e.g. bankofamerica.com is the legitimate (or should I say, _a_ legitimate) site for the financial institution of the same name becomes less certain when we have e.g. bank.of.america, www.bankofamerica.bank, www.bankofamerica, www.bofa, and other variants. Perhaps the solution is to devalue names (through the introduction of some theoretically unlimited number of variants) to the point that users come to rely upon reputation-based systems (e.g. PageRank) exclusively. Or maybe I'm just brewing a tempest in a teapot. *shrug* What I do know is that the folks @ ICANN who were involved in this are universally more experienced than myself, so I think perhaps I'll pipe down for a while and see what happens. :) cheers, -- [EMAIL PROTECTED],darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
In article [EMAIL PROTECTED], Bill Nash [EMAIL PROTECTED] writes I agree with Scott, I'd rather see ICANN spend time on current problems instead of making new ones. Did you express that opinion to the Paris meeting? [Not an attack on you specifically, but as this process has been ongoing for at least five years, I think I detect a number of people here hastily building stables, debating what kind of door to attach, when the horse is already several blocks away.] -- Roland Perry
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, 27 Jun 2008 17:04:19 EDT, =?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?= said: Say I am a pastry chef, and I pay $40 per year for pastry.com, I got it because I signed up early and now cherish my domain name. I am a small business. But now, some rich guy can come in and bid for .pastry This will prove interesting for users who are still using browsers that will automagically prepend 'www.' and append '.com'.. :) pgpw3RYvhNhcP.pgp Description: PGP signature
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 2:02 PM, Scott Francis wrote:
what little assurance we have that e.g. bankofamerica.com is the
legitimate (or should I say, _a_ legitimate) site for the financial
institution of the same name becomes less certain when we have e.g.
bank.of.america, www.bankofamerica.bank, www.bankofamerica, www.bofa,
and other variants.
I agree, but we already face that problem now. Is bankofamerica.
{org,net,us} the same thing as bankofamerica.com? I would agree that
a flood of new TLDs would exacerbate the problem, but I suspect the
difference is between a run over on a two lane street versus being run
over on a five lane highway. In both cases, you're road pizza
Perhaps the solution is to devalue names (through the introduction of
some theoretically unlimited number of variants) to the point that
users come to rely upon reputation-based systems (e.g. PageRank)
exclusively.
I suspect the right answer is to rely not on reputation or labels, but
rather stronger security credentials, e.g., valid X.509 certs, PGP/GPG
signatures, etc. Of course, that's been true for a while now.
Regards,
-drc
Re: ICANN opens up Pandora's Box of new TLDs
On Jun 27, 2008, at 1:32 PM, Roger Marquis wrote: Phil Regnauld wrote: As business models go, it's a fine example of how to build demand without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Oh, no. There are plenty of worse thought out approaches. _Plenty_. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. I'm not sure how much I'd trust a 'security-aware programmer' that relies on top-level domain name labels for _anything_, much less domain name validity. But perhaps I misunderstand your point. Phishers and spammers will have a field day with the inevitable namespace collisions. I believe an attempt at limiting this is found in the restriction to disallow 'confusingly similar' names. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. I suspect you might not be fully aware of how ICANN works. ICANN is not the Internet's mommy and it can't make problems go away (even those it created itself) by waving a magic wand. It works via a bottom-up policy definition process that involves a large number of parties, many of which are directly at odds with each other. Efforts are underway in several of ICANN's constituencies and advisory councils to propose solutions to all of these (e.g., for domain tasting see http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113173) , but (as I have discovered painfully) it is exceedingly difficult to have rapid forward motion in such an environment. If you try, you get accused of acting in non-open, non-transparent, non-accountable, etc. ways by all sorts of people. Really. [de rigueur ICANN bashing] It is easy to criticize (trust me, I do it all the time :-)). It is more difficult to participate to try and get things fixed. Regards, -drc
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, 27 Jun 2008, David Conrad wrote: On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: I'd rather see ICANN spend time on current problems instead of making new ones. Out of curiosity, what are the problems you feel ICANN should be spending its time on? For starters, has Verisign ever been sanctioned by ICANN for it's business practices, with stupid stuff occurring as late as what, this past February (the front running debacle)? If ICANN is supposed to be encouraging competition, et cetera, why is Verisign still in business? Also, show me a single registrar that actually gaurantees their service. Almost every registrar has boilerplate user agreements that shafts the domain owner in the event of any failure, even if the registrar screws it up. I'm not talking about some standard protection against user errors or identidy theft, I'm talking about a genuine 'If our service breaks, you get to keep both halves.' Would you use a registrar with these terms of service? I bet you do. Would you use them if you had a choice? I bet you wouldn't. Because certain states do not permit the limitation of elimination of liability for certain types of damage, $registrar's liability shall be limited to the smallest amount permitted by law. $registrar disclaims any loss or liability resulting from: 1. access delays or interruptions to our web site or domain name registration system; 3. events beyond our control (i.e. acts of God); 4. the loss of registration or processing of a domain name or the use of a domain name; 5. the failure for whatever reason to renew a domain name registration; 7. errors, omissions or misstatements; 8. deletion of, failure to store, or failure to process or act upon email messages; 9. processing of updated information to Your registration record; 11. errors taking place with regard to the processing of Your application; I pulled a couple of lines out because they were things that I felt a registrar might actually be indemnified, in the event of, but seriously. How does an entire class of business truly serve the consumer with these kinds of policies? reg·is·trar 1. a person who keeps a record; an official recorder. 2. an agent of a bank, trust company, or other corporation who is responsible for certifying and registering issues of securities. Except for domain registrars, who are only really a registrar when they make a mistake that could cost your entire commercial enterprise. I'll be the first to admit there's been progress made on the front of preventing domain theft and other shenanigans, but when it comes down to it, running a domain registry doesn't seem to be in the best interests of the primary consumers of such a product. - billn
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Fri, 27 Jun 2008, Bill Nash wrote: Except for domain registrars, who are only really a registrar when they make a mistake that could cost your entire commercial enterprise. Edit: s/when/until/ Beer:30. - billn
Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
On Jun 27, 2008, at 3:30 PM, Bill Nash wrote: On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: Out of curiosity, what are the problems you feel ICANN should be spending its time on? For starters, has Verisign ever been sanctioned by ICANN for it's business practices, You mean like Sitefinder? with stupid stuff occurring as late as what, this past February (the front running debacle)? I suspect you've confused VeriSign with Network Solutions here (and I can't comment on the NetSol stuff because ICANN was named in a lawsuit on the topic). If ICANN is supposed to be encouraging competition, et cetera, why is Verisign still in business? Well, for one reason, people continue to register their names in (say) .NET... (:-)). Also, show me a single registrar that actually gaurantees their service. [concerns about registrars] You have commented on the revision to the Registrar Accreditation Agreement (http://www.icann.org/topics/raa/) I presume? How does an entire class of business truly serve the consumer with these kinds of policies? Read a software EULA recently? With that said, personally, I agree that more attention should be spent on the welfare of the registrants. Unfortunately, given I work for ICANN, my providing comments in the RAA public consultation along those lines would be a bit ... awkward. I'll be the first to admit there's been progress made on the front of preventing domain theft and other shenanigans, but when it comes down to it, running a domain registry doesn't seem to be in the best interests of the primary consumers of such a product. I'm not sure I follow this (did you mean registrar?), but I suspect it depends on the registry. So, other than slapping VeriSign and making registrars liable for more stuff, what should ICANN be spending its time on? This is a serious question (not saying I can fix anything, but I can push internally). One of the personally frustrating things about ICANN processes is the lack of input from the network operations community. One of the reasons I'm spamming the NANOG list is to try to stir up folks from this community to actually participate in ICANN processes because, as should be apparent, it actually does matter... Regards, -drc (speaking only for myself)
