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."

Comments

wonder of wonders

[wherley]

what are the chances - using the
search page that comes up at the
verisign site to search for "register" we find at the top of the
list a link to networksolutions.com (a verisign company). we also
note that searching for the same word at google
does not result in that site being present in at least the first four pages of results.

yeah - thats a real useful search tool verisign has there - thanks so much.

Re:wonder of wonders

[pbox]

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

Re:wonder of wonders

[Anonymous Coward]

It is not that bad. At least if you enter "Verisign sucks big donkey balls", two of the three first results are from Slashdot.

Re:wonder of wonders

[bobthemonkey13]

More fun with sitefinder.verisign.com

Hmm, cross-site scripting. Seems harmless enough, but I wonder if VeriSign stores anything important in the verisign.com cookie...

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

Re:wonder of wonders

[mosch]

Actually, the verisign search seems to be pretty good. A search for FUCK VERISIGN returns a slashdot article about verisign sending out deceptive domain renewal mail as the second result.

Re:wonder of wonders

[BJH]

Perfect!

Re:wonder of wonders

[gantzm]

Speaking of search engines. What would happen if a significant number of web sites put links on every page to a poison page. This poison page would generate 10,000 random links of the form "www.verisignblows948950948393903848585.com", with the number obviously being random. How long would it take for all the search engines and web crawlers to hit this and have a serious impact on verisigns servers?

Now, I'm not suggesting anybody do this, I'm just asking the question.

Re:wonder of wonders

[morganjharvey]

No, the real fun is that if you misspell verisign like this:
http://www.veirsign.com
Looks like someone beat them at their own game. :)

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?

Re:wonder of wonders

[gantzm]

It's not the page content to be concerned about. If google is constantly hitting pages with tens of thousands of these links the DNS servers are going to start having serious cache problems. I'm sure google runs their own dns servers (at least caching servers), this technique would play havoc with that.

I don't see anyway a search engine could prevent this. It has no prior knowledge of the domain in the link until it tries to resolve it.

Re:wonder of wonders

[CaptainSuperBoy]

Do you know how a DNS wildcard works? Apparently not. There is a SINGLE record that resolves all nonexistent .com and .net addresses to Verisign's sitefinder. Although I'm sure Google's massive server farm can handle storing 10,000 addresses it won't even have to. As soon as it sees the domain resolves to the same address it can move on.

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.

Re:wonder of wonders

[User8201]

Also, MS has been doing this in Internet Explorer for some time, so a mistyped URL goes to an "MSN Search" branded page. So, MS will probably try to solve this problem, so they get their brand name awareness campaign back!

(Actually MSN Sucks and no one uses it despite that).

It's interesting, that the VeriSign page has a Terms of Use. I don't think they legally can require me to abide by SHIT if I got their because of a wildcard, e.g. they trapped me into getting there, not because I intended to go there. And a privacy policy? I didn't _intend_ to access their server, so I don't think I have to grant them rights to do whatever the hell they want with my info or whatever, if I don't want to.

Someone should sue them, or something.

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:wonder of wonders

[javilon]

"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."

Indeed. And, if the Mozilla and Konqueror people had balls, they could set up a default option on their browsers so this page is blocked. You could uncheck it, but it should be on by default.

This would be a cool way to protest!

Re:wonder of wonders

[cerberusss]

You bastard. You forgot to mention to put quotes around it. I looked up that sentence at a client and now they want my balls because the first zillion results returned pr0n sites.

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, <script> insertion works too...

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.

joy

[digitalsushi]

this should make troubleshooting dns records as a netadmin much more fun with all those glorious false positives... guess that means i'll have to learn how to spell finally!

But...

[Anonymous Coward]

according to this "soemcompany.com" isn't wrong.

How Long...

[jlaxson]

until we get gator-type forced advertising (not just incidental unrelated ads on the page) whenever you make the slightest domain mistake? I get the feeling this doesn't bode well for the continued freedom of the internet, if one company can unilaterally do something of this magnitude. (But then again, Mr. Bush seems to get along fine.)

Re:How Long...

[dnoyeb]

This happened to my mother just yesterday. She calls me complaining about "my computer has a virus!" I countered that their was no way her computer could know. This went on for a while..

My mother is visually impared. She was trying to go to www.biblegateway.com, but she went to www.gatewaybible.com. sacreligious scum.

It's hard for her to find the stupid MODAL popup windows when she is using a screen magnifier and the whole screen is not even showing...

A DNS error would have been MUCH nicer. She would not have even called me costing my employer productivity. Currently I know somebody is wasting money on those parked domains. This verisign situation is just sad.

How can we undo this?

[Anonymous Coward]

Anyone have any information on whom to contact to put an end to this absurdity?

Re:How can we undo this?

[Anonymous Coward]

Anyone have any information on whom to contact to put an end to this absurdity?

I think you mean Commander Taco. Or were you talking about that dns thing?

Re:How can we undo this?

[pirodude]

ICANN and DoJ

Re:How can we undo this?

[r_weaver]

I checked their site, and found a Domain Names & Related Services contact number (888-642-9675), and gave it a try.

Unfortunately, the rep that answered the phone was unable to help, he said that he works for Network Solutions, and can only help with domain registration issues, and that the Verisign parent company runs the root nameservers. He was unable to give me a contact number for Verisign. However, you may want to try calling this number yourself to see if maybe a different rep has the contact number for Verisign.

I did a whois on the verisign.com domain, and came up with the main contact number for Verisign: 650-961-7500, but it's been ringing for the past 5 minutes, with no answer. One would think that they would have an automated voice-response system on their main number, so I think that they are being innudated with calls.

Strike Back with Poor Typing

[nightsweat]

As a Denial of Service Attack Iwill continue to manually type domain names and not take typing classes.

I oughta be able to bring em to their knees in a day or two.

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: <anyone@example.com>
250 OK
DATA
550 User domain does not exist.

Re:Strike Back with Poor Typing

[Jeffrey Baker]

Why the fuck would anyone run a "mail rejector daemon"? Seems like not answering to port 25 would fulfill all your mail rejection needs.

Re:Strike Back with Poor Typing

[Electrum]

Why the fuck would anyone run a "mail rejector daemon"? Seems like not answering to port 25 would fulfill all your mail rejection needs.

VeriSign is doing the correct thing with regards to SMTP. Not answering will cause the sending mail server to hold the mail in the queue for the queue lifetime (usually a week). Rejecting mail with a 550 causes it to bounce immediately. This is the desired behavior.

Re:Strike Back with Poor Typing

[Jeffrey Baker]

Ah, that does make sense. It also allows VeriSpam to harvest misspelled email addresses ;)

Re:Strike Back with Poor Typing

[bigberk]

Seems like not answering to port 25 would fulfill all your mail rejection needs.

What are you, crazy? You're saying that if no service exists at an address then nothing should be returned? You obviously don't have a business degree and don't work for Verisign. Returning nothing would clearly waste valuable potential for new business.

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:Strike Back with Poor Typing

[mino]

VeriSign is doing the correct thing with regards to SMTP.

Indeed. But not as right a thing, surely, as not returning IPs for these non-existent domains anyway.

If nothing else, they're sucking bandwidth. It's not much, surely, but -- OK. We send out an email newsletter at work (legitimate, opt-in, unsubscribable -- calm down) which goes to 200,000+ people. Say 5,000 people have their domain wrong -- htomail.com or something (no idea if that's accurate, but it's probably not massively far off).

