Resolving Everything: VeriSign Adds Wildcards

DragonHawk writes "As of a little while ago (it is around 7:45 PM US Eastern on Mon 15 Sep 2003 as I write this), VeriSign added a wildcard A record to the .COM and .NET TLD DNS zones. The IP address returned is 64.94.110.11, which reverses to sitefinder.verisign.com. What that means in plain English is that most mis-typed domain names that would formerly have resulted in a helpful error message now results in a VeriSign advertising opportunity. For example, if my domain name was 'somecompany.com,' and somebody typed 'soemcompany.com' by mistake, they would get VeriSign's advertising." Read on below for some more information.

"(VeriSign is a company which purchased Network Solutions, another company which was given the task by the US government of running the .COM and .NET top-level domains (TLDs). VeriSign has been exploiting the Internet's DNS infrastructure ever since.)

This will have the immediate effect of making network trouble-shooting much more difficult. Before, a mis-typed domain name in an email address, web browser, or other network configuration item would result in an obvious error message. You might not have known what to do about it, but at least you knew something was wrong. Now, though, you will have to guess. Every time.

Some have pointed out that this will make an important anti-spam check impossible. A common anti-spam measure is to check and make sure the domain name of the sender really exists. (While this is easy to force, every little bit helps.) Since all .COM and .NET domain names now exist, that anti-spam check is useless.

VeriSign has published white papers about their implementation and also made some recommendations."

Re:wonder of wonders

[pbox]

You at least have an option of turning off this "helpful" page in IE. No such feature from NSI.

Agreement by typo.

[Lux]

This is hillarious!! They have a TOS!

By making a typo, you supposedly agree that if their site overflows a buffer in your browser and wipes your HD, they are not liable.

Okay, terrible example for many reasons, but I still think it's pretty laughable that they claim that the "user" agrees to certain terms of service by "utilizing" this little piece of indirection.

-Lux

Re:Verisign just DDOSed itself

[dzym]

That's not really true. The daemon that runs on the SMTP port of the server with the IP(s?) in question will automatically close the connection once the DATA directive is issued by the client making the connection.

Re:This is a bitch

[SSpade]

Those spam-catching tools work by doing a reverse-dns lookup of the IP address that is trying to send the mail. This is different than doing a "forward"-dns lookup.

Not so.

A common spam filtering method is to check the envelope sender to see if the domain exists. Any mail that is sent with a faked envelope sender to which bounces can't be sent is spam.

That means querying for either an MX record or A record for that domain, and bouncing all the spam that doesn't have either. Now, thanks to verisign, all spam sent with forged envelope senders in .com or .net wil go straight through this spam filter, increasing the amount of spam in many peoples mailboxes.

Yes, in theory you could look for the magic A record returned, but to do so is something of an operational nightmare, and impossible to do with most current MTAs.

Re:Which domains?

[mcpkaaos]

The update was performed a short while ago and will take some time to propagate. DNS updates aren't immediate.

30% chance of failure

[MavEtJu]

With DNS tracer [mavetju.org], you can see how much damage they do:

[~] edwin@k7>dnstracer -s . -o blaat.burps.ploeps.thisdomaindoesnotexistabcdef.co m
Tracing to blaat.burps.ploeps.thisdomaindoesnotexistabcdef.co m via A.ROOT-SERVERS.NET, timeout 15 seconds
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ M.GTLD-SERVERS.NET [com] (192.55.83.30)
|\___ E.GTLD-SERVERS.NET [com] (192.12.94.30)
|\___ K.GTLD-SERVERS.NET [com] (192.52.178.30)
|\___ J.GTLD-SERVERS.NET [com] (192.48.79.30)
|\___ F.GTLD-SERVERS.NET [com] (192.35.51.30)
|\___ L.GTLD-SERVERS.NET [com] (192.41.162.30)
|\___ D.GTLD-SERVERS.NET [com] (192.31.80.30) Got authoritative answer
|\___ B.GTLD-SERVERS.NET [com] (192.33.14.30) Got authoritative answer
|\___ I.GTLD-SERVERS.NET [com] (192.43.172.30)
|\___ C.GTLD-SERVERS.NET [com] (192.26.92.30) Got authoritative answer
|\___ H.GTLD-SERVERS.NET [com] (192.54.112.30)
|\___ G.GTLD-SERVERS.NET [com] (192.42.93.30)
\___ A.GTLD-SERVERS.NET [com] (192.5.6.30) Got authoritative answer


Personal opinion: stupid idiots who wrongly mix political goals with technical capabilities. Just because we can doesn't mean we should.

Re:wonder of wonders

[StewedSquirrel]

Sure you do, if you have a REAL router (or a DSL router even) you should be able to null-route that IP. Or actually, you might even be able to convince your ISP to do it with a short, friendly letter to the admin.

Stewey

Send your queries to the GTLD servers direct

[DragonHawk]

Okay, everybody and their brother is trying to resolve "bogusdomainname.com" or whatever and finding they get a NXDOMAIN error (as they should). There are a lot of possible reasons for this, which I will simply handwave as "caching".

To see the real thing in action, query an authoritative nameserver directly. For example:


$ host www.bogusdomainname.com
Host www.bogusdomainname.com not found: 3(NXDOMAIN)
$ host www.bogusdomainname.com a.gtld-servers.net
Using domain server:
Name: a.gtld-servers.net
Address: 192.5.6.30#53
Aliases:

www.bogusdomainname.com has address 64.94.110.11
$


The first query uses the default resolver on my system, which is a local named which in turn forwards to my ISP's resolvers, which do who knows what. The second query says to ask a.gtld-servers.net, which causes the host utility to send the query directly to one of the authoritative nameservers for the GTLDs (Global Top Level Domains, as opposed to country-specific domains like .us). Then I see the current authoritative response.

