ICANN, IAB Ask VeriSign to Suspend SiteFinder

dmehus writes "ICANN issued an advisory late today concerning VeriSign's controversial SiteFinder service. The advisory requests that VeriSign voluntarily suspend SiteFinder until various independent and objective reviews, which are now underway, have been completed. Interested parties should see the advisory for more details." I think most people here can agree it was a bad idea, although it's not generating revenue for most of us either. ICANN isn't alone here either. Nuclear Elephant writes "The Internet Architecture Board issued this response to an ICANN inquiry about Verisign's SiteFinder service."

Comments

This isn't really new.

[windows]

Forgive me if I'm being idiotic about this, but relatively recently, the .museum TLD went live. It's just like any other TLD except that domains that don't exist diect you to a page saying the domain doesn't exist and with a couple of links. It's not very different than Verisign's SIteFinder, but there's little to no outcry over this. I'm curious because a lot of the objections about SiteFinder should also be true about the .museum TLD. What's different here?

Re:This isn't really new.

[SmallFurryCreature]

Oops good thing I checked before I commented.

Amazing you are right. I never knew this. That of course might be your answer. Who the fuck uses .museum anyway? (Yeah I know the obvious answer thank you) See this for all the domains on .museum. One company I maintain servers for has got more domains then this list. Anyway.

The outcry is not so much that they are cybersquatting. Well some are but that is not why the geeks are rebelling. The problem is that you used to be able to do a lot of usefull stuff by checking if a domain existed or not.

Now thanks to this you can't well not without rewriting your code. grrr.

I can only guess that nobody ever used a .museum url anyway :)

But yes it is exactly the same thing. Except for the scale difference. I guess you can't check against spam being send from a .museum domain either.

Good for finding this and pointing this out.

Not a "best guess" system

[Crimplene Prakman]

In common with the majority of internet protocols, DNS is not a best-guess system, it is a technically accurate way of transferring information, with correct failover mechanisms. From the article:

As a lookup system, the DNS is designed to provide authoritative answers to queries.

And later...

The DNS is not a search service, and presenting speculative mappings based on HTTP inputs is not the service that the registry is expected to provide.

And later still...

To restore the data integrity and predictability of the DNS infrastructure, the IAB believes it would be best to return the .com and .net TLD servers to the behavior specified by the DNS protocols.

That seems to wrap it up really. I doubt any further studies will find differently, unless Verisign follows the apparently accepted way of paying for a biassed study......

IAB response isn't

[Frater 219]

"The Internet Architecture Board issued this response to an ICANN inquiry about Verisign's SiteFinder service."

Actually, if you read that article you will find that it is dated January 25 and is a response to another Verisign screwup. That one was similar to the present one, but had specifically to do with "internationalized" domain names -- DNS records for strings with characters above ASCII position 127.

Historians find it important to check the dates of events and documents, so they can know which ones could possibly be responses to which other situations. For instance, an American comedian telling anti-French racial jokes in August 2001 could not possibly be responding to the French objection to Bush's war. Similarly, a document released January 25 2003 cannot be a response to a situation that arises the following September. Time just doesn't work that way.

Old IAB response

[zjbs14]

People keep quoting that IAB response, but if you look at the date and actually read it, you'll see it's from back in January. And it was in response to Verisign's proposed wildcarding of only domains that contained non-ASCII characters, not all domains. Their point was that wildcarding based on a character set was against standards.

So I guess Verisign interpreted that as "we better wildcard everything then."

Get the latest version of BIND

[AchmedHabib]

Get the latest version of BIND to block that Verisign junk. go here
Now all it needs is support for the Evil-Bit in TCP/IP

Real IAB Response

[bigal123]

The response in the orignal article links to something old. Here is the IAB's offical reponse. The bottom has a whole section on "Principles, Conclusions, and Recommendations" Good reading http://www.iab.org/documents/docs/2003-09-20-dns-w ildcards.html

Re:I'd love to have been a fly on the wall...

[Nurgled]

At DNS level also. Wildcard records are part of the master record format. Verisign's servers are using a more complex decision than "anything not registered" which is detailed in the IAB report.

If they simply added a wildcard record there would be no spec violation.

Re:So who gets the money ?

[warkda rrior]

DNS is not distributed, it is hierarchical. The queries travel up the tree (where the client first queries the ISP which is a leaf in the DNS tree), until the reach the top level DNS. Someone has to be at the top and manage the top level DNS. Of course, it does not have to/should not have to be Verisign...

Re:I'd love to have been a fly on the wall...

[squiggleslash]

No, not at the DNS level. At the DNS level, NXDOMAIN should be returned for domains that do not exist. www.sjnnasdfdfjksdfdndajkadjndks.com is NOT a valid name for a machine in Verisign and should never be resolved to a machine in Verisign. If you misuse wildcards to point domains at machines they're not valid for, then it becomes impossible to automatically detect errors.

