ICANN opens up Pandora's Box of new TLDs

Mailman List Mirror (Read Only)
1

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

2

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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

3

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?

4

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
"myname@smtp." 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 "user@gmail" (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 "user@msn". ^_^; )

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

5

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 user@tld, but they certainly will accept user@smtp
  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
"myname@smtp." 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

6

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)

7

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

8

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

9

  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

10

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 :slight_smile:

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.

11

In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> 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

12

In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> 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/

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.

IE was a little more normal, and simply returned a 'host unknown"
error. Annoyingly enough, however, IE returned the "host unknown"
for *both* "http://museum/&quot; and "http://museum./" so it failed to follow
proper resolution practice and ignored the trailing dot.

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. ^_^;

R's,
John

Thanks!

Matt

13

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.

14

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 n@ai (yes, his name is Ian) and see what his experience has been.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

15

>> 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 n@ai (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 :wink:

16

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 "myname@smtp." 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.

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.

Not true. There have been TLDs with MX and A records for a long time,
though they tend to be badly set up, and many MTAs treat single-component
domains specially such that email to these TLDs will often not work.

Tony.

17

It would be helpful if someone could put together of web page of different
links so that people could test the native resolvers for each OS and
applications (web browsers primarily, but also DNS clients separated from
the OS stack such as dig and nslookup).

Perhaps some of this brokenness can be illuminated sooner rather than later.

Frank

18

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

19

Doing that comlpetely generally turns out to have more layers than you
might expect. My first cut is here:

  http://bestpractices.wikia.com/wiki/Unusual_Domain_Names

Cheers,
-- jra

20

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!'