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)
Core
Networking
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."
Comment 1•21 years ago
|
||
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
Comment 2•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Assignee | ||
Comment 5•21 years ago
|
||
WONTFIX
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Comment 6•21 years ago
|
||
*** Bug 219528 has been marked as a duplicate of this bug. ***
Comment 7•21 years ago
|
||
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•21 years ago
|
||
The workarround for this does not belong in Mozilla.
Status: RESOLVED → VERIFIED
Comment 9•21 years ago
|
||
*** Bug 219687 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
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•21 years ago
|
||
*** Bug 220104 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
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)
Updated•21 years ago
|
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)
Comment 13•21 years ago
|
||
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•21 years ago
|
||
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)
Comment 15•21 years ago
|
||
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.
Description
•