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
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.
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.
The update was performed a short while ago and will take some time to propagate. DNS updates aren't immediate.
It goes from God, to Jerry, to me.
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.
I'm still getting NXDOMAIN for any misspelled .com sites. I assume this is because it takes a while to propagate?
Litigious bastards
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.
"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
comments@icann.org
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.
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:
.com and .net .net zone was activated from .com zone is
/ im plementation.pdf
.biz and .us top-level domains. Understanding
/ be stpractices.pdf
Today VeriSign is adding a wildcard A record to the
zones. The wildcard record in the
10:45AM EDT to 13:30PM EDT. The wildcard record in the
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
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
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
Matt
--
Matt Larson
VeriSign Naming and Directory Services
It looks like they added only an "A" record -- records which denote web addresses, not mail "MX" addresses, thus they will not be receiving bounced e-mail.
Yet.
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
Add to /etc/hosts.deny 64.94.110.11
Problem solved.
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...
I tried a few domains and got the Verisign page, but now the 'feature' seems to be missing. Did they backtrack already?
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..."
Inventor Says Search Service Won't Break DNS
VeriSign Looks At Earning Money on Domain Typos
VeriSign Mulls Way to Make Money from Typos
Litigious bastards
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.
Someone's already asked WRT BIND. I would be more interested in a fix for djbdns, though.
20 January 2017: the End of an Error.
In the absense of a MX record for a given domain, the MTA will attempt to go to the A-record for the domain.
MX or not, most mail systems will attempt to deliver to the primary A record if no MX is present.
Available here
How nice of them to let us know...
Hire a Linux system administrator, systems engineer,
Also, contact the operators of the root nameservers B-M.
d ns-root/y2k-state ment.htm
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/
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.
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.
Perfect!
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...
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)
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.
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
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. :/
GROGGS: alive and well and living in
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.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
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?
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.
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
Don't piss off The Angry Economist
It is propagating, as .com and .net servers are reloaded.
-russ
Don't piss off The Angry Economist
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
This will make you search google for your cookie. You can modify it to do whatever you want.
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?
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.
220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
puto
250 OK
laputamadre
250 OK
laconchadelalora
550 User domain does not exist. -- Whoa! it wants a real domain name huh?
laconchadelalora@kagate.com
250 OK
Actually it is not a working MTA. It just prints a series of static messages. If you don't do things in the right order you may not even get a bounce out of it.
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.
So, one could theoretically spam them like so:Of course I am not advocating that anyone do this. Especially anyone with scads of bandwidth. That would be terrible. Oh, the humanity.
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.
Nothing for 6-digit uids?
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
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.
<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.
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
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.
Have fun!
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
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!
Unfortunately, OpenNIC cannot actually mirror .com and .net, since Verisign won't release the zone files themselves. The best we can do is see that the part of the namespace we run ourselves (opennic.glue, .null, .geek, .indy and .parody so far) are run as we think they should be. The queries for the stuff Verisign operates we can only pass off to their servers.
.null (for example) domains, but we can't do that on .net without breaking it completely for our users. (In theory, we could actually run a query ourselves and, if it comes up as Verisigns hijacker IP we could return NXDOMAIN but since this is quite a new problem we haven't had time to look into how difficult that would be.)
This _does_ mean, however, that our servers will return a "no such domain" error correctly on non-exixtent
-robin
done: the patch is here
A patch against this is available for djbdns.
:)
:
:
g z
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.
{{.sig}}
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.
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
A better patch can be found here.
--
Eric Ziegast
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
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.
Seems like now all root servers have the wildcards.
It will be interesting to see the EU's response to this mess.
Real life is overrated.
Remember to include document.cookie in the URLs you refresh to, so that you can steal verisign's cookies. Yup, <script> insertion works too...
Your head of state is a corrupt weasel, I hope you're happy.
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?
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.
Curiosity was framed; ignorance killed the cat. -- Author unknown
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?
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!
I bought this house and you know I'm boss
Ain't no h'aint gonna run me off
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.
No matter how many of my rights are taken away, somehow I still don't feel safe. -Frigid Monkey
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
I don't know how to get around the lameness filter. Ironic, isn't it? Anyway, grab it: antisearch 0.1
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
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
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
Hire a Linux system administrator, systems engineer,
-- Grow up and use mutt.
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