They at least gave us warning

[jdc180]

This isn't something new, they told us it was coming. [slashdot.org] What a crock of shit. I think this shows that there needs to be some sort of accountability in this business.

Re:Which domains?

[D. J. Bernstein]

Requests for unknown .com names are handled by VeriSign's thirteen .com servers. As of 2003.09.16 01:35 UTC, the wildcard is on only four of those servers. So you may or may not see it; there's no guarantee that your ISP's DNS cache will contact a particular server.

Presumably VeriSign will copy the wildcard to the other servers at some point. I wouldn't be surprised if they're ramping up slowly, monitoring the load as they expand the wildcard coverage.

Re:Which domains?

[Nucleon500]

I'm still getting NXDOMAIN for any misspelled .com sites. I assume this is because it takes a while to propagate?

Oh common, the workaround is so obvious...

[TyrranzzX]

Simply block all traffic to 64.94.110.11 and give verisign your hate mail as well. It'll still return the error message whenever that address is found, so even if it is hosted, it's as good as not registered.

This a stupid stupid stupid move by them, Akin to shooting themselves in the foot with a 45 caliber pistol; it's going to anger a lot of people in the IT industry.

Make sure you let Scott and Matt know ....

[jea6]

You may want to let Scott Hollenbeck ([e-mail] [mailto]) and Matt Larson ([e-mail] [mailto]) from VeriSign's Naming and Directory Services know what you think of their Best Practices [verisign.com].

And while you are at it, you may consider a friendly note for W.G. Champion Mitchell ([e-mail]) [mailto], President, NetSol and Stratton Sclavos ([e-mail]) [mailto], Chairman and CEO, VeriSign.

mail will still return 550 errors...

[mhawk13]

"the site finder response server runs a limited smtp server that returns an smtp 550 error response for any specified destination..."

different protocols will be treated differently

Complain to ICANN *NOW*

[Teflon]

In order to get this rather unwelcome act of Verisign's reversed, EVERYONE should contact ICANN immediately.

[e-mail]

MSN search hasn't changed.

[ogre2112]

The contents of the address bar are only processed by MSN's built in search form if you don't add the TLD.

'slashhhdot' - would bring up MSN's search.