As it was, our mail server would do 5000 dns lookups, get 5000 NXDOMAINs, and ignore them. Instead, it does 5000 lookups, gets this address, connects to the mail server, sends a HELO, gets a response, sends a MAIL FROM, gets a response, sents a RCPT TO, gets a 550. That's an extra... what... couple of hundred bytes of network traffic? Say in the order of 1-2 MB for the lot. Down here in expensive-bandwidth-land, that's about 30 cents Australian it costs us. Not much, I know, but even so, it's there. Not to mention the additional load on our servers for trying to send, making port-25 connections, etc, compared to just giving up.

It's not much, but it IS costing us some small amount of bandwidth and some server time. Screw them.

This is the most #@^%ed-up #@#$ of @#*&ing !@%^ that I've ever #$@@ed in my %$#*.

network operators are pissed at this

[mdouglas]

expect that ip to get null routed by the backbone carriers real fast.

Re:network operators are pissed at this

[Wateshay]

I wonder how long it will be before Verisign decides to sue the backbone carriers for some kind of unfair business practice crap.

Re:network operators are pissed at this

[Alien Being]

That would leave browsers waiting to timeout. ICMP-Rejects wouldn't be much better.

We'll need to hack the resolver libraries and/or DNS servers to translate 64.94.110.11 into "no such domain". Verisign will add some more numbers, and soon we'll have blacklists.

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...

Shorting Microsoft (prepare for battle)

[StewedSquirrel]

Doesn't this this short-circuit Microsoft's attempt to capture ad revinue from all mis-typed domains through their Internet Explorer?

I always thought that a revolting misuse of monopoly power and I use Mozilla exclusively now (that was one of the primary reasons I switched, tho not the only one).

Prepare for Microsoft to be EXTREMELY UPSET. MSN's search count will be cut in 1/4 by this move too.

Watch for it.

Stewey

Re:Shorting Microsoft (prepare for battle)

[wkcole]

The IE rediect to the MSN search mess is configurable: you can turn it off AND turn off the stupid useless 'all errors are one thing' error page and make IE actually give you something useful, at least with IE 5.5 and 6.

