Slashdot Mirror
Resolving Everything: VeriSign Adds Wildcards
"(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."
You at least have an option of turning off this "helpful" page in IE. No such feature from NSI.
Code poet, espresso fiend, starter upper.
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
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.
With DNS tracer, you can see how much damage they do:
o mo m via A.ROOT-SERVERS.NET, timeout 15 seconds
[~] edwin@k7>dnstracer -s . -o blaat.burps.ploeps.thisdomaindoesnotexistabcdef.c
Tracing to blaat.burps.ploeps.thisdomaindoesnotexistabcdef.c
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.
bash$
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
There are 10 kinds of people in the world. Those who understand binary and those who don't.
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".
.us). Then I see the current authoritative response.
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
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
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.
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.
Candy-Coated Knowledge
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.
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
comments@icann.org
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
"The details of my life are quite inconsequential..."
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.
In the absense of a MX record for a given domain, the MTA will attempt to go to the A-record for the domain.
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.
.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.
.COM and .NET domain names now exist, that anti-spam check is useless.
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
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
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---
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.
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)
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).
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.
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.
SSL Certificate
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
Would you do it for some scoobie crack?
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.
--- Fox
VeriSign Worldwide Headquarters
487 East Middlefield Road
Mountain View, CA 94043
Phone: 650-961-7500
FAX: 650-961-7300
Have fun!
And the brethren went away edified.
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.
<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.
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.
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!
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.
SSL Certificate
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)
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
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.
http://rocknerd.co.uk