'www.slashhhdot.com' - would bring a 404 (or now, Verisign's site-finder)

After this change by Verisign, MSN's search operates 100% the same. At least, on my IE6 SP1 with no customizations.

Re:I can't confirm this is true....

[pirodude]

Well wait for it to propigate, everyone on NANOG (who I hope would be able to confirm this) has said it's true. Verisign also posted this:

Today VeriSign is adding a wildcard A record to the .com and .net
zones. The wildcard record in the .net zone was activated from
10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is
being added now. We have prepared a white paper describing VeriSign's
wildcard implementation, which is available here:

http://www.verisign.com/resources/gd/sitefinder/ im plementation.pdf

By way of background, over the course of last year, VeriSign has been
engaged in various aspects of web navigation work and study. These
activities were prompted by analysis of the IAB's recommendations
regarding IDN navigation and discussions within the Council of
European National Top-Level Domain Registries (CENTR) prompted by DNS
wildcard testing in the .biz and .us top-level domains. Understanding
that some registries have already implemented wildcards and that
others may in the future, we believe that it would be helpful to have
a set of guidelines for registries and would like to make them
publicly available for that purpose. Accordingly, we drafted a white
paper describing guidelines for the use of DNS wildcards in top-level
domain zones. This document, which may be of interest to the NANOG
community, is available here:

http://www.verisign.com/resources/gd/sitefinder/ be stpractices.pdf

Matt
--
Matt Larson
VeriSign Naming and Directory Services

Re:Verisign would look nice in gasoline and flame

[ccady]

It looks like they added only an "A" record -- records which denote web addresses, not mail "MX" addresses, thus they will not be receiving bounced e-mail.

Yet.

Re:This is a bitch

[77Punker]

Add to /etc/hosts.deny 64.94.110.11 Problem solved.

Illegal?

[__aagmrb7289]

Well, I've read a lot of posts that say this should/is illegal. Fine, let's go for it - everyone needs to contact the Better Business Bureau [bbb.org] and their local congressmen/women (here is contact info for Oregon [aidsstories.com]; Washington [aidsstories.com], etc. - use your brain, you'll figure it out), and get some movement on this. Don't just sit there and make angry comments! Do it...

Changed Already?

[hutman]

I tried a few domains and got the Verisign page, but now the 'feature' seems to be missing. Did they backtrack already?

Re:I think Verisign now owes...

[signe]

VeriSign *is* InterNIC.

Network Solutions "bought" InterNIC way back when. VeriSign bought Network Solutions. Now Network Solutions sells domains as a registrar, and VeriSign (VeriSign Naming and Directory Services, specifically) is the registry. Every registrar, including Network Solutions, pays VNDS $6 per year per domain. VNDS doesn't pay anyone anything.

It's VNDS that is doing the wildcard entry.

-Todd

They've been waiting for a critical mass

[jamezilla]

From the bestpractices whitepaper [verisign.com]:

Several TLD administrators* already support wildcard functionality in their zones, demonstraiting that the concept works in practice. The applications provided by these administrators to support wildcard functionality vary, but in all cases the administrators provide a web page to inform the human web users that they have reached a destination as a result of attempting to resolve a non-existent domain name. In most cases, the web page informs the user that the domain is available for registration. In one case the web page helps the user find web sites associated with delegated subdomains.

*The zones for .cc, .cx, .io, .mp, .museum, .nu, .ph, .td, .tk, .tv, and .ws support wildcard functionality.

They've been watching others do this for a long time... just waiting for a critical mass so they can point to everyone else and say, "They're all doing it, why can't I?"

Other articles about this

[Nucleon500]

This seems to be the first test, but there was some speculation that they'd do this beforehand. Check out these, c/o Google News:

Inventor Says Search Service Won't Break DNS [cbronline.com]

VeriSign Looks At Earning Money on Domain Typos [slashdot.org]

VeriSign Mulls Way to Make Money from Typos [cbronline.com]

Re:Strike Back with Poor Typing

[Electrum]

Even better, you can send mails with 10MB attachements to people you don't know at random internet addresses ending with .com, they'll love it...

Wrong. Their SMTP server rejects all DATA commands with a 550:

$ nc 64.94.110.11 25
220 snubby1-wceast Snubby Mail Rejector Daemon v1.3 ready
MAIL FROM: <>
250 OK
RCPT TO: <[e-mail]>
250 OK
DATA
550 User domain does not exist.

Re:patches?

[ncc74656]

I wonder how long it will be before there are patches for BIND/dnscache/etc...

Someone's already asked [google.com] WRT BIND. I would be more interested in a fix for djbdns [cr.yp.to], though.

Re:Verisign would look nice in gasoline and flame

[Asgard]

In the absense of a MX record for a given domain, the MTA will attempt to go to the A-record for the domain.

Already discussed on the ICANN/GNSO mailing list

[next_permutation]

This is discussed on the ICANN/GNSO mailing list [icann.org]. A vote saying

gTLD Registry operators WILL return NXDOMAIN for ALL DNS queries for which there is not a REGISTERED domain name.

has been suggested. Sure seems like a good idea to me.

Re: Re:Verisign would look nice in gasoline and

[Anonymous Coward]

MX or not, most mail systems will attempt to deliver to the primary A record if no MX is present.

Site Finder Developer's Guide available...

[Etcetera]

Available here [verisign.com]

How nice of them to let us know...

Re:Changed Already?

[Anonymous Coward]

.com doesn't, .net still does for me.

glad I moved all my domains off NSI a long time ago.

Re:Contact ICANN [e-mail]

[chuckk]

Also, contact the operators of the root nameservers B-M.

No direct contact addresses, but hostmaster@domain for these is a good start, but a list of CIOs (ot the equiv) for these orgs would be more apppropriate...
http://www.icann.org/committees/d ns-root/y2k-state ment.htm
The root nameservers are operated by all these different entities for the precise reason of preventing this sort of shennanigans. John Postel saw this coming.

Re:Mail trap

[alexburke]

Amusingly enough, their mail rejection system seems broken. The first RCPT command fails, as it presumably should since the purpose of this "service" is to bounce mail sent to nonexistent domains, however subsequent RCPT commands succeed. Thereafter, the DATA command returns a 2xx condition and closes the socket.

Shouldn't that be a 5xx condition returned, to cause the MTA to bounce the message immediately rather than keep trying (as is the case for 2xx and 4xx conditions)?

[alex@penguin alex]$ telnet 098237498273649287364.com 25
Trying 64.94.110.11...
Connected to 098237498273649287364.com.
Escape character is '^]'.
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
HELO
250 OK
MAIL FROM:[e-mail]
250 OK
RCPT TO:[e-mail]
550 User domain does not exist.
RCPT TO:[e-mail]
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

Re:wonder of wonders

[BJH]

Perfect! [verisign.com]

Re:network operators are pissed at this

[piyamaradus]

Null routing this address makes your problems worse, unless you also rewrite/fix the DNS lookups. Why? Because, again, of the email -- if that IP gets null-routed, all email to non-existent domains ends up QUEUED (after a nice timeout) and retried and retried and eventually bounced, 1-3-5 days later. Horrible customer experience -- you mistype a domain and don't know about it until the retry time on your SMTP relay expires. Plus, the ISP relay queues go through the roof.

Now, any good ISP wiz will be doing what my folks are doing right now and rewriting their SMTP servers to handle this address as a special case, and to watch for address changes. But even if you do that for your mail servers, if you run a network, you have to worry about all those people with their own mail servers on your backbone, and their little admins probably aren't rewriting Exchange...

Here is a form letter for everybody:

[techstar25]

I used VeriSign added a wildcard A record to the .COM and .NET TLD DNS zones as the subject of the email. You could use something more original if you want.


To whom it may concern,
Verisign is commiting a major injustice that cannot be allowed to continue. It is important ICANN consider what is best for the internet community as a whole and take proper action. Proper action would be to immediately stop this monopolistic behavior from Verisign.

Please read below for more information taken from Slashdot.org:

As of a little while ago (it is around 7:45 PM US Eastern on Mon 15 Sep 2003 as I write this), VeriSign added a wildcard A record to the .COM and .NET TLD DNS zones. The IP address returned is 64.94.110.11, which reverses to sitefinder.verisign.com. What that means in plain English is that most mis-typed domain names that would formerly have resulted in a helpful error message now results in a VeriSign advertising opportunity. For example, if my domain name was 'somecompany.com,' and somebody typed 'soemcompany.com' by mistake, they would get VeriSign's advertising.

This will have the immediate effect of making network trouble-shooting much more difficult. Before, a mis-typed domain name in an email address, web browser, or other network configuration item would result in an obvious error message. You might not have known what to do about it, but at least you knew something was wrong. Now, though, you will have to guess. Every time.

Some have pointed out that this will make an important anti-spam check impossible. A common anti-spam measure is to check and make sure the domain name of the sender really exists. (While this is easy to force, every little bit helps.) Since all .COM and .NET domain names now exist, that anti-spam check is useless.

The internet belongs to everyone. It is not something that can be bought and sold by any one entity. Please put a stop to this behavior.

Thank you.
---insert name here---
---insert city and state of residence here---

The damage is already beginning

[Huusker]

This is so amazingly reckless and damaging that I don't know where to begin.

A few hours ago I was trying to troubleshoot a lame delegation to another zone. It seemed to be working which puzzled me to no end. It turns out the lame DNS server was returning 64.94.110.11.

Lame delegation is a very common phenomenon and (in the case of a typo) can often be diagnosed with NXDOMAIN being returned for the glue RR record. Never returning NXDOMAIN means that many types of lame delegation will no longer be caught.

One of my peer zones had a typo'ed MX record. Before VeriSign's sabotage (yes, sabotage) the lookup of the corresponding address record would simply fail with NXDOMAIN. The source MTA would then try to deliver to the secondary MTAs on the list of MX records in order of priority. Mail delivery would proceed normally using the secondary MTA(s).

However to my complete and utter astonishment, 64.94.110.11 has a working MTA listening on port 25 (why???). This means that any MX records with typos in the primary record will have all their e-mail redirected to VeriSign's MTA. Mail that would normally automatically be re-routed to the secondary MTA instead now gets bounced by Verisign's ''Snubby Mail Rejector Daemon v1.3''. Not returning NXDOMAIN will break mail delivery to secondary MTAs.

And what about spam filters? It will break any spam filter that tries to verify that the source MTA hostname claimed in the HELO request is resolvable (i.e. that the claimed HELO name is not fictious).

I could probably list another half dozen problems if I thought about it. I can't believe the arrogance (read: stupidity) of this act.

I can't wait to see reaction reaction from the backbone cabal on NANOG.

Waste of time

[Adam9]

As another person mentioned this already, e-mailing them is a waste of time unless you're a corporation with extra cash.

How do you fix this problem? DON'T USE THE ICANN ROOT SERVERS. Easy as that.

Plug: OpenNIC (for ICANN users) [unrated.net] and OpenNIC (for OpenNIC (and its peers) users) [opennic.glue]

Re:Complain to Verisign as well

[enosys]

If you have the time call them to complain:

Domain Names & Related Services
U.S. & Canada: 888-642-9675

Also check their contact info [verisign.com]

I'm not sure if they care about complaints about this but they might care about the other effects of the quantity of complaints.

Re:Already taken down??

[DDumitru]

Only 4 of the root servers have the wildcard in place. Thus there is a bit of randomness in whether you hit it or not.

If you have a Linux box, you can see this with:

host verisigniscrooked.com a.gtld-servers.net ...
host verisigniscrooked.com i.gtld-servers.net

I think we should all call tech support on their 800 number and complain.

U.S. and Canada: 888-642-9675
Worldwide: 1-703-742-0914

Lets see if we can get their hold queue time to several hours. Perhaps even ask to speak to a supervisor. Be sure to get names of everyone you talk to. Ask for names and phone number of the corporate officers. Compare them to SCO (ok, a bit off topic but I couldn't resist).

BIND Blocking Configuration

[Anonymous Coward]

If you run a nameserver and want to return NXDOMAIN instead of Verisign's IP, add this code to your named.conf if you are running BIND 9.2.2

zone "11.110.94.64.in-addr.arpa" { type master; allow-query { none; }; };

If you are running a version below 9.2.2 create a generic zonefile with contents such as

$TTL 288000 @ IN SOA localhost. root.localhost. 1 7200 3600 604800 600

and use this line in named.conf instead

zone "11.110.94.64.in-addr.arpa" { type master; file "generic.zone"; allow-query { none; }; };

Not every root nameserver is serving the A record

[ziegast]

At my last check, only the "a", "c", and "d" COM servers are serving the global A record for *.COM.

I am removing those broken nameservers from my root zone hints at all of the places that I administer. Hopefully enough root servers will remain clean of this aborration to keep up a good level of service.

I encourage others everywhere to do the same and ask their ISPs follow suit. If you don't play fairly with the public trust, the public should stop trusting you.

If Verisign can hijack *.COM and *.NET, what is to keep resolving ISPs from hijacking unused domains at the resolver level to suit their own purposes?

Where was the RFC on this practice? It would never have passed peer review.

--
Eric Ziegast
Former TLD administrator.
Former hostmaster at a major ISP.

PLEASE DO NOT CLICK ON ANY SEARCH ENGINE RESULTS

[ddent]

Hi All,

Took a look at their setup, and from what I can see, they have partnered with Overture to get their search results. Overture is a pay per click search engine, meaning advertisers bid to get to the top of the search results - anywhere from $0.10 to $50. Most arrangements involve Overture getting half of the the bid, and VeriSign getting the other half.

What this means is that they are making money (probably hundreds of thousands if not millions daily) from most of the searches you make.

Topics which attract high bids (up to $50 per click, it is shocking) include online casinos, dedicated servers, refinancing, and a few others.

I implore you all:

If you want this to stop, please do not click on any of the search results from this 'search engine'. Doing so will contribute to the profit VeriSign will make from this. If you really really want to click on one of the listings plase go to www.overture.com and get it directly from them.

Other things we can do include:

1) Putting them on the spam RBLs for spamming the entire internet. This will have the effect of blackholing them from some parts of the internet that drop packets based on those RBLs right at the router level.

2) Encourage your vendors to modify their DNS server packages to change results for that IP to NXDOMAIN.

3) Encourage your admins to run such modified DNS servers.