HOWEVER, you can bet that MS and AOL and everyone else who does something interesting and useful with HTTP queries that look for bad domain names (like some ISP's that have proxies for users and some companies that have proxies for employers) will be pissed off. Different people like to do different things with their NXDOMAIN responses, and Verisign has just made sure that a lot of those responses never happen and that only Verisign gets to choose what the user sees instead.

There essentially are no more unregistered .(com|net) domains. Verisign has just in effect registered all unregistered domains in those TLD's and pointed them at their own little cash-spinner.

What?

[Lord_Dweomer]

So let me get this straight.....If I own http://www.hardtospelldomain.com, and someone mispells it, Verisign now has the opportunity to offer up the highest bidders site for redirects? Even potential competitors? Perhaps I'm missing something here, but wouldn't this open them to all kinds of lawsuits from companies that were affected in that way?

Re:What?

[Drakonian]

How is this significantly different than the case before? Your competitors were free to buy your domain names misspellings, they just didn't have a handy link to do it right away.

Verisign just DDOSed itself

[diamond0]

Verisign just DDOSed itself by redirecting untold numbers of spam bounces to a single IP. Good job, guys!

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:Verisign just DDOSed itself

[etcshadow]

You didn't hear it from me, but...

Go to any machine you have a login on and:

while true; do for i in 1 2 3 4 5 6 7 8 9 0; do wget -O /dev/null `head -c 30 /dev/urandom | perl -pe 's/[^a-zA-Z]//ig'`.com >& /dev/null & done; echo -n . ; sleep 1; done

If you don't have wget, be creative. Substitute curl, maybe. Or mail. They're totally asking for it.

Of course, I'm not *actually* advocating a voluntary distributed denial of service attack against this unbelievable bullshit. That would be irresponsible. Shame on anyone for thinking of it. ;-)

Verisign would look nice in gasoline and flame

[netmask]

This is really sad.

Not only will mail have problems, as the "non-existent domain" check will always fail.. but this is completely criminal it seems.

I hate to mention, but they are giving Microsoft a dose of their own medicine.. taking away their ability to bring you to their 'search' page for non-existent domains.. and AOL's own feature similar to that. It hurts google, since Verisign teamed with yahoo on this one for search services (Although, google provides yahoos search functionality for now).

All .com domains are resolving with an authoratitive section of Verisign's server.. and .net's with the list of root servers. It would seem that no domain should ever resolve with either of those as an authority.. The real dns server for the domain should. Hopefully BIND and other DNS packages will start blocking domains that have a root server or a verisign server as the authoratitive dns server.

Further.. they'll be harvesting bounced email addresses for sure. If you get spammed from a bunk domain, and it gets returned.. or you typo and email address.. they are nice enough to run a mail daemon on port 25 to harvest those addresses. It lets you helo, from, rcpt, and data.. and then closes your connection.. just long enough to snag all the info it wants from you.

This entire thing is a mess, and seems like it should be highly illegal. Hopefully OpenSRS and GoDaddy and others will have a fit over it. This just seems completely wrong.

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.

Is it just me?

[Anonymous Coward]

Or is this a bit of a coincidence given story

sreb

DDOS in the making

[digitalsushi]

think about it.. your dns server caches the entries it gets back, but now we can make scripts that check sequentially all the way up! crash your ISPs name servers, or crash a root server for the prize! remember kids, take down 2/3 + 1 of the root servers and it's not running on spec anymore!

Now let's see

[psyconaut]

Porn companies aren't allowed to run sites with slightly mispelled names because it's considered unfair practice, but a 'registrar' is allowed to catch anything that might come their way?

-psy

Re:Now let's see

[DA-MAN]

I believe you are looking for www.hotmale.com

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:Agreement by typo.

[flatt]

3. COST OF THE VERISIGN SERVICES.
The Verisign Service(s) are provided to you free of charge.

I can't wait under they start charging for this wonderful service.

Re:Agreement by typo.

[JayBlalock]

That's not hillarious, that's maddening beyond my ability to properly express. Especially, #10 - Sole Remedy: "YOUR USE OF THE VERISIGN SERVICES IS AT YOUR OWN RISK. IF YOU ARE DISSATISFIED WITH ANY OF THE MATERIALS, RESULTS OR OTHER CONTENTS OF THE VERISIGN SERVICES OR WITH THESE TERMS AND CONDITIONS, OUR PRIVACY STATEMENT, OR OTHER POLICIES, YOUR SOLE REMEDY IS TO DISCONTINUE USE OF THE VERISIGN SERVICES OR OUR SITE." If you don't like what Verisign is doing, get off the Internet. This could well inspire even our current Administration to smack them down. This is the most hubris-laden abuse of a monopoly I've heard of in a long time.

Re:Abusing the Power that be

[ScrewMaster]

Verisign has forgotten that they don't own the Internet: they were granted the power to run the root servers and manage primary DNS by the federal government. That government-granted monopoly is revocable. This is a risky maneuver, as it will have global implications. They will probably get their wrists slapped.

The ultimate domain squatter?

[Eric_Cartman_South_P]

Isn't this what domain squatting is? Now, EVERY single variation of a name is squatted, barring the few similar names that are legit. Crazy.

If Verisign somehow was incharge of POP3, then a wrong user name or wrong password would still log you in, but into a dummy account with spam for you to read.

wahts the porelbm?

[yali]

For example, if my domain name was 'somecompany.com,' and somebody typed 'soemcompany.com' by mistake...

What do you mean, "by msiatke"?

patches?

[Pathwalker]

I wonder how long it will be before there are patches for BIND/dnscache/etc. to remap any result containing 64.94.110.11 to a "record not found" result?

Re:patches?

[ncc74656]

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

Someone's already asked WRT BIND. I would be more interested in a fix for djbdns, though.

Re:This is a bitch

[pavon]

I vote that we concider anything from 64.94.110.11 to be spam. That should take care of the problem for spam filters.

Re:Windows already does this...

[leerpm]

Yes, but it is one thing when the application software does it. It is another matter when the network infrastructure provider does it.

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:Windows already does this...

[diamondc]

But you can change your browser in Windows.

Mail trap

[piyamaradus]

This also traps all mail sent TO a non-existent domain. Since all RFC-compliant mail servers will follow up a negative MX response with an A lookup and connect to that IP, if you send mail to a bogus domain, it goes to verisign's server, which (currently) bounces it. Imagine the fun the federal government can have subpoena'ing those logs.

Also, you'll note the cookies that 'sitefinder' sends out, so they can uniquely track any traffic to that site. Also a fun subpoena opportunity. And did you read the fun terms of service that they claim you agree to by 'choosing to visit' their site?

I doubt this will stand. I certainly know that, as a major ISP executive, we'll be reviewing our business with Verisign.

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:234@29387239487234.com
250 OK
RCPT TO:234@587235987234.com
550 User domain does not exist.
RCPT TO:234@587235987234.com
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

Re:Mail trap

[xdroop]

Quick, saturate web pages with hundreds or thousands of nonsensical email addresses -- we can dilute spammer's lists, _and_ flood verisign.

Everybody wins!

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, 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.

My Rights! My Rights!

[Alex Pennace]

Help!

VeriSign has taken over www.lksdjglkjdslkjg44.com! This infringes on my trademark, which I have been using since 21:31 EDT. Unless VeriSign transfers that domain to me, for free, I'll sue!

This is what happens Larry...

[MrPerfekt]

when you fuck an RFC in the ass. *baseball bat on car headlight*

Coupons?

[_Sharp'r_]

Great... now we're all gonna get a wheelbarrow full of $5 coupons from Network Solutions that we can only use for their price-inflated products!

I already have enough toilet paper that says "register.com" on it. Guess I better go invest in a fireplace...

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. What a crock of shit. I think this shows that there needs to be some sort of accountability in this business.

What about Google?

[MobyDisk]

This is horrible for web spiders and search engines. Every link to a dead domain name will now result in a series of pages that need to be indexed. And there will be thousands (millions?) of web sites that all offer Verisign name registrations -- all identical. This will surely affect their page rankings! Spiders will have to be hard-coded to ignore certain IP addresses or DNS names.

I hope they get sued by every mail filter vendor, registrar, and search engine that they just damaged with this. And the government needs to review the powers they are granting to name-server providers.

Re:What about Google?

[Asgard]

Fortunately there is a robots.txt hosted on that server:

User-agent: *
Disallow: /

Re:What about Google?

[Asgard]

It would seem fairly straightforward for Google to change their code to skip that host entirely.

A place for all those bad email addresses

[scruffy]

A lot of email addresses are modified to include "SPAM" or some other word so that they can't be easily spammed. Now all those emails using these addresses have someplace to go. And as long the from address is spoofed to a nonexistent .com or .net domain, then they'll give Verisign something to do.

No, I'm not suggesting that anybody intentional do this. What kind of person do think I am?

Who is going to be the first to hack it?

[Istealmymusic]

Starting nmap 3.28 ( www.insecure.org/nmap/ ) at 2003-09-15 06:36 PDT
Host sitefinder.verisign.com (12.158.80.10) appears to be up ... good.
Initiating SYN Stealth Scan against sitefinder.verisign.com (12.158.80.10) at 06
:36
Adding open port 80/tcp
The SYN Stealth Scan took 94 seconds to scan 1643 ports.
Warning: OS detection will be MUCH less reliable because we did not find at lea
st 1 open and 1 closed TCP port
For OSScan assuming that port 80 is open and port 36304 is closed and neither ar
e firewalled
For OSScan assuming that port 80 is open and port 43206 is closed and neither ar
e firewalled
For OSScan assuming that port 80 is open and port 44655 is closed and neither ar
e firewalled
Interesting ports on sitefinder.verisign.com (12.158.80.10):
(The 1642 ports scanned but not shown below are in state: filtered)
Port State Service
80/tcp open http
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SInfo(V=3.28%P=i386-portbld-freebsd5 .1%D=9/15%Time=3F65C0E9%O=80%C=-1)
TSeq(Class=TR% IPID=Z%TS=U)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags= AS%Ops=MNNTNW)
T1(Resp=Y%DF=Y%W=16D0%ACK=S++%Flag s=AS%Ops=MNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16D0%A CK=S++%Flags=AS%Ops=MNW)
T4(Resp=Y%DF=Y%W=0%ACK=O %Flags=R%Ops=)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 673A4C36 652AB817 BBE534C3 685BB54A
IPID Sequence Generation: All zeros

Nmap run completed -- 1 IP address (1 host up) scanned in 137.552 seconds

But we can't hate them...

[ShawnD]

They are running Linux.

Just a little humour...

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.

Re:Oh common, the workaround is so obvious...

[jaysones]

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.

I don't think a lot of IT people would be very upset if they shot themselves after this! :D

BANZAI!!! Self-DoS Attack of Ownage

[Cordath]

This is one helluva of a way to drum up traffic, so I'd be curious to know what kind of steroid-pumped uber-server and fat petabyte pipe they plan to run their site on. Personally, I suspect the ad page will be taken down by Verisign themselves when they smell smoke coming from the server room and see their sysadmin's running around naked on the front lawn while tearing out their hair and screaming "SWEET MOTHER OF SMEGMA, MAKE THEM STOP!!!".

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

[jea6]

You may want to let Scott Hollenbeck (shollenbeck@verisign.com) and Matt Larson (mlarson@verisign.com) from VeriSign's Naming and Directory Services know what you think of their Best Practices.

And while you are at it, you may consider a friendly note for W.G. Champion Mitchell (wmitchell@verisign.com), President, NetSol and Stratton Sclavos (ssclavos@verisign.com), 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.

comments@icann.org

Re:Complain to ICANN *NOW*

[tuba_dude]

If ICANN was still there for the good of the internet, yeah, that should work. Otherwise, you should only bother complaining if you're a CEO.

Re:Complain to ICANN *NOW*

[trainsnpep]

Well, regardless of whether it will work, I tried:

Verisign has continually been abusing the power that has been handed out to them. Two such examples are its mailing of false renewal notices, and its most recent exploit: sitefinder.verisign.com. Now, nearly all mistyped names will be sent to Verisign where they can do whatever they like to the unwitting user. There are even categories on sitefinder.verisign.com where one can browse and go to sites which are undoubtedly paying Verisign for the space.

Please take this, and the hundreds or thousands of e-mails you will receive, into consideration, and exercise the power that ICANN has. Verisign has continually been abusing and tricking people through deceptive business practices, and this should be the last straw. Verisign should not only be removed from it's post, but it should also be fined for its numerous escapades designed to make money.

Sincerely,
Michael B****

I've got to wonder: where do they come up with such evil ideas? Verisign must have a beowulf cluster of insensitive clods...

Abuse of monopoly will result in regulation.

[semanticgap]

I find it very hard to believe that they will be able to get away with this without some response from the US (and EU) government(s).

Sorry to say this, but this is going to be a precedent for Internet being regulated, this time for real. And you'll be able to thank Verisign for it. Perhaps that's a provocative step to achieve what they are really after - being regulated, which will guarantee them longevity.

Greedy bastards.

Re:Seeeing the future

[SwellJoe]

How big a problem will this be as most people/companies register common mispellings along with the right domain and make the mispellings point to the right site?

This was likely one of the primary motivations for this maneuver...to encourage formerly unnecessary registrations.

I've never registered mispellings of my companies domains, and the thought never even crossed my mind until now. I'm sure the crooks at Verisign saw this angle, in addition to the tons of free eyeballs.

Nope...

[tugrul]

tugrul@duality:~$ telnet dkfjdfkjdkfjdkjf.com 80
Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
^]
telnet> c
Connection closed.
tugrul@duality:~$ telnet it.really.is.a.wildcard.dkfjdfkjdkfjdkjf.com 80
Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
^]
telnet> c
Connection closed.
tugrul@duality:~$

