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."
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.
Anyone have any information on whom to contact to put an end to this absurdity?
expect that ip to get null routed by the backbone carriers real fast.
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
There are 10 kinds of people in the world. Those who understand binary and those who don't.
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.
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?
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.
No, I'm not suggesting that anybody intentional do this. What kind of person do think I am?
It looks like only "www.*.com" resolve this way. Try adding "www" to the front.
# telnet dkfjdfkjdkfjdkjf.com 80
telnet: dkfjdfkjdkfjdkjf.com: Name or service not known
dkfjdfkjdkfjdkjf.com: Unknown host
# telnet www.dkfjdfkjdkfjdkjf.com 80
Trying 64.94.110.11...
Connected to www.dkfjdfkjdkfjdkjf.com.
Escape character is '^]'.
^]
telnet> q
Connection closed.
#
Tsunami -- You can't bring a good wave down!
Starting nmap 3.28 ( www.insecure.org/nmap/ ) at 2003-09-15 06:36 PDT ... good.5 .1%D=9/15%Time=3F65C0E9%O=80%C=-1)% IPID=Z%TS=U)= AS%Ops=MNNTNW)g s=AS%Ops=MNW)A CK=S++%Flags=AS%Ops=MNW)O %Flags=R%Ops=))
Host sitefinder.verisign.com (12.158.80.10) appears to be up
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-freebsd
TSeq(Class=TR
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags
T1(Resp=Y%DF=Y%W=16D0%ACK=S++%Fla
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16D0%
T4(Resp=Y%DF=Y%W=0%ACK=
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
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
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.
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.
Its odd given that we just found out spelling isn't *that* important =P
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.
Wasn't OpenNIC created to prevent exactly this kind of abuse? People might just start using them if VeriSign carries on in this manner...
It sounds a whole lot better than the current system to me...
I signed up for a
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.
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.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
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)
... while talking to slashdoct.com.:
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 -----
>>> 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???
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.
/. 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.
Yeah, bravo. The idea is alright, but suggesting it to the bagillion
What is this, better living through DDoS?
To: icann@icann.org, iana@iana.org, nstld@verisign-grs.com,
.com and .net TLDs to a Verisign owned search
.com and .net TLDs.
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
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
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
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?
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:
i sign.com,p ki@verisign.com,m ,c omi gn.com,e rprise-sslsupport@verisign.com,s .com,o m,s igning-support@verisign.com,g n.com,e tworksolutions.com,@ networksolutions.com,p ort@verisign.com,u pport@verisign.com,
v ts-mktginfo@verisign.com,
websitesales@verisign.com,g n.com
authenticode-support@verisign.com,
billing@ver
channel-partners@verisign.com,
client
consultingsolutions@verisign.co
dbms-support@verisign.com,
dcpolicy@verisign.
digitalbranding@verisign.com,
dnssales@veris
enterprise-pkisupport@verisign.com,
ent
info@verisign-gr
internetsales@verisign.com,
IR@verisign.c
jobs@verisign.com,
mss@verisign.com,
object
paymentsales@verisi
practices@verisign.com,
premiersupport@n
press@verisign.com,
privacy
renewal@verisign.com,
sup
verisales@verisign.com,
vps-s
vts-csrgroup@verisign.com,
webhelp@verisign.com,
websitesupport@verisi
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...
--<Mike>--
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.
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
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...
Preliminary (as in, it seems to work for me) BIND 8 patch that I just cooked up available here.
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.
Excessive forking causes un-wanted children.
You know there is no reason why anyone has to use Verisign, ICANN, or any of that crap. There exist many alternatives. 1) We could go back to using the actual ip address. 2) We could each maintain our own huge hosts file. I don't actually recommend either of those ideas. But the idea I do like is why doesn't GNU or FSF or whoever start their own, open DNS system. There are no barriers to entry other than the bandwidth necessary to run root nameservers. OpenNIC is an example, I'm sure there are others.
.com, ,net & .org to much more descriptive endings. DNS can and should be just as free and egalitarian as GNU software.
There are so many problems with the current system that it's begging to be replaced. Corporations basically stealing domains from individuals who got there first. Incompetant corporations like verisign getting rich off of doing almost nothing.
What's more, the OpenDNS system could be much more accomodating with rolling out more progressive TLD's. Move beyond
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.
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).
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.
V$ would have to run a mail server so they can bounce the email immediately - otherwise mail servers would retry for a few days before bouncing the message back to the user.
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.
CAn'T CompreHend SARcaSm?
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
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.
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.
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.
... VeriSign has only itself to blame if they resolve unregistered domains improperly.
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
Welcome thoughts...
Ron
spacemeat:/# /usr/lib/sendmail -bt foo@foothefuckinghell.comc om
foo@foothefuckinghell.
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.)
Now porn sites can send unlimited spam. I just received this p0rn spam in my email
From: sexkitten@ihadsexatverizonswebsite.com
Message-ID: 20030915.9ie4s@ihadsexatverizonswebsite.com
Subject: Hi!
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.
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.
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.
eTrade SUCKS
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...
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.
If you complain to ICANN, be sure to note that this is a breach of the WhoIs policy:
. html
"76. It is noted that ICANN's Statement of Registrar Accreditation Policy requires accredited registrars to provide public access on a real-time basis (such as by way of a Whois service) to the contact details which it is recommended, above, be required to be provided by a domain name registrant 54."
-- The Availability Of Contact Details, The Management Of InterNet Names And Addresses: Intellectual Property Issues, World Intellectual Property Organisation, http://wipo2.wipo.int/process1/report/finalreport
Port 25 is open, and an SMTP daemon is running on it, too, so they are accepting all emails which are incorrectly addressed to any address.
Wonder what's going to happen to *those*...?
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/
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
[insert witty comment here]