Re:Waste of time

[silentbozo]

Thanks for the link. I'm sending an e-mail to Speakeasy to suggest that they switch over. I'll also talk to a few of the network gurus at work and see if we can come to a consensus as to what to do about VeriSign's sabotage.

Definitely, I'm setting up a local DNS at home and have it talk to the OpenNIC root until Speakeasy gets an OpenNIC box up and running.

In the meantime, 64.94.110.11 is blocked on my NAT - it takes a hell of a long time to time out, but it does the trick for now.

It's in the ccTLDs too, sadly

[marnanel]

On a global scale, it's not so recent, and it's not just Verisign. A bunch of the ccTLDs have been indulging in this unpleasant behaviour for a while: .ac [woijgworgwri.ac], .cc [woijgworgwri.cc], .cx [woijgworgwri.cx], .mp [woijgworgwri.mp], .nu [woijgworgwri.nu], .ph [woijgworgwri.ph], .pw [woijgworgwri.pw], .sh [woijgworgwri.sh], .td [woijgworgwri.td], .tk [woijgworgwri.tk], .tm [woijgworgwri.tm], and .ws [woijgworgwri.ws] (of course, some of those are run by the same registrar as one another). I was shocked when I first saw this, but I never thought the rot would spread into .com and .net. :/

Re:Renegade DNS