This is just evil

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.

This is simply wrong.

[mindstrm]

Verisign should nto be able to just mess with the dns system like this. They should be a registrar.. nothing more. From their point of view, whether or not this involves websites is pointless.

File a complaint at ICANN

[Anonymous Coward]

http://reports.internic.net/cgi/registrars/problem -report.cgi

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

Terms of Use

[creidieki]

So let me get this straight. A site I didn't ask to go to has a Terms of Use which says that my sole remedy is to discontinue use of "The Verisign Services".

So, by mistyping a domain name, I've entered into a legal agreement with Verisign? And the only way to get out of it is to not use the internet?

The only address on the page is their legal department's postal address, at

VeriSign, Inc.
Attention: Legal Department
21355 Ridgetop Circle
Dulles, VA 20166

I guess I'll be sending them a nice letter. As soon as I figure out what legal recourse I actually have.

Re:But they do manage those TLD's

[leerpm]

No, they are not within their rights to do this. They were hired to manage the infrastructure, not provide sleazy business services. Think of this analogy. If the phone company were to bombard you with an advertisement everytime you dialed a number that was not in service or a cellphone that was unreachable, do you think the federal and state regulators would stand for that? I do not think so.

Boycott the root servers

[Famanoran]

I vote that we all boycott the VeriSign root-servers, and setup an international non-profit agency to maintain new non-commercially-run root servers.

This is outrageous, and despite what they say, is completely in violation of internet standards and best practices.

Re:Boycott the root servers

[WhiteWolf666]

Done.

Ask and ye shall receive:

OpenNIC

Don't worry, it resolves on verisign's servers (for now).

Contact ICANN comments@icann.org

[Teflon]

If you want this "feature" of verisign's turned off (I know I sure do), contact ICANN now. This is yet another example of Verisign having far too much unchecked power over the .COM and .NET registries.

Re:Contact ICANN comments@icann.org

[C10H14N2]

Terrific. As the staff at ICANN can barely fill the coffeehouse across the street, hell, you could probably cram them all in the bathroom without too much work, I'm sure they'll appreciate the /. effect of 35,000 emails in a day on a single issue.

Yeah, bravo. The idea is alright, but suggesting it to the bagillion /. trolls that will see this is not exactly the epitome of civility. I feel for the sysadmin who is no doubt already writing the filter for anything regarding this issue that they are no doubt already aware of.

What is this, better living through DDoS?

Re:Contact ICANN comments@icann.org

