Closed Bug 219464 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: bugzilla, Assigned: darin.moz)

References

()

Details

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."
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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.
WONTFIX
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
*** Bug 219528 has been marked as a duplicate of this bug. ***
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.
The workarround for this does not belong in Mozilla.
Status: RESOLVED → VERIFIED
*** Bug 219687 has been marked as a duplicate of this bug. ***
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.
*** Bug 220104 has been marked as a duplicate of this bug. ***
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)
Summary: NXDOMAIN is no longer returned for nonexistent .com and .net domains → NXDOMAIN is no longer returned for nonexistent .com and .net domains (Verisign DNS wildcard)
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 ...
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.
Summary: NXDOMAIN is no longer returned for nonexistent .com and .net domains (Verisign DNS wildcard) → DNS: Verisgn Site Minder (NXDOMAIN is no longer returned for nonexistent .com and .net)
Blocks: 220409
Blocks: 219150
No longer blocks: 219150
FYI, Verisign has sued ICANN. If they win the lawsuit and deploy Site Finder, I will reopen.
Summary: DNS: Verisgn Site Minder (NXDOMAIN is no longer returned for nonexistent .com and .net) → DNS: Verisgn Site Finder (NXDOMAIN is no longer returned for nonexistent .com and .net)
You need to log in before you can comment on or make changes to this bug.