[WhiteWolf666]

Nothing.

OpenNIC does exactly that.

OpenNIC [unrated.net]

Verisign has continued to be the #1 DNS provider (monopoly root control over the internet, supposedly) through intertia.

Not that I don't hate the bastards, given their effective monopoly.

My only point is that very little has to change to eliminate them.

Rejector isn't even parsing

[DeathB]

I've seen several people now post sessions they've had with "Snubby". Snubby is assuming that people are ordering things in a specific order. A session I just had with it:

telnet 64.94.110.11 25
Trying 64.94.110.11...
Connected to 64.94.110.11.
Escape character is '^]'.
220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready

250 OK

250 OK

550 User domain does not exist.

250 OK

221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

That's right. It doesn't parse the input at all (I just hit Enter a bunch of times). If you have multiple RCPT lines, or have an extra command in there anywhere, you will get an OK in the wrong place and it will look like you have succeeded.

Adam

they're only running smtp and http

[Jerf]

They aren't. "Filtered" means the packet sent to that port simply disappeared, without even a error packet coming back to indicate the failure. In other words, indistinguishable from "There is no machine at all receiving the packet". Here's how to use nmap [insecure.org], see the third paragraph.

The server is only running smtp and http, and theoretically it could be running services on the tens of thousands of other ports you didn't scan, but it almost certainly isn't.

Those filtered ports are why the nmap scan took 24.611 seconds; system without filtered ports will go faster then that under normal circumstances.

Patch to djbdns

[Russ Nelson]

Here's a patch to djbdns which lets you ignore certain A records in responses. If you're not already using djbdns, you should.

http://tinydns.org/djbdns-1.05-ignoreip.patch

Re:Which domains?

[Russ Nelson]

It is propagating, as .com and .net servers are reloaded.
-russ

NANOG threads on this topic

[PghFox]

The North American Network Operators' Group [nanog.org] has two ongoing threads ('What *are* they smoking' [merit.edu] and 'Change to .com/.net behavior' [merit.edu]) with further discussion on this topic.

An exploit

[Anonymous Coward]

This will make you search google for your cookie. [verisign.com] You can modify it to do whatever you want.

Re:wonder of wonders

[CaptainSuperBoy]

No, that won't work at all.

First, Verisign put an exclude: / in their robots.txt.

Second, do you really think Google doesn't know how to handle wildcards by now? Think about it for a second. Even Slashdot has a wildcard - anything dot slashdot.org goes to the homepage. Does Google index Slashdot an infinite amount of times? Of course not. Why should it be different for anything dot com?

Physical Location of Verisign Offices

[CaptainCarrot]

From the website:

VeriSign Worldwide Headquarters
487 East Middlefield Road
Mountain View, CA 94043
Phone: [phone]
FAX: [phone]

Have fun!

Re:Rejector *IS* parsing

[Anonymous Coward]

220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
puto
250 OK
laputamadre
250 OK

laconchadelalora

550 User domain does not exist. -- Whoa! it wants a real domain name huh?

[e-mail]
250 OK

It gets worse

[Anonymous Coward]

Actually it is not a working MTA. It just prints a series of static messages. If you don't do things in the right order you may not even get a bounce out of it.

Here's a neat idea:

[pipeb0mb]

A fellow SA Goon (thatdog), pointed this out, and it could perhaps be a nice fun tool to screw with them...I'll quote his post over there:

thatdog said:
The most amusing part of this to me is they take whatever is passed in the url parameter and shove it into the html of their page, no questions asked. Remote scripting exploits will be ever so easy!

If you don't get what I'm talking about, just check out this link [verisign.com].

Would be fun to see redirects on major isps and backbones...or even forwarding to an alternate site hosted elsewhere with an explanation.

Re:Strike Back with Poor Typing

[idiot900]

No need to use a DATA command. Just send crap to the rejector even if it is expecting a command.

So, one could theoretically spam them like so:

while [ 1 ]; do cat /dev/zero | telnet 64.94.110.11 25; done

Of course I am not advocating that anyone do this. Especially anyone with scads of bandwidth. That would be terrible. Oh, the humanity.

Re:wonder of wonders

[vrmlguy]

It's a single record for verisign, but there's no difference in the DNS response record. This means that a caching DNS has to keep every record that it gets back. This means that you could overload Google, but verisign would be unlikely to be affected.