[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:Contact ICANN comments@icann.org

[innocent_white_lamb]

What is this, better living through DDoS?

No, this is receiving feedback from the affected administrators, engineers and other interested persons; said feedback hopefully leading ICANN to do the give Verisign a short, sharp lesson in "WHOA!".

You know, the job that they are supposed to be doing and all that kind of thing.

Re:Contact ICANN comments@icann.org

[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:Contact ICANN comments@icann.org

[tulare]

Sorry, but bullshit.

ICANN is responsible for, among other things, ensuring that it's registrars perform their duties properly. If an issue such as this one crops up, and the /. community (trolls and non-trolls alike) decide to make their complaints known using the established protocol that ICANN itself has provided for such matters, so be it. Yes, this will generate an enormous volume of sometimes absurd attempts at flaming, and yes, someone at ICANN has probably filtered all that traffic - although I suspect not to a circular file as you seem to suggest, but to a count-aggregation file to provide a record of public comment.

Face it - sometimes, being responsible for a little thing like the internet can be a bitch. Most of us do have to deal with inane crap as a part of our daily grind, although I admit that getting 20,000 emails suggesting I view a goatsex link in a single day would probably be unusual for me at least. But at least ICANN has said outright that they aren't going to read all of them :) But that's their job, and the closetfull of people who work for ICANN get paid to do it, knowing fulll well that things like this will happen. Big deal. Such is life, such is work. Or do you have a job where your responsibility is guaranteed to be 100% hassle-free? If so, I applaud and doubt you.

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 and their local congressmen/women (here is contact info for Oregon; Washington, 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...

Bisso giveth, Verisign taketh

[tugrul]

Its odd given that we just found out spelling isn't *that* important =P

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:

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

VeriSign Looks At Earning Money on Domain Typos

VeriSign Mulls Way to Make Money from Typos

OpenNIC anyone?

[efti]

Wasn't OpenNIC created to prevent exactly this kind of abuse? People might just start using them if VeriSign carries on in this manner...

"The OpenNIC is a user owned and controlled Network Information Center offering a democratic, non-national, alternative to the traditional Top-Level Domain registries.

"Users of the OpenNIC DNS servers, in addition to resolving host names in the Legacy U.S. Government DNS, can resolve host names in the OpenNIC operated namespaces as well as in the namespaces with which we have peering agreements (at this time those are AlterNIC and The Pacific Root).

"Membership in the OpenNIC is open to every user of the Internet. All decisions are made either by a democratically elected administrator or through a direct ballot of the interested members and all decisions, regardless of how they are made, within OpenNIC are appealable to a vote of the general membership."

It sounds a whole lot better than the current system to me...

Type whatever you want...

[Ieshan]

Just type in any URL you don't think corresponds to an address, like www.googoogoogle.com. All the contact info will be on the bogus page that pops up.

WHY?!?!

[tugrul]

We do blacklists for spam because it originates from multiple moving targets.

Verisign is neither multiple nor moving. Instead of sullying our libraries with this stupidity, put your effort into beating Verisign into submission to common decency.

Misplaced root of trust?

[LostCluster]

Is it just me, or is Verisign now absuing the trust of the Internet community, which is a very strange thing for a company that wants to be a root of trust when it comes to issuing SSL certs?

Re:Misplaced root of trust?

[graxrmelg]

When was the last time VeriSign had the trust of the Internet community? That was gone long ago, especially after they started sending fake domain renewal notices to people whose domains weren't registered with them. If they have a monopoly on issuing SSL certificates, why would they need to care about their reputation?

This isn't all bad...

[Sikmaz]

When I get into work tomorrow I will do two things:

1) Setup an internal web server and redirect all traffic to 64.94.110.11 to this box that says something, you have misstyped something...

2) I will enable reverse lookups and anything coming from 64.94.110.11 will be considered spam.

Won't affect my users and might help a LITTLE bit with spam.

Re:That's it.

[WhiteWolf666]

Well, I know of ONE way....

Internet Death Penalty.

End of Story

Now, the problem is, most individuals are unwilling to go that far. Me, I have no problem---I think the IDP should be used more often than it is.

*.verisign.com, (plus all associated ip addresses).

*.sco.com (and all SCO related addresses (ip/names).

Everyone will need to switch to OpenNIC, or something else, first.

Closer to possible political reality, switch to OpenNIC, and get all your friends to switch to OpenNIC.

Scuh a walircdd culod be used for good

[lplatypus]

Hinavg jsut raed the shoasdlt srtoy eeilnttd Can You Raed Tihs?, I bigen to wnoder if the sirntg mthicang used by DNS is too sitrct. Sulery a pmueertd nmae culod be rtdcireeed to the ceorrct stie? Aslo, one suhold not be aoellwd to reeisgtr a doamin nmae wihch is a smlipe pimaureottn of an esxiintg dimoan name wtih the smae frist and last leettr.

There is no Internet

[DragonHawk]

(Pre-emptive strike: Insert Matrix-spoon reference here.)

I feel it is worthwhile to post a more general response to this point as well.

There is this myth that "the Internet" exists as a single, cohesive network. It does not, and never has. "The Internet" is a network of networks. What that means is that a bunch of independent network operators have agreed to exchange traffic with each other because it benefits them. When you dial in to your ISP of choice (or plug in your Ethernet cable or whatever), you're not connecting to the Internet. You're connecting to your ISP. Your ISP probably connects to their ISP. Their ISP (if you're lucky) connects to several other ISPs, who connect to other ISPs, and so on. All these independent network operators form "the Internet". So, "the Internet" exists as an abstract concept (and a useful one), but not as something you can touch. Not even as something you can route traffic through. All you can do is connect to some other guy's network and hope for the best.

The reason this is important is because we are already seeing ISPs implementing countermeasures against this VeriSign move. Some are null-routing that IP address at layer two; others are using DNS tricks to give us the old behavior. If enough ISPs do this, VeriSign's move will be largely ineffective. In effect, ISPs as a community can veto VeriSign or anyone else. It only works if most of them agree and take action, of course, and it remains to be seen if they will do that. And, of course, some of these countermeasures may themselves be easily defeated, leading to an arms race (like the spammer vs anti-spam arms race).

The possible consequences of all this are, shall we say, interesting.

(BTW, I don't disagree with the OP's suggested course of action, nor with the principle behind it. I'm just pointing out that things are, as usual, more complicated then they might appear.)

Already discussed on the ICANN/GNSO mailing list

[next_permutation]

This is discussed on the ICANN/GNSO mailing list. 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.

E-mail

[jdunlevy]

Just to see what would happen, I just tried sending an e-mail to <testuser@slashdoct.com>. Would they bounce the message? If so what would the error message look like? If they didn't bounce it, would they just keep it? Read it? Inquring minds want to know!

Well it bounced:

The original message was received at Mon, 15 Sep 2003 21:06:55 -0500 (CDT)
from [myhost.mydomain] [xxx.xxx.xxx.xxx]

----- The following addresses had permanent fatal errors -----
<testuser@slashdoct.com>
(reason: 550 User domain does not exist.)

----- Transcript of session follows -----
... while talking to slashdoct.com.:
>>> RCPT To:<testuser@slashdoct.com>
<<< 550 User domain does not exist.
550 5.1.1 <testuser@slashdoct.com>... User unknown

Reporting-MTA: dns; [myhost.mydomain]
Received-From-MTA: DNS; [myhost.mydomain]
Arrival-Date: Mon, 15 Sep 2003 21:06:55 -0500 (CDT)

Final-Recipient: RFC822; testuser@slashdoct.com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; slashdoct.com
Diagnostic-Code: SMTP; 550 User domain does not exist.
Last-Attempt-Date: Mon, 15 Sep 2003 21:06:56 -0500 (CDT)

And: >telnet www.slashdoct.com 25
Trying 64.94.110.11...
Connected to www.slashdoct.com.
Escape character is '^]'.
220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready
quit
221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.
>

Snubby Mail Rejector???

Re:E-mail

[pipeb0mb]

I wonder if more people will become concerned when verisign starts to harvest instead of bounce?

Site Finder Developer's Guide available...

[Etcetera]

Available here

How nice of them to let us know...

An open letter of complaint

[DDumitru]

To: icann@icann.org, iana@iana.org, nstld@verisign-grs.com,
rcc@verisign.com, hostmaster@nsiregistry.net, ir@verisign.com,
dcpolicy@verisign.com
Subject: Complaint about Versign abuse of DNS root zones

A Letter of Complaint about actions undertaken by Verisign Incorporated
on or about 9/13/03.

Sent to the Internet Corporation of Assigned Names and Numbers and the
Internet Assigned Number Authority.

Doug Dumitru
xxxxx xxxxxx xxxx Road
xxxxxx xxxxxx, CA 9xxxx
949 xxx-xxxx

Dear sirs,

As you are probably aware, Verisign is redirecting unregistered
2nd-level domains in the .com and .net TLDs to a Verisign owned search
engine. They are using a technique known as DNS wildcarding to
accomplish this.

I firmly believe that this is clearly an abuse of the DNS system, that
it violates the technical requirements for domain lookups, that the
results returned are fraudulent, and that this technical action only
benefits Verisign at the expense of the rest of the internet population.

I respectfully request that IANA and ICANN immediately take action
against Verisign demanding that Verisign cease this fraudulent and
damaging behaviour. Should Verisign refuse, I would recommend that IANA
and/or ICANN (and/or the US government) take immediate action to revoke
Verisign's contract to administer the .com and .net TLDs.

I would also recommend that IANA and/or ICANN immediately pass "best
practice" rules that prevent other TLDs and country-code domains from
following in Verisign's deceptive footsteps. It is important that a
"domain not found" error not be subverted into an advertising opportunity.

Sincerely,
Doug Dumitru

Terms of use

[Psykosys]

Get this: (Terms of Use):

Use of the VeriSign Services. You agree not to use the VeriSign Services in any manner that is unlawful, or in any manner that could damage, disable, impair or otherwise interfere with another party's enjoyment and use of the VeriSign Service. You may not manipulate or attempt to gain unauthorized access to our website or systems or any websites or systems connected through our website through hacking, password mining or any other means. Modification by VeriSign. At any time VeriSign may modify or terminate these terms of use, its websites and the VeriSign Services and may at any time discontinue your use of the VeriSign Services without any notice to you, and without liability to you, any other user or any third party. Please review these Terms of Use from time to time so that you will be aware of any changes. Your continued use of the VeriSign Services constitutes your agreement to all such terms, conditions, and notices.

A "terms of service" section on a website people don't reach voluntarily?

Complain to Verisign as well

[trafik]

They don't seem to have an e-mail address for the category of "Subversion of the global DNS," so pick one of the following e-mail addresses and use it to CC your complaint to Verisign:

authenticode-support@verisign.com,
billing@veri sign.com,
channel-partners@verisign.com,
clientp ki@verisign.com,
consultingsolutions@verisign.com ,
dbms-support@verisign.com,
dcpolicy@verisign.c om
digitalbranding@verisign.com,
dnssales@verisi gn.com,
enterprise-pkisupport@verisign.com,
ente rprise-sslsupport@verisign.com,
info@verisign-grs .com,
internetsales@verisign.com,
IR@verisign.co m,
jobs@verisign.com,
mss@verisign.com,
objects igning-support@verisign.com,
paymentsales@verisig n.com,
practices@verisign.com,
premiersupport@ne tworksolutions.com,
press@verisign.com,
privacy@ networksolutions.com,
renewal@verisign.com,
supp ort@verisign.com,
verisales@verisign.com,
vps-su pport@verisign.com,
vts-csrgroup@verisign.com,
v ts-mktginfo@verisign.com,
webhelp@verisign.com,
websitesales@verisign.com,
websitesupport@verisig n.com

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

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:Complain to Verisign as well

[PD]

Very good, I just sent them this mail:

From: Patrick Draper <slashdot@pdrap.org>
To: authenticode-support@verisign.com, annel-partners@verisign.com, clientpki@verisign.com, consultingsolutions@verisign.com, dbms-support@verisign.com, dnssales@verisign.com, enterprise-pkisupport@verisign.com, enterprise-sslsupport@verisign.com, info@verisign-grs.com, internetsales@verisign.com, IR@verisign.com, jobs@verisign.com, mss@verisign.com, objectsigning-support@verisign.com,
paymentsales@verisign.com, practices@verisign.com,
premiersupport@networksolutions.com, press@verisign.com,
privacy@networksolutions.com, renewal@verisign.com,
support@verisign.com, verisales@verisign.com,
vps-support@verisign.com, vts-csrgroup@verisign.com,
vts-mktginfo@verisign.com, webhelp@verisign.com,
websitesales@verisign.com, websitesupport@verisign.com,
billing@verisign.com
Subject: Fix the Internet, you broket it!
X-SpamProbe: GOOD 0.0000000 3f0bd9f2ffff366c6e9e732ad3227480

Stop your silly games with the wildcard A records.

Love,

Patrick

--
Patrick Draper | Don't |sig4433@pdrap.org
Austin, Texas | Fear |Father Order runs at a
http://www.pdrap.org | The |good pace, but old Mother
Be Microsoft Free - Use Linux |Penguin |Chaos is winning the race.

Re:Complain to Verisign as well

[tulare]

Heh, the spambots are going to have a field day with your post. Good man.

Violation of ICANN Policy

[wsloand]

It seems that they have effectively violated the ICANN Domain Name Dispute Policy: "circumstances indicating that you have registered or you have acquired the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration". They're definitely doing this to sell domains.

Bill

64.94.110.11

[gyratedotorg]

everyone keeps suggesting that blocking/ignoring 64.94.110.11 is the fix for this. come on, you people are smarter than that! how hard do you think it would be for them to change the A record to 64.94.110.12? then 64.94.110.13? and so on...

as i see it, the only way this madness will stop is if the government gets involved somehow.

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---

Oh great!

[jeeryg_flashaccess]

Tihs is all thanks to sldhsaot's sroty elirear today! Hree's a lnik jsut inacse

http://science.slashdot.org/article.pl?sid=03/09 /1 5/2227256&mode=thread&tid=133&tid=134&tid= 186

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.

Re:The damage is already beginning

[Wyzard]

I'm curious about this. According to RFC 2821, section 5, an A record is only used for mail delivery if there are no MX records for the name. If there are multiple MX records and the first is broken, shouldn't the MTA immediately try the subsequent MX records, rather than using the A record?

I'm not correcting you, I'm asking, since you seem to know what you're talking about and I don't have real-world experience with "serious" DNS administration.

Easy Cheasy DDoS?

[Predius]

So, any dns worm that launches a DDoS, like say, msblaster, that launches an attack against say, windowsupdate.com if it resolves, will now attack Verisign's root nameserver instead? Interesting...

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) and OpenNIC (for OpenNIC (and its peers) users)

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.

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 of publicly available tier 2 servers that you can switch to that are offered by OpenNIC members.

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

Not much of a workaround

[KeithH]

This isn't much of a workaround since the mistyped DNS name will still resolve. Instead of a no-such-domain response from the resolver, you'll instead get a no-response at the application level. This suggests that the server (website or mailserver for example) exists but is down.

In the case of SMTP traffic, the sender will waste time and bandwidth retrying.

Note also that Mockapetris explicitly intended for wildcarding to be supported in RFC1034 - unfortunately, I don't think he foresaw the crass exploitation of the internet by ICANN 16 years ago.

Drastic times call for drastic measures.

[pr0ntab]

Let's define reserved bit 3 in RCODE to be the "evil bit".

So if a patched named resolves a domain to an IP node on a DNS-tomfoolery blacklist, it returns 11 instead of 3, ie. FUCK_VERISIGN instead of NXDOMAIN.

libresolv on Solaris, glibc, etc. should be modified accordingly. Perhaps an environment variable determines the behavior: default is to map non-existant, of course.

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.

Preliminary BIND 8 patch

[achurch]

Preliminary (as in, it seems to work for me) BIND 8 patch that I just cooked up available here.

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, .cc, .cx, .mp, .nu, .ph, .pw, .sh, .td, .tk, .tm, and .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

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

Re:Rejector isn't even parsing

[Molina the Bofh]

Wrong. The DATA command should be followed by a 354 not a 250.

Plus, it'd cut the connection before any harm is done. Look:

volcano:~# telnet 64.94.110.11 25
Trying 64.94.110.11...
Connected to 64.94.110.11.
Escape character is '^]'.
220 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 ready
HELO verisignsucks.com
250 OK
MAIL FROM:<ihateverisign@verisignsucks.com>
250 OK
RCPT TO:<herbalviagraorders@spammer.net>
550 User domain does not exist.
RCPT TO:<iwanttomakemoneyfast@spammer.net>
250 OK
DATA
221 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

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, 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.

Re:Uhm...

[gantzm]

stunt? I'm offended you would call my serious question a stunt! I really would like to know the impact this would have on DNS caches, considering the responses have a 15 minute TTL.

Remember this come with a big smiley! And kids don't try this at home, it just might piss of google. And I don't want to see what happens when google starts bitch slappin' VeriSign.

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 has two ongoing threads ('What *are* they smoking' and 'Change to .com/.net behavior') with further discussion on this topic.

Re:Security Geniuses

[Voivod]

It's easy, but I'm not gonna tell you how. :-)

Besides, I have no doubt they'll fix this shortly. The point is that this shows the level of incompetence at Verisign. We can look forward to them demonstrating this again and again as their marketing department canibalizes key elements of Internet infrastructure into minor profit opportunities for the company.

Boycott Thawte (Verisign's SSL subsidiary)

[ajks]

If you have SSL certificates from Thawte (a subsidiary of Verisign), you can send them a message today.

Email your Thawte rep to explain why you or, better yet, your huge organization :) won't be renewing your certificates with Thawte.

You can tell them "it's a trust thing" (their own motto).

Re:Boycott Thawte (Verisign's SSL subsidiary)

[mino]

Email your Thawte rep to explain why you or, better yet, your huge organization :) won't be renewing your certificates with Thawte.

Superb idea, ajks. Have a cookie (or a certificate).

Here's a form-letter version of the email I'm about to shoot off to our rep, the delightful(!) Barbara:

Dear [Thawte Rep Name],

I am an employee (and listed CSO) of [company name], which purchases 128-bit SSL certificates from Thawte. We purchase approximately [x] certificates a year, which works out to approximately $US[y] per year.

As you might be aware, Verisign, parent company of Thawte, has recently introduced a deceptive and misleading practise with regards to DNS resolution of non-existent domains. Any attempt to locate the IP address of a domain which is not registered (www.non-existent-domain.com) will, rather than returning an error message, return the address of a Verisign advertising server.

This practice is not only ethically dubious, it is also something which promises to cause untold headaches for network administrators all over the world, as well as confusion for end-users of the Internet, all purely for the financial benefit of Verisign.

I am not writing this letter to you in an official capacity as representative of my company: however, I wish to advise you that come certificate renewal time, I will be strongly recommending to my company that we change to an alternate SSL certificate provider, rather than Thawte, if this practice of Verisign's is still in place.

As the listed CSO of this company, I strongly expect that my stance will result in the direct and immediate loss of this $US[y] worth of annual business to Thawte.

This is an selfish and narrow-minded move on the part of Verisign, and I have no hesitation in recommending that my company withdraw its business from Thawte.

Kind Regards,

[Your Name],
[Your location]

We're a small company: but even in our case, [x] and [y] are are 10 and 3000 respectively. It won't take that many to make a sizeable hole in Thawte's pockets.

An exploit

[Anonymous Coward]

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

Physical Location of Verisign Offices

[CaptainCarrot]

From the website:

VeriSign Worldwide Headquarters
487 East Middlefield Road
Mountain View, CA 94043
Phone: 650-961-7500
FAX: 650-961-7300

Have fun!

Here you go

[Anonymous Coward]

#!/usr/bin/python
import socket
x = 0
while True:
try:
x += 1
dns = "www." + "verisignsucks" + str(x) + ".com"
s = socket.gethostbyname(dns)
print dns, "resolved to", s
except: print "resolving", dns, "failed"

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.

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

Re:Here's a neat idea:

[BuilderBob]

I have to ask what is possibly a stupid question...

Is it possible to get the Versign website to DDOS itself? If the server uses server side includes then it can include itself? Would it stop if the client stopped requesting the page or would it keep looping until it maxed out the server threads?

Or, if not server side include, a javascript 'wget' maybe, but that's client side.

Do not leave it is not real.

[Tokerat]

OK fellow geeks, I am seeing alot of ranting about clogging mail server queues with typos and the like, let's go over this a little more in depth:

• http://aldvhlddvhlsdfvh.com - Verisign'd
• http://www.aldvhlddvhlsdfvh.com - Verisign'd
• http://aldvhlddvhlsdfvh.com:69 - DNS Error (immidiately)

Aha, so this only affects web browsers. Other ports besides 80 are somehow ignored...at least that is what happens on this end.

So perhaps it's not that bad. Port designations aren't sent with DNS queries, though, which makes this a bit puzzling. At least if it's true your mail queue wont' clog. Anyone with more experience in the area care to elaborate/prove it wrong? Not looking for a flame war, but a little scientific method.

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.

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

[Anonymous Coward]

Check out http://www.haque.net/verisign_dns_rant.php 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

ICANN said no....

[chipster]

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

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

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

I'm voting with my feet. Bye bye Verisign.

[nuckfuts]

By coincidence I received a (legitimate) domain renewal notice from Verisign today. Instead of renewing with Verisign I am transferring my domain to a new registrar. Verisign-ing off.

Re:I'm voting with my feet. Bye bye Verisign.

[BlacKat]

Wait for the email from Verisign offering you a discount to renew once they get the registrar transfer request. ;)

I got one for each of my domains I moved to a new registrar a year or so ago after I finally got irked enough with Verisign to move.

Now I get my domains MUCH cheaper and the new registrar is miles better then Verisign ever was.

libverisignfix.c

[Dwonis]

Try libverisignfix.c. 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:PLEASE DO NOT CLICK ON ANY SEARCH ENGINE RESULT

[okigan]

Actually I think you are totally right.

The whole thing was done exactly with this
purpose, but I think it can be used to break the
system. If enough bots (and bots only)
constantly "click" on the ads, their price will
plummet. Since now they cannot tell if a person
saw the ad, they "pay per click" becomes
pointless. (and boy they will be mad when find
out they paid all that money for nothing)

On the other other hand if every slashdoter
would ping the thing it would be way more fun.
Come one everybody just type : ping 64.94.110.11
(at -t if you are in windows)

Anti-Trust violation

[kolding]

IANAL, but I dated on once, so take this for what it's worth. This appears to me to be a clear violation of anti-trust laws. Verisign is using their monopoly position as the root DNS to create business opportunities which are not available to others. Verisign can create a nearly infinite number of domains for free, and sell advertising on all those domains. Any of their competition would have to pay for those domains (in fact, would have to pay Verisign). If this isn't abuse of a monopoly position, nothing is. Somebody should sue them under the Sherman Anti-Trust act and get an immediate injunction against them.

Eric
eric at koldware dot SpamThisSucker dot com

What I did

[Piquan]

I've created a Squid redirector to deal with this problem. I tried to post it here, but couldn't get past the Slashdot lameness filter.

It catches anything going to a gTLD's wildcard response (there's about 15 gTLDs doing this!) and redirects it to google. It also does some other niceties that don't automatically happen when using a proxy, such as adding www. and .org/.com/.net if needed.

