219464 - DNS: Verisgn Site Finder (NXDOMAIN is no longer returned for nonexistent .com and .net)

Status: VERIFIED WONTFIX

(Core :: Networking, defect)

Description

[bugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827

Due to a deliberate act by VeriSign, NXDOMAIN is no longer returned by the DNS
for nonexistent .com and .net domains. Instead, an advertising portal is
returned, rather than the alert box. This is potentially misleading to users.

The ISC, IETF, ICANN and NANOG members are all formulating responses to this:
Mozilla should be configurable to block this behavior, and to restore the
original behavior, without waiting for ISPs to implement fixes.

This also has possible consequences for mail delivery, mail filtering and
general DNS, as this is done at the DNS resolution level, not at the protocol level.

Reproducible: Always

Steps to Reproduce:
1. Visit a URL for a nonexistent .com or .net domain


Actual Results:  
A redirect VeriSign advertising portal page such as 
"http://sitefinder.verisign.com/lpc?url=no-such-domain-really.com&host=no-such-domain-really.com"
is displayed

Expected Results:  
Displayed an alert box: 
"xxx.yyy.com could not be found. Please check the name and try again."

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

We should consider an (optional?) feature to recognize DNS responses that point
to sitefinder.verisign.com (or sitefinder-idn.verisign.com, which is supposed to
be the 'official' address) and give the user the classic "unknown domain" error
instead of fetching from verisign.

Details of how to do it are another issue - we'd need to recognize by (ick) IP
address probably.  Sniff the address of sitefinder at startup perhaps and cache it. 

Comment 2

[Boris Zbarsky [:bzbarsky]]

Really, this should just be handled by the DNS resolver.  I've already seen
patches for bind to do this floating about...

In any case, I would give this a few weeks, because chances are verisign will be
beaten into stopping this idiocy.

Comment 3

[Matthias Versen [:Matti]]

This should be fixed on the Network side and not in the client.
There is already a "fixed" bind for this and I think that many ISPs will do
something against this verisign "attack".

It makes no sense to implement a feature in Mozilla that is only needed 2-3 Weeks.

Comment 4

[Nicholas Allen]

This is pointless to do at the application level.  You cannot reliably detect
that you've resolved a wildcard unless you have the original query answer. 
Filtering junk responses is a job for the resolver.

Comment 5

[Darin Fisher]

WONTFIX

Comment 6

[Bill Mason]

*** Bug 219528 has been marked as a duplicate of this bug. ***

Comment 7

[B. Galliart]

VeriSign was "kind" enough to recommend a "fix" at
http://sitefinder.verisign.com/pdf/sitefinderdevguide.pdf

They recommend doing an A record lookup on *.com and *.net, if other lookups
return the same IP address then treat it the same as an NXDOMAIN.  The VeriSign
provided conclusion is that "application developers should consider taking
appropriate corrective actions."

The IAB also has a responce at
http://www.iab.org/Documents/icann-vgrs-response.html
which points out that lookups for NS records still return NXDOMAIN even when
lookups for the A/CNAME produce a Verisign spoofed entry.

I think it will be a long time until Verisign backs down on this change.  It
will also be a while until every flavor of DNS server and/or OS resolver library
include a fix.  The more applications respond to this quickly the less effective
this hijacking is.

Comment 8

[Bradley Baetz (:bbaetz)]

The workarround for this does not belong in Mozilla.

Comment 9

[Matthias Versen [:Matti]]

*** Bug 219687 has been marked as a duplicate of this bug. ***

Comment 10

[benc]

Perhaps this is another case for adding a NULL() or NOOP() function to a PAC
rewrite ("PAC2"). 

People could at least have some configurable mechanism to block this activity.
However, it might create a "cat and mouse" game of Verisign moving the DNS entry
and people constantly having to update their PAC files to "chase" the offending
site.

Comment 11

[Bill Mason]

*** Bug 220104 has been marked as a duplicate of this bug. ***

Comment 12

[Miguel Vargas]

Sure, this doesn't belong in Mozilla, but the DNS wildcard doesn't belong in the
TLDs either.

I think Mozilla would make a big protest statement and would get a lot of news
coverage if it protested Verisign by blocking http://sitefinder.verisign.com at
the application level.  

From the looks of their letter to ICANN,
http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm, it doesn't look
like Verisign is going to back down anytime soon.

mozilla should be one of the leading defenders of an open and
standards-compliant internet.

(P.S. Adding the word "Verisign" to the summary of this bug will prevent dups)

Comment 13

[Jo Hermans]

It's too soon to take a decision. We'll have to wait and see what happens in the
next few weeks. Verisign might back down, they might stay at the current
situation, or they might fight back.

In particular I wouldn't try to redefine PAC's, because it won't always be
64.94.110.11 or sitefinder.verisign.com (after a redirect) that you get back.
The algorithm in comment 7 has the best chance. We should lookup *.com when we
start up, and use those ipaddresses  as an indication for the wildcard domain.
With the 5-fold rise in the traffic that they now have, you can bet on it that
they'll use multiple ipaddresses in the future !

This really belongs in the DNS-servers, but since not every ISP is capably or
willing to replace those, it might still be a good idea to do it in the
application too. But Verisign are idiots, when they think they can force every
application to be changed in this way.

On the other hand, what if Internet Exploder decides too to implement the
algorithm in comment 7 ? Then Verisign would be really f*cked up.

PS: my daytime-company is also waiting to see what happens. Some of our
customers (this includes entire countries) have started to redefine their
routers, or upgrade their DNS-servers. If it continues like this, Verisign will
be a ver lonely place ...

Comment 14

[benc]

I'm linking a couple bugs as depends, so that we have a record of problems this
change created. 

I'm not going to say much else about how I feel about this change, since it has
been switched off, about as silently as it was switched on. 

A long time ago (maybe Navigator 3.0), Netscape had browsers that gave it's own
home page special DNS treatment. I can't find documentation on this, but I
remember reading this. This was before I worked on any networking for Netscape
or AOL, but I'm just hoping we won't go back to a world where everyone is giving
their domains special treatment.

Comment 15

[benc]

FYI, Verisign has sued ICANN. If they win the lawsuit and deploy Site Finder, I
will reopen.