And you can't ignore domains that resolve to identical addresses. Virtual web servers share the same address with different domain names. The web server uses the name to decide which set of web pages to serve up.

A quick post on the damage caused by this action..

[Anonymous Coward]

Check out http://www.haque.net/verisign_dns_rant.php [haque.net] for some more information on how this is damaging to the rest of the net (as well as to your own privacy)

-- a concerned netizen

Re:Do not leave it is not real.

[Anonymous Coward]

You're right... port designations aren't sent with DNS queries. randomdomainthatdoesntexist.com:69 resolves, but does not display because there is no Web server on port 69. Therefore, your entire post is moot.

ICANN said no....

[chipster]

...back in January, as you will read here:

<http://www.icann.org/correspondence/iab-message-t o-lynn-25jan03.htm> [icann.org]

What happened? I STRONGLY URGE that complaints be made to ICANN and the US DoC...right now.

This is so much worse than many folks think.

Re:attn: BIND/djbdns/whatever wizards

[Anonymous Coward]

From previous postings:

Preliminary BIND8 patch:

http://achurch.org/bind-verisign-patch.html

Patch to Dan Bernsteins DJBDNS:

http://tinydns.org/djbdns-1.05-ignoreip.patch

libverisignfix.c

[Dwonis]

Try libverisignfix.c [slashdot.org]. It's an LD_PRELOAD hack to intercept gethostbyname, gethostbyname_r, and gethostbyname2_r. It doesn't intercept anything else (like getaddrinfo), but it works in Mozilla.

Re:Waste of time

[Adam9]

If your ISP won't switch over or you don't want to run your own nameserver.. there is a list [unrated.net] of publicly available tier 2 servers that you can switch to that are offered by OpenNIC members.

Re:Security Geniuses

[Anonymous Coward]

Have fun! [verisign.com]

Re:actually the sitefinder page is kinda useful.

[MidKnight]

Troll? Or just naive? I'll bite.... Some questions:

• Did you notice that, by mis-typing some URL, you implicitly agreed with their Terms of Service [verisign.com] agreement?
  
• How long would you trust a fine, upstanding monopoly company like Verisign to continue to provide this useful service pro bono? Did you read that TOS after all? Notice where they explicitly state "The information ... may be supplied by VeriSign's commericial licensors, advertisers or others" Hmm... what *could* they possibly be planning here?
  
• Would you mind if every domain-spoofing spam email that you bounced from your email went directly to Verisign, who would be free to do with it what they wish? Legally, you would have just sent them an email, and they'd be more than happy to harvest as much info from it as possible. And, by the way, Verisign has plenty of experience [cnet.com] selling people's personal data for profit.
  
• How is the end result any different from the recent cases of "typo-squatting" [wired.com] that have been found illegal in various courts?
  

Look -- the root name servers are at the absolute core of the usefulness of the Internet. Using a hey just hijacked every non-existent URL on the planet & pointed it directly at their own money-making, pay-per-click-thru search engine. For crissake man, are you paying attention here?

--Mid

Re:Waste of time

[jerde]

would sticking that IP in our hosts file work?

Nope. Hosts files map name->IP, not vice versa.

No, the only way to truly counteract this would be to get your local caching DNS server to intercept these bogus replies and replace them with the nonexistent-domain error.

- Peter

Complaint Form ICANN

[Anonymous Coward]

The ICANN website [icann.org] has an online complaint form [internic.net].

To quote from the site in question:

Although ICANN's limited technical mission does not include resolving individual customer-service complaints, ICANN does monitor such complaints to discern trends.

Let your voices be heard!

Re:OpenNIC anyone?

[Anonymous Coward]

Unfortunately, OpenNIC cannot actually mirror .com and .net, since Verisign won't release the zone files themselves. The best we can do is see that the part of the namespace we run ourselves (opennic.glue, .null, .geek, .indy and .parody so far) are run as we think they should be. The queries for the stuff Verisign operates we can only pass off to their servers.

This _does_ mean, however, that our servers will return a "no such domain" error correctly on non-exixtent .null (for example) domains, but we can't do that on .net without breaking it completely for our users. (In theory, we could actually run a query ourselves and, if it comes up as Verisigns hijacker IP we could return NXDOMAIN but since this is quite a new problem we haven't had time to look into how difficult that would be.)

-robin

done!

[js7a]

I would be more interested in a fix for djbdns

done: [icann.org] the patch is here [tinydns.org]

Patch available for djbdns

[chrysalis]

A patch against this is available for djbdns.

It gives the server a new feature to answer that a
host is nonexistent if it actually resolves to certain IP address.

It was specifically designed for Verisign :)

It works extremely well and brings back the DNS caching the way it was working until the Verisign change.

Get it here :

http://tinydns.org/djbdns-1.05-ignoreip.patch

Or if you want a pre-patched djbdns including this patch and other recommended patches (like the Linux glibc patch and other patches that don't break the stability) :

ftp://ftp.fr.pureftpd.org/misc/djbdns-jedi.tar.g z

Re:Contact ICANN [e-mail]

[fwc]

I think you misunderstood my response to the poster.

The poster was suggesting that we email the root nameserver operators and complain. All that is in the root nameservers are NS records for each of the Top Level Domains (.com, .net, .org, .us, etc.), NOT the .com and .net NS records.

As a result, there is absolutely nothing the root nameserver owners (I.E. [a-m].root-servers.net) can do about this wildcard resolution, short of removing .com and .net from the internet which would be worse than the current situation.

The .com and .net zones are on the [a-m].gtld-servers.net servers. These are 100% owned and operated by Verisign/Netsol last time I checked. The wildcard is on the these .com and .net nameservers, and as such, nobody other than Verisign can make any changes to these zones.

Re:wonder of wonders

[ddent]

From VeriSign global registry services... I have access to them - you just need to sign a contract with them. It's not hard.

Google caches IP info a good deal longer than is specified by TTL and such, and a lot of other fancy bandwidth reducing (but frustrating) tricks). Its known by people who pay a lot of attention to google, based on observations. Many people have good reason to pay attention to google - they make their living from the traffic they get from google.