If anybody wants the code, then post a reply here and I'll set up a web page with it and post the URL. (I won't bother if nobody wants it.)

You may want to know, also, that some of the NANOG folks have patches for BIND to change these responses back into NXDOMAIN.

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

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 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 selling people's personal data for profit.
  
• How is the end result any different from the recent cases of "typo-squatting" 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

Complaint Form ICANN

[Anonymous Coward]

The ICANN website has an online complaint form.

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!

What's next?

[drx]

If you look for a file that doesn't exist on your hard drive, you will get ads for MS Office, telling you that you can create your own files with that!

Add IMG SRC Tags Pointing to Bogus Domains!?

[Ron Bennett]

What would happen if I added some IMG SRC tags to webpages we serve that point to unregistered domain names ... between all the sites I operate that I could easily drive several million hits to semi-random unregistered domains everyday.

Before someone says this is a DoS...remember, the mere reference of a domain name is not a DoS...especially when said domain name is unregistered and in addition contains OUR extremely unique registered service/trade marks ... VeriSign has only itself to blame if they resolve unregistered domains improperly.

Welcome thoughts...

Ron

my complaint, as submitted to ICANN

[Anonymous Coward]

Verisign's current practices imply that Verisign owns veritable rights to all domain names, EXCEPT those which have been registered by others.