While theres some legitimacy in saying "I want every email ending in .isp.net to get directed to mail.isp.net so that all my customers can have subdomains, so I'll use a wildcard for that" despite that resulting in misspellings going to that machine too, there's no such excuse with the Verisign grab. Verisign's wildcard never matches legitimate sites, and it's at such a high level that third parties will regularly be inconvenienced. It's worth noting that every paper I've read on wildcards specifically advises against using them if possible.

I have one domain at work I maintain that uses one, and we only use it because we know that if we have to get our technical services people and the DNS server company we contract the thing out to to change it for each additional subdomain we add, then it's going to get messy. I'm not happy about it, and if I could manage the name server directly, I'd do that instead.

Re:So who gets the money ?

[mlong]

maybe because they're tired of running half of the DNS system for free? I mean, we're talking absolutely huge servers that serve hundred of gigabytes per day and like 2/3 of the traffic are absolutely useless queries from random IDS and logging systems. weekend internet users won't care and the rest of us will find ways to ignore it. So why not?

You do realize that for every domain name registered in .com or .net ANYWHERE VeriSign gets a cut for running the "registry"? I think its $6. Thats a hell of a lot of money when its multiplied out. Now as far as running a root server, then perhaps, but there are dozens of other organizations also running root servers.

Re:So who gets the money ?

[Nintendork]

Reading through this thread, it's obvious that there's a lot of confusion on how DNS works. AC was close by saying that it's hierarchal, but (s)he missed a step or two. When a client needs to resolve a DNS name, it sends a recursive query to the DNS server it's configured to use. Assuming the server isn't using any forwarders (Forwarding the query on to another DNS server), it goes through the name resolution process. Let's say you type in www.slashdot.org in your web browser. Your computer will send a DNS query to the configured DNS server. The query will ask for "www.slashdot.org.". The extra dot is usually not seen by us end users, but it's there. The full host name with the trailing dot is a fully qualified domain name (FQDN). That DNS server (Let's say the ISP) will then contact the root servers (That trailing dot) and ask for the record, www.slashdot.org.. The root servers will respond that they don't have that record, but they do know where the org servers are. The DNS server will then send the same query to an org server. The org server will respond that it doesn't have the record, but it does know where the slashdot.org servers are. Finally, the DNS server sends the query to the slashdot.org servers and gets the host record for www.slashdot.org.

-Lucas

At least 15 different TLDs are doing this

[Gnavpot]

In a quick search I found 12 two-letter TLDs doing the * thingy:
.ac, .cc, .cx, .mp, .nu, .ph, .pw, .sh, .td, .tk, .tm and .ws

Including .com, .net and .museum this makes 15 TLDs.

The search was done using this very clumsy one-liner:
for b1 in a b c d e f g h i j k l m n o p q r s t u v w x y z ; do for b2 in a b c d e f g h i j k l m n o p q r s t u v w x y z ; do host asqerdfqewrd.$b1$b2 >> dom.txt.slet; done; done

(I wonder if there is a character equivalent for 'seq 1-27'.)

Implementation Changes...

[pabl0]

This appeared on the NANOG list about an hour ago. Seems they are at least addressing some of the problems that this has caused with mail services. Please don't go flaming this person's e-mail address. Consensus on list is that he's a "good guy making the best of a bad situation".

Unfortunately, despite the fact that they say they aren't collecting e-mail addresses, for the community at large the issue is we now have to trust them to continue to honor that promise. Considering their actions in implementing SiteFinder in a most irresponsible fashion, I'm not sure that trust would be well placed.

Date: Sat, 20 Sep 2003 14:01:39 -0400
From: Matt Larson
To: nanog@nanog.org
Subject: VeriSign SMTP reject server updated

Folks,

One piece of feedback we received multiple times after the addition of
the wildcard A record to the .com/.net zones concerned snubby, our
SMTP mail rejection server. This server was designed to be the most
modest of SMTP implementations and supported only the most common
sequence of SMTP commands.

In response to this feedback, we have deployed an alternate SMTP
implementation using Postfix that should address many of the concerns
we've heard. Like snubby, this server rejects any mail sent to it (by
returning 550 in response to any number of RCPT TO commands).

We would like to state for the record that the only purpose of this
server is to reject mail immediately to avoid its remaining in MTA
queues throughout the Internet. We are specifically not retaining,
nor do we have any intention to retain, any email addresses from these
SMTP transactions. In fact, to achieve sufficient performance, all
logging has been disabled.

We are interested in feedback on the best way within the SMTP protocol
to definitively reject mail at these servers. One alternate option we
are considering is rejecting the SMTP transaction by returning a 554
response code as described in Section 3.1 of RFC 2821. Our concern is
if this response effectively causes most SMTP servers to bounce the
message, which is the desired reaction. We are researching common
SMTP servers' handling of this response code; at least one popular
server appears to requeue mail after receiving 554. Another option is
remaining with the more standard SMTP sequence (returning 250 in
response to HELO/EHLO), but then returning 550 in response to MAIL
FROM as well as RCPT TO.

I would welcome feedback on these options sent to me privately or the
list; I will summarize the former.

Matt

Are we having fun yet?