Re:Correction (need resolver workaround)

[ziegast]

A better patch can be found here [tinydns.org].

--
Eric Ziegast

Re:Legal degree from Play Skool?

[Cramer]

Oh, and what happens with that address is unreachable, down, DoSed, or whatever... your mail will sit in the queue for some configured amount of time with zero indication of the user's error.

Remedy:
1) blackhole that IP - PERMANENTLY. (blacklist their entire IP assignement(s))
2) modify bind to return NXDOMAIN for any query containing that IP.
3) make aformenttioned modification a configuration option (list) thus making it easy to adjust when the assh^W^Wthey change the address.
4) add my own choice wildcard entries :-)
5) kill every living thing at Verisign/Network Solutions even remotely involved with this bullshit (as an example to others who have not learned to participate in a civilized society.)

There's a real big difference between me adding *.bar.com and someone adding *.com.. The wildcard record was originally intended to reduce the number of records -- specifically to negate the need for an MX record for every host. And honestly, it's never worked to anyone's satisfaction (e.g. the ability to send email to bob@[censored].bar.com)

Complaint submitted - the text

[mccalli]

This complaint is regarding Verisign's recent decision to claim all non-registered .com and .net domain names for itself. It has done this by inserting a wildcard into the DNS registers, meaning an IP of 64.94.110.11 is returned for any domain name that has not yet been registered. That page is an advert for Verisign's domin registration services This is unfair competition with existing registrars - there is no means for myself, for example, to gain a similar foothold without actually purchasing each and every currently unregistered .com/.net name. It is also a technical breach of trust - the internet is not merely the web, and unknown domains should return errors rather than constantly try to contact Versign advert servers. Non web-based applications, such as ftp clients etc., will now incorrectly log that they have contacted the host you asked for when in fact they should have returned an error 'hostname unknown'. The same for traceroute, ping...any of these will not behave in a manner expected. I would be grateful if you could investigate this matter. Yours, Ian McCall

Email the Department of Commerce

[James_G]

Ultimately, these guys tell ICANN what to do, so it can't hurt to drop them an email too. Their site is here [doc.gov] (I think that's a good page to start with - if someone finds a better one, feel free to reply). I've personally mailed ICANN and also the address listed on this page. If enough people make noise about this (polite noise, I should add), with a bit of luck they'll do something about it.

Re:Already taken down??

[dabadab]

Seems like now all root servers have the wildcards.
It will be interesting to see the EU's response to this mess.

Re:wonder of wonders