Clearly this is not ethical: all others need to pay a yearly fee for registration, while Verisign does not. This must be corrected.

Specifically, Verisign is using all un-registered domain names as aliases (redirects) to their own business sites. This can realistically be a significant step towards ending the internet as we know it - every single internet user puts an immense amount of trust into "the system" every day she or he uses a web browser to surf the web. Verisign threatens to end our trust in the system, with serious consequences for us all.

Legal degree from Play Skool?

[Cramer]

spacemeat:/# /usr/lib/sendmail -bt foo@foothefuckinghell.com
foo@foothefuckinghell.c om
deliver to foo@foothefuckinghell.com
router = lookuphost, transport = remote_smtp
host foothefuckinghell.com [64.94.110.11]
spacemeat:/# telnet 64.94.110.11 25
Trying 64.94.110.11...
Connected to 64.94.110.11.
Escape character is '^]'.
220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
QUIT
221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

Umm, the fact that email is going to go there for every typo or expired domain opens up a great deal of legal trouble. They really haven't thought this out very well have they?

(Even if it currently bounces everything. It still has to get there to be rejected. And there's nothing that says they aren't keeping it, reading it, or won't do so in the future.)

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)

done!

[js7a]

I would be more interested in a fix for djbdns

done: the patch is here

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

UDRP violation.