[You're All Wrong]

Remember to include document.cookie in the URLs you refresh to, so that you can steal verisign's cookies. Yup, &lt;script&gt; insertion works too...

Alteratives

[imbezol]

1) make your own wildcard in /etc/resolv.conf (this can be done in windows too but I don't know where by memory) seach yourdomain.com then add *.yourdomain.com wildcard to go to your own domain or your own companies main site. 2) block at your firewall under linux: iptables -A INPUT -p tcp -d 64.94.110.11 -m multiport --dports http,https -j DROP 3) redirect to your web site with a message configure your internal website to have a virtual host for http://sitefinder.verisign.com/ and on that page give a notice to the user that the domain they are trying to reach does not exist and explains that verisign's attempt at gross misuse of the power given over the .com and .net TLD's has been blocked (with appropriate links to relevant info) then add the following to your firewall under linux: iptables -t nat -A PREROUTING -d 64.94.110.11 -i $internal_interface -p tcp -m multiport --dports http,https -j DNAT --to-destination $internal_webserver:80 Anyone have any other ideas for this?

Re:wonder of wonders

[bernywork]

You don't seem to understand, by VeriSign doing there there never will be a failure for a mis-typed URL for you to get re-directed to a search page for google.

We lost half a day of email because of this

[Anonymous Coward]

The company where I worked lost half a day's worth of emails over this.

We have several RBL blacklists enabled, and one of them wasn't spelled right. Before, nobody noticed, because even in testing, the RBL check of the non-existing name would return NXDOMAIN and nothing would be blocked.

But after Verisign's change, suddenly the non-existing RBL domain would return IP's for every single RBL lookup. So every email was blocked!

Suddenly all our email was bounced back as being RBL blocked! All because of a typo and Verisign's stupid change.

We lost half a days worth of email until we found out. That translates into lost sales in the hundred thousands.

And if we did it... how many more thousands of typos are out there?

I got yer reference right here

[AkkarAnadyr]

Giving up mods to reply to this, but oh well...

Just googling "bush nuclear "first use" ' brings up all sorts of links - here [nukewatch.com] and here [counterpunch.org] for starters. This shite was on the news for a few instants, among all the other obnoxious noise and probably juxtaposed with unemployment news or the abortion debate. The neocon cabal (tinnc) uses this type of 'shiny thing/booga booga' distraction to great effect lately, coupled with the 'Dopeler effect' - the effect of stupid ideas seeming smarter if they come at you fast.

Thank Heaven that Michael Powell is there to ensure diversity in the horrid liberal media .. :/

Or did you want a reference to the original 'no first use' doctrine? I'm sure many of my fellow Merkins weren't aware of it in the first place!

Change your hosts file

[Tin Foil Hat]

This works. Add an entry to your hosts file:

127.0.0.1 sitefinder.verisign.com

By using your loopback address, you effectively short-circuit their method.

This is, of course, a limited fix. It will not have any effect outside of your machine, so contact ICANN, Verisign, and your ISP and tell them what you think.

But this will at least give you some relief.

Clue-by-four

[David Gerard]

From: Martin A. Brooks
Reply-To: [e-mail]
To: [e-mail]
Subject: [uknot] Cluebyfour verisign HOWTO for the UK
Date: Tue, 16 Sep 2003 11:32:55 +0100

Call 0800-032-2101 and select option 2 for Support.

Explain to the engineer that you have typed in an non-existant domain name and
been directed to their sitefinder service.

Explain that you have read the "Terms of Use" and do not agree to abide by
them.

Explain that, as you don't agree to the ToU, you are explicitly forbidden from
using their service.

Ask them to exclude your IP block from those that will be given the sitefinder
IP rather than NXDOMAIN.

Give them your name, company (if appropriate) and a contact telephone number.

US and Canada: The contact page number is 888-642-9675. Apparently they will also refer you to 866-345-0330 (which isn't listed on that page), but you should of course check the number given on their official contact page and call that first. The postal address is VeriSign, Inc., Attention: Legal Department, 21355 Ridgetop Circle, Dulles, VA 20166, USA.

Re:What I did

[Piquan]

I don't know how to get around the lameness filter. Ironic, isn't it? Anyway, grab it: antisearch 0.1 [shorttermwhat.com]

The Internet Architecture Board responds

[Etcetera]

From: http://www.iab.org/Documents/icann-vgrs-response.h tml [iab.org]

Subject: Re: Request for Advice on VGRS IDN Announcement
To: "M. Stuart Lynn"
Cc: Leslie Daigle ,
Chuck Gomes ,
Brad Verd ,
Masanobu Katoh ,
Steve Crocker ,
Vint Cerf ,
Louis Touton ,
Andrew McLaughlin ,
[e-mail]
Date: Sat, 25 Jan 2003 10:19:37 +1100

Dear Stuart,

Thanks for your message. After reviewing the announcement, examining the behavior of the deployed system, discussing the issue with colleagues external to the IAB, and meeting with VeriSign's technical staff to go over the system's aim and implementation, the IAB has come to the following consensus.

The IAB feels that the system VeriSign had deployed for .com and .net contains significant DNS protocol errors, risks the further development of secure DNS, and confuses the resolution mechanisms of the DNS with application-based search systems. The IAB understands the efforts that VeriSign has made to limit the applicability of this system to queries which would normally not correspond to registered domains, and it recognizes the importance of the distribution of IDN-capable systems to end users. While the IAB agrees with VeriSign that rapid adoption of IDN-capable systems is desirable, the IAB feels that the very limited gain in distribution cannot balance the shortcomings of this deployment strategy.

The IAB has begun the process of shepherding the creation of an Informational RFC on concerns with operational practices with the DNS. We anticipate discussing the issues raised in your notes in more detail as part of that document. Given the scope of the issue, and our desire to ensure that it will have adequate review by the (DNS) operational community, we will be enlisting the help of the broader IETF community through relevant IETF working groups. In advance of that document, we have outlined below the issues with the VeriSign system which led us to the conclusion above.

As a lookup system, the DNS is designed to provide authoritative answers to queries. The DNS protocol specifies behavior for queries whose targets do occur in a zone by describing the data format for the specific resource records and the wire format for the response. The DNS protocol also specifies behavior for queries whose targets do not occur in a zone by describing the wire format for a negative response.

The system deployed for .com and .net does not follow the specification for targets not in a zone. Instead, it examines the target and decides whether to give the specified negative response or a synthesized record based on whether the target contains a code point above 127. This is a violation of the DNS protocol as described in RFC 2308, Section 2.1. While it is possible within the DNS protocol to include wildcard records which cover all queries not otherwise specified by a zone, this is not what VeriSign has done. Negative answers for records which do not contain code points above 127 continue to be sent.

It would, of course, be theoretically possible to add zone entries for all records containing code points above 127. Given that the Verisign system does not recognize "." as a label delimiter for testing these records, the size of the resulting zone is unimaginably large. VeriSign confirms that they are not managing a zone of the size this would imply and is, instead, synthesizing these entries. This implies that the zone as currently served by VeriSign cannot be transferred using either AXFR or file transfers in master file format. Though the choice of who may employ AXFR or file transfer to get copies of a zone is a policy decision, the IAB notes that the current system does

Experimental Postfix patch to do NS and MX lookups

[Hygelac]

Wietse posted an experimental patch [theaimsgroup.com] for Postfix to work around this:

This patch allows you to blacklist sender or recipient addresses
on the basis of their MX (or DNS) server's hostname and IP addresses.
Blocking by DNS server was asked for long ago. I wrote it today
because the same code can also be used to block verisign wild-card
domains.
/etc/postfix/main.cf:
smtpd_mumble_restrictions =
...
check_sender_mx_access hash:/etc/postfix/mx_access
...

/etc/postfix/mx_access:
64.94.110.11 reject verisgn wild-card

Combined with the new CIDR table this also allows you to block
mail from senders whose MX hosts resolve to reserved address
blocks such as 127.0.0.0/8 or 192.168.0.0/16.

This patch was written with yesterday's snapshot. It will also
apply with little trouble to the stable release.

This code is lightly tested. I haven't got the time to put this
into operation here today.

Wietse

Petition

[fiddles2k]

I suggest people have a look at http://www.petitiononline.com/badnsi/petition.html - seems that a few people would like verisign remoived from control of .com and .net