[arget]

No company will ever have to pay verisign again.

Think about it. You can't register a trademark or similarly "owned" name unless you own the trademark. If you do, the UDRP process will yank it away from you and give it over to the "real" owner. So any company can now file a claim against verisign for any trademark they haven't bothered to buy the domain for, or have let lapse, because now it resolves to verisign, and verisign is clearly using it to make money. Before you can say "corporate stooge arbitration", verisign will have to fork over any trademarks to the companies that own them.

Re:Correction (need resolver workaround)

[ziegast]

A better patch can be found here.

--
Eric Ziegast

I feel a bit like Aurther Dent

[Ex Machina]

The plans have been on file for how long??? eeesh

verisign-sucks.net reaches them fine

[billstewart]

I tried some obvious alternate spellings for Versign's domain name, such as verisign-sucks.net, and they do reach that page. Verisign-sucks.com doesn't get there, but that's because somebody's already registered it....

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 (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.

Others are doing it too

[Jesus IS the Devil]

Other domain registrars were doing this way before Verisign. If you typed in a non-existent domain name for .tv or .cc you'd get the registrar's page.

To me it's a stupid tactic to make more money. But I've moved all 50 of my domains away from Verisign a long time ago anyways.

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.

web.archive.org

[Specialist2k]

Did Verisign even think when they implemented SiteFinder?

One of many problems is that web.archive.org will honor the /robots.txt of any host and remove that host from its archive. So, sooner or later, the archive of all formerly (and currently no longer) registered domains will be gone...

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?

Time to replace verisign?

[joostje]

I mean, we can start paching the nameservers etc, letting verisign change the IP number, and pach them again.

But if enough ISP's or other people with big servers are infuriated by this, why not create a new set of root DNS servers (that get their data from the verisign ones, but filter out the * records), and then replace the current list of root servers in the bind config files with the new ones? No paching of bind, and verisign would learn a nice lesson.

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?

DDoS/attack/"testing"?

[Fastolfe]

So if a script kiddie out there is trying to test his hostname parsing code in his latest DDoS tools, and tries to use a hostname that he knows doesn't exist, would he be liable for the damage his scriptz cause when that hostname actually does resolve to a Verisign IP address?

It really sounds like Verisign wants traffic destined for every mistyped or invalid hostname. I say let them have it. Surely they're aware that the Internet is not just the web.

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 and here 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.

Re:Despicable.. But they're not the first...

[gerardrj]

This is of course completely different than the MSIS issue.
The MS only affected MSIE users for web browsing. The Verison issue affects ALL Internet clients, not just web browsers.
It's actually worse for other clients than web and email as Verizon's machine does not return an error for any other protocol, it just says "connection refused".

DNS wasn't designed to do what Verizon wants it to do, and there's no way to only offer the fake address for queries for web sites.

Clue-by-four

[David Gerard]

From: Martin A. Brooks
Reply-To: uknot@uk.com
To: uknot@uk.com
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:Verisign broke my home mailserver...

[Abalamahalamatandra]

Actually, I somewhat misspoke. It's worse than it appears, and the problem is sendmail, not fetchmail.

Basically, ANYONE who's running sendmail, most likely any sendmail, but definitely on RedHat 8.0, and has a bogus domain name configured on their server, is going to have problems with local mail delivery.

Say I have a server that I've configured with a local domain name of blarg.com, which doesn't exist. When someone on a shell account types "mail joeschmoe", the sendmail that gets started up doesn't deliver mail straight to a file like Sendmail did before the split into submission and delivery daemons.

Instead, it connects over port 25 to the host specified by MTAHost in submit.cf. By default, at least on RedHat 8.0, that setting is "[localhost]".

But guess what? Sendmail tacks on the domain name. And does DNS resolution before host table resolution, even if nsswitch.conf is set to check /etc/hosts first, because Sendmail does its own thing.

End result? You log into a shell, type "mail joeschmoe". The mail program then uses Sendmail as its delivery agent, which then connects to Verisign's mail plonker. No delivery.

The only solution I see is to set the MTAHost setting in submit.cf (I'm too lazy to figure out how to do it in submit.mc) to "[127.0.0.1]".

Andre Opperman fixes this in qmail and qmail-ldap

[acesuares]

From the qmail-ldap mailinglist: New: Fix Versign Breakage for standard qmail and for for qmail-ldap (Updated 20030916!). With this patch we treat wildcard responses (*.com) from the GTLD servers as NX_DOMAIN, like the DNS system did before Verisign broke it for us all. To the hell with these geedy bastards! http://www.nrg4u.com/

Put this in your crontab:

[pen]

0 * * * * lynx -dump http://www.verisignisevil.com/ > /dev/null

Damages

[Sablewing]

Many of the programs at my company were broken all morning, until we found the problem. A lot of the programs we run were trying to get IP addresses from NetBIOS names in Windows, but Windows managed to find hostname.companyname.com. Until now, that had failed and the computer had given up on DNS and gone to the IP address of the computer with that NetBIOS name (the expected result). For that entire morning, all our requests to license managers, database servers, file servers, etc. were timing out and dying.

Also, our ERP package was completely dead for the duration: several hours in which our accounting people couldn't get any work done. I think we'd have a foot to stand on in court if we wanted to sue them for that one. Of course the damages weren't big enough to really make it worth it, but it's just another example of the kinds of things you can screw up by going out and doing this crap.

Personally, I've already added "route add -host 64.94.110.11 reject" to my startup scripts on all my Linux boxes. It won't give me the invalid domain errors back, but at least I won't have to wait for their server to time out before I get my error message.

--Sablewing

The Internet Architecture Board responds

[Etcetera]

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

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 ,
iab@ietf.org
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

Re:Complaint submitted - the text(error-corrected)

[Snover]

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 advertisement for VeriSign's domain 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 VeriSign's advertising servers. Non-Web-based applications (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' because the site does not exist. The same will occur with any ICMP TRACEROUTE or PING tools-- these will not behave in a manner expected. I would be grateful if you could investigate this matter. Yours, Ian McCall

Experimental Postfix patch to do NS and MX lookups

[Hygelac]

Wietse posted an experimental patch 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

That won't work

[pchasco]

All of the programmers out here should know that using magic numbers like this never works. What happens when Verisign changes the IP? What happens if they decide to round-robin sitefinder with a number of other servers with different IP addresses? You would have update your lists of blocked sitefinder IPs regularly.

The only real solutions are to use different name servers, or to put a stop to Veri$ign. And why should we have to spend our time moving to new a DNS?