BIND Strikes Back Against VeriSign's Site Finder
BrunoC writes "Following the story about VeriSign's new Site Finder, the Internet Software Consortium promises to release a patch to its (in)famous BIND that will block the controversial Site Finder. Wired News has full coverage of the ISC initiative against this name resolving atrocity."
#!/bin/sh
function get_char(){ local GOOD=0;while [ $GOOD == 0 ];do RAND_C="$(dd if=/dev/urandom bs=1 count=1 2>>/dev/null)";if [ $(echo "$RAND_C" | grep [0-9A-Za-z]) ];then GOOD=1;fi;done;};function get_string(){ local INDEX=0;while [ $INDEX != 32 ];do get_char;RAND_STR[$INDEX]=$RAND_C;let INDEX++;done;};get_string;URI=$(echo "${RAND_STR[@]}" | tr -d ' ');wget -O - $URI.com >>/dev/null 2>>/dev/null;exit 1
Tereby helping to prove the old adage that the Internet will just route around regulation! (OK, it's not strictly regulation, but with any luck Verisgn will find that "controlling" the underlying technology of the Internet is not as easy as they first though).
A little planning goes a long way...
Good... Verisign's actions here are a particularly heinous form of "embrace-and-extend". Here, they're "embracing" an entire technology freely provided to them, and "extending" it in a blatantly proprietary manner, with no significant work at all on their part. Taking the whole DNS stack and turning it into a profit center by redirecting it at your whim across the entire internet, is outrageous.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
but couldn't this be the thin end of the wedge towards technologically mediated censorship?
' m a programmer with a soldering iron, and I'm not afraid to use it.
after all, almost anything is possible with the a patch... it just takes the will to do it.
____________________________________________
I
I assume the patch will filter requests, which resolve to the site-finder IP, so what's to stop VeriSign simply changing IPs every so often?
Of course, hopefully this and public opinion will actually cause VeriSign to rethink the whole operation. (We can at least dream)
As soon as a patch comes out, bug your ISP to sort out their DNS servers. Try and nip this thing in the bud
Interesting that BIND only runs 80% of DNS servers, what is the other 20% made up of?
The .nu domain registry has been doing this for years.
Money for nothing, pix for free
Isn't it this one ? ;)
I'm asking because the wording is quite hard to understand as my main language isn't english
blah
http://www.isc.org/products/BIND/delegation-onl
To E-mail me, replace the first period in my domain with an @
"VeriSign did not respond requests for comment."
Isn't that what caused the problem in the first place?
Thanks, I'll be here all week!
I hope some large ISP's bring action against Verisign for breaking their email systems like that.
In the meantime, if you want to help keep Verisigns SiteFinder off the internet, try this simple script in a while loop:
OK, I'm in favour of working-around the problem in classic
But I'm really concerned that this effectively lets VeriSign get away with it. They've bust everyone's trust folks, doesn't anyone care? This sort of activity in a social context (umm... let's see if we can construct a tortured metaphor: ...uhhh..: Your friend asks for your cousins's phone number and you instead give them the phone number of your shop. Reasonable?) would result in the perpetrator being ostracised fairly quickly, if not actually slapped about by a clue-by-four. It's flat out antisocial behaviour, never mind any legalities.
Here, since these buggers appear to hold us all over a barrel with the root domains, we can't just ignore them, and invoking legal recourses is at best slow and expensive. But what about appeal to the authorities that granted them those rights?
Um, the more I rant about this the closer I get to thinking a better solution is switching to an alternate root... Best head off to google again then, I know there's a way around this...
--
I'd rather have a bottle in front of me than a frontal lobotomy
Yep, the patch for dnscache by veteran Russ Nelson is here:
tinydns.org/djbdns-1.05-ignoreip.patch
Not if they make it in a configurable way to let you choose what IP Verisign is redirecting to. Then again, Verisign is a bunch of Dope Smoking Pedophiles, as referenced by this Internet Web site they have registered. Let's not forget they're also a bunch of Clueless DNS whores. Oh yes, and I heard Verisign supports terrorists at this page: here...
Verisign needs to be shut down for these un-American and clearly criminal web sites. Someone notify John Ashcroft, quickly!
I was dumb enough to sign up with, what was called Network Solutions at the time. Then during a moment of shear stupidity, I renewed... till 2007!
I really want to get away from these jerks. There seem to be lots of registrars out there, but I've heard horror stories about totally unresponsive registrars that are glad to take your money, but ignore you if there's any problem at all. Also, if I switch, doesn't that just improve Verisign's profit margin? I've paid till 2007, now they don't have to do anything at all for that money. If I transfer to another registrar does Verisign get to keep my money?
Advice?
Signatures are a waste of bandwi (buffering...)
Patches for DJBDNS and lots of other daemons here.
upgrade can be found here:n -only.h tml
s &m=1063 79587928771&w=2
http://www.isc.org/products/BIND/delegatio
There is no need to create a com or net data file. Just the
entries to the named.conf file is enough
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
Ofcourse, if you use views, this needs to be provided within the relevant
view (the one performing recursive lookups).
quote from:
http://marc.theaimsgroup.com/?l=bind9-user
Russell Nelson has a patch for tinydns which does the same thing.
He also notes that several other TLD operators for the same thing and has another patch that allows you to do the same thing to several naughtly tld operators at once.
Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).
You can get the details from the bind-announce list archives:
All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:
Have fun downloading and installing!
-Raphaël
Unfortunately the djbdns patch at that URL is not as elegant as the official patch from ISC for BIND. Unlike the ISC BIND patch, the djbdns patch does not support the declaration of "delegation-only" zones. Instead, it adds support for the rather crude technique of converting an A record response containing an operator specified IP address (which you would currently set to 64.94.110.11) into a NXDOMAIN response.
So you have 2 mail servers with mx priorities as follows:
mail.someplace.com 10
mail.otherplace.com 20
if your someplace.com domain expires (hey, it happens) all your mail bounces thanks to verisigns ace "Snubby Mail Rejector Daemon v1.3". The backup mx record, which is there to cover failures like domains expiring, is never tried. In the 'real' world.. where lookups on dead domains fail... the backup server would be used.
Thats a bigger problem than all this spam checking people are getting worked up about. If they both had priority 10 (a simple load balancing arrangement) then half your mail would bounce and half would be ok.
Some improvement! Patches to BIND aren't the answer. Verisign need to be made to stop breaking the internet.
0daymeme.com: Great stuff.
I said it a long time ago, but there's a very simple way to fix this problem. Alternic was offering a solution 7 or 8 years ago for the Network Solutions monopoly. If BIND decided to distribute a seperate set of root servers in a cache file and enough ISPs used it the Internet DNS system as we know it today could change overnight. ;-) There is NOTHING giving ICANN or Verisign any power except our own complacency to not change a single file in our DNS server. It's laziness.
The interesting question is, will enough people pick up the patch, so that Verisign will see their efforts wasted? This will only happen if the distros redistribute the patch.
Will the Linux distros provide updates to BIND that include the patch? (I bet yes.) Will Sun, the dot in .com, update Solaris? (This is harder to guess.) As for Microsoft, I think they will sneak in a patch, to Internet Explorer only, the next time they issue an "urgent" security patch -- though their motive is purely to protect their MSN Search revenue.
DJBDNS already has a patch available.
ISPs running DNS will certainly disallow this redirection to VeriSuck.
/we/ want you to go."
But soon thereafter, if not immediately, they'll start directing their customers to their own search site, or whatever search site they're paid to send them to. Or maybe some ISPs already do this?!
We need an RFC stating that this is not permissable.
Heh, maybe as a byproduct we'll see public DNS servers pop up. "Use us for free, but occasionally we will send you where
I for one welcome our new DNS overlords! All our domain name are belong to THEM! Mwuhahahaha...
Please help metamoderate.
Maybe if a misspelled URL went to a random other URL, it might be OK, but using that page to advertise for a particular company's profit, regardless of the URL, seems really bad. I would much prefer to have a "not found" message, since that's really what's happened. Can you imagine if this happened while driving? Anytime you turn down the wrong street, the same ad came on the radio or something like that? It seems positively Orwellian.
stuff |
NO NO NO NO NO NO NO! DNS is a directory service for god's sake, not a god damn search engine. If you want a search engine then go to Google like everyone else does. If people are too stupid to assume typing in "www.whitehouse.com" will take them to the White House's homepage then they deserve to get tits in the face. Type in White House in Google, hit feeling lucky and you'll get the right page right off. DNS maps domain names to IP addresses and vice versa, nothing more. Don't pervert it into some god damn spell checking search engine.
Bind should just return NXDOMAIN and the application (Mozilla, IE, BitchX, whatever) can then sort it out in this fashion. Hell, we can even make handy BSD-licensed shared libraries that do this for easy integration.
The matter is that the application must be informed when a domain does not exist, not spammed with guesses that may be right.
Pathman, Free (as in GPL) 3D Pac Man
BIND should be enhanced in several ways:
The most important one, IMHO, is to compute a list of close matches and present these choices to the user. They may use the Soundex algorithm or some other tricks to see if characters are transposed, if one characters is wrong, if one is missing, etc. If well implemented, this would solve 60% of the problem.
BIND (and other Domain Name Servers) are given the simple task of turning a string into set of 4 octets (aka an IP address), using a massively distributed lookup table that maps strings to IP address.
The reason people are pissed off about Verisign's wildcard entry is that they have depended on their DNS saying "I can't find an IP address" when it can't find an IP address.
In general BIND is a program that talks to other programs via a very stable and well understood interface. Now, how would enhance BIND to do a soundex and return multiple possible results to programs that have been written to expect either a response in the form of a single IP address, or a "domain not found" error?
Sounds to me like this is something that should be handled in the application, if at all.
-josh
Exactly. The correct term for this is Sldahost efcfet
Having an application do that is completely different than having what is essentially one of the only Internet "utilities" do it without your consent. Redirecting queries is the job of an application, not the DNS root servers. There's a reason looking up non-registered domains returns an NXDOMAIN, because the RFC says it is should!
Actually, ISC as been smarter than that. What they have done is allow certain domains to be designated "delegation only". That means, in a nutshell, you can specify for instance ".net" and ISC will automatically return NXDOMAIN for anything other than an NS pointer at that level. This in effect will wipe out wildcarding at the TLD/GLD levels for which it is configured, and if you wished you could even extend it to block wildcarding of things like "*.uk.com".
UNIX? They're not even circumcised! Savages!
this is just a trick. They just want to get rid of all those obsolete BIND-versions out in the internet.
So they did this to goat all admins into patching their bind.
Tricky they are...
Regards, Martin
ICANN might be able to force VeriSign to get this off the net
http://www.petitiononline.com/icanndns/
Is Stratton D. Sclavos doing a good job as CEO of Verisign? Vote yes or no in this Forbes.com poll.
Also, here's a petition that may also be of interest.
<sig>Guvf vf abg n frperg zrffntr
They don't state if it's simply blocking the well-known IP of SiteFinder or doing something cleverer.
How long till they change the IP/round-robin it?
I noticed the wildcard domain does not generate an SOA record so that may be a better detection mechanism, but maybe it will break existing misconfigured sites?
In any case, Verisign can always come up with new scams to make the record look more authentic.
The only long-term solution is to move to a different host, which would be really hard to arrange collectively.
We're not talking about you and your little web browser, we're talking about a major network provider breaking an important network infastructure component in a way which has already started to cause havoc across the internet. At the moment, the server they are using as a catch all is not responding to connections, which means that there "clever" solution to handle mis-directed email doesn't work. As a consequence, mis-directed mail has already started to pill up in mail queues while mail servers waste their time trying to contact the Verisign server.
Other services are also shit out of luck; Verisign only allowed for HTTP and SMTP. Anything else trying to connect to a non-existent domain is out of luck and will sit around until the connection timesout. Of course, if the server had just returned NXDOMAIN in the first place, as it should, you wouldn't have that problem.
Were I coding this patch, for example, the IPs for which to return NXDOMAIN would be specified in a config.
And what good would that do? If VeriSlime changes the ip hourly, you'd have to edit the config file hourly: bwilliant patching Holmes.
I prefer the patch as it will be supplied by the ISC: Patch bind and add the following snippet to named.conf:
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
Tada. Let VeriSlime work around *that*.
DNS is a directory service for god's sake, not a god damn search engine.
Right
DNS maps domain names to IP addresses and vice versa, nothing more
Wrong
Special Relativity: The person in the other queue thinks yours is moving faster.
as suggested by Abby Patel at http://www.theregister.co.uk/content/6/32872.html
/. them and see how many netblocks they end up excluding.
However, it seems that the T&C's might help us to stop this abuse. If you do not agree to the T&C's the only option they have is to not redirect your netblock to their site. So, give them a call on 0800-032-2101, select 2 to speak to their support department and once you get a human, tell them that you don't agree to their T&C's and can they remove your netblocks!
So lets
"I just did. I don't see what the fuss is."
.net and .com and there's a world of other TLDs out there.
Ah. Bless. Cuddle up nice and warm.
Verisign is the root domain authority. This is them overstepping bounds and trying to get into the search engine game, something which is 'forbidden' by ICANN. They're farming information that comes in, and if you'd read the handy terms and conditions, you'd notice some real oddity.
So, you type in a mispelled URL...what if your competitor is in their database but you aren't? Furthermore, what if they get the domain wrong? Verisign only has
Then there's the email angle. They're running an MTA that barfs after the 550 for 'From: '. So they're grabbing 'legitimate' email addresses. Trust verisign? As a 'trusted' third party for certificate signing, they're supposed to remain impartial to a certain degree, except they're pushing webservices.
Oddly Draconis
Too cynical to live, too stubborn to die.
And not to be outdone by Verisign, Google has added a default route to the global BGP table which brings any formerly unroutable web traffic to their search engine.
NOT!
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Read the discussion: 80% runs BIND, what runs on the remaining 20%?
Clever signature text goes here.
The root servers do not serve
Moreover, alternative root servers would have to delegate .com & .net to some other trusted(?) party...
I have to make a small complaint here. I don't seem to be able to get the sitefinder page when I enter in an unregistered domain name. Not the links above nor just random garbage. I merely get a "Could Not Connect to Remote Server" message.
*Sigh*. I never get to have any fun...
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".
This is especially critical given that Verisign's business is supposedly trust. They sell SSL certificates, and the only way they can claim they're better to use for them than (say) I am, is that they have an established record of security procedures and trust.
Had trust. Who can take them seriously now?
"2.4 Monitoring and Communication .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign's Network Operations Centre... complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis."
VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in
Ehm, well I don't agree to your Terms and Conditions, thank you very much. Please stop storing my typo data Please.
Anyone have a lawyer and a small site to try this on. I suspect that you have a case of some sort. "Your honor, we had planned for this type of mistake by having some.other.domain.com as a backup, but verisign illegally stole the expired domain and started bouncing our messages." Or some such. Of course that backup wouldn't work in the case of the domain expiring and someone else registering it instead, but you tried.
It's the other way around. Hormel has a trademark on 'SPAM' and would prefer UBE to be called 'spam'. See the SPAM website for more info.
What your not aware of is that about the same time Microsoft inserted it's own "helpful" page instead of what the remote server sent web admin realised the value of using the servers own internal feature of sending a more helpful page.
The internal 404 usually is some sort of program to track down and redirect you to where you should be so instead of saying "This page no longer exists" it's saying "Hay maybe you want THIS page instead."
Also read the 404 page more carefully. If something has gone wrong with the website your given contact information (presumming the web admin did his job and put the admin contact e-mail into the server) in the 404 message so that you can contact the person or persons responsable for maintanence and tell them what went wrong.
But again you won't get that contact information under Microsoft Windows IE "helpful" page.
That page is IEs best guess as to what happend and being familure with the Internet I'm usually aware of what is wrong and what is really going on and quite frankly IE has yet to guess the real cause of the 404 message.
However the big diffrence between Microsoft IEs replacement "Hay quit complaining I'm only trying to help" and Verisons search website is that IE is on YOUR computer and if you don't like how IE works download Netscape, Opra, Mozilla or one of the many other web browsers that are out there and you get the REAL 404 message but Verison is basicly changing the Internet inferstructure to do this so we all get screwed reguardless of the programs and os we use.
I don't actually exist.
You don't get to see a "404 No Found" response if the server doesn't even exist. You'd usually get an error message (generated by IE) that says something like "www.invaliddomain.com doesn't exist." (that's what Mozilla displays, I don't know IE's message).
The 404 response is what you get when your browser could send a HTTP request to the web server, but the server couldn't find the page you were requesting. The response page is generated by the web server, so how helpful it is depends on what the web server admins have configured. Some pages will not simply return an error message but also include a search box, for example.
Well, yes, I expect a somewhat helpful error message. But that's not actually the point. The main problem with Verisign's move is that they are assuming (like you seem to do) that the purpose of the Domain Name System is to find the web server that a user is trying to contact when he types an URL into his browser. But DNS isn't used for the web only, it is used to associate names with IP addresses. You can then use the returned IP address for whatever protocol you want, DNS doesn't tell you whether or not the server with the returned IP supports that protocol.
For all protocols that run non-interactively (i.e. without a human sitting in front of the computer and interactively deciding what server should be contacted next, and interpreting the responses), Verisign's action means that if contacting a remote system fails, the computer can now no longer find out if it's due to a misconfiguration and will likely never work (if the other computer doesn't exist), or if it's just a temporary problem (if the other computer does exist but does not respond).
Sig (appended to the end of comments I post, 54 chars)
this effectively lets VeriSign get away with it.
h tml
As a BIND architect/deployer/admin I see that ISC is always getting bashed. Kudos to them for this creative patch, presented almost instantly compared to their usual release schedules. But, precisely, it let's Verisign get away with this action, which is horrible. Especially because this: http://www.iab.org/Documents/icann-vgrs-response.
(which was posted in the first slashdot thread abot this topic), went unnoticed, and unheeded by Verisign.
Big business in this country is getting WAY out of hand with greed.
You dial a wrong number on your phone and a local telephone carrier answers and begins to try and sell you long distance and local services.
UNIX/Linux Consulting
Of course, they would need to customize their DNS software to do that, as opposed to just adding a line to a config file.
Even better is the version I wrote last night, which lets you ignore a list of names.
-russ
names.tinydns.org/djbdns-1.05-ignoreip2.patch.
Don't piss off The Angry Economist
OK, bad form to reply to my own post, but it was a serious question, not a troll.
Granted this breaks a lot of systems that depended on getting error results for failed lookups. So, now they will have to check for 64.94.110.11. Not nice.
But as much as I dislike monopolists and their heavy-handed ways, the arguments against this action seem a little weak.
One guy complains that his printer no longer works because previously, his network configuration depended on failing to resolve some addresses in order to route the request internally.
Another person mentions that anti-spam checks based on domain names will fail. So, this is a valid check for spam? Oh, I thought spammers simply spoofed the originating host, which is why I get hundred of "returned" messages I never sent.
Someone else complains that it's an abuse of powers given to Verisign by the government. OK... but so is 75% of business. It's a tough life, yeah.
Seriously, I'm not trolling: I'm trying to understand what the actual technical problem is. How can any system rely on the absence of something? How can a "not resolved" error actually be more useful than a resolution to an IP address that does nothing useful?
Ceci n'est pas une signature
With it's digital certificate business, Verisign started as a company that dealt in trust. That was the heart of their business. Now it's hard to think of a company I trust less than Verisign.
For this stunt, they should lose their authority to register domain names. This company should never be allowed to touch internet infrastructure.
When all you have is an axe, everything looks like a grindstone.
"Linux is a serious competitor"
- Steve Ballmer, Chief Executive Microsoft Corp.
Yup. It's crude. On the other hand, it's simple. Simple is good because you can read the patch and understand it. Consider that ISC has published three or four remote root exploits, and djbdns has had no exploits, remote, root, or otherwise. I'll take crude over insecure any day. J.P. Larocque has a script which lets you update root/ignoreip. You can update that file in a few seconds. An ISC-enabled root exploit means a complete reinstall unless you seriously trust your ability to remove a rootkit. Let's say it takes five seconds to update the file. Let's say it takes a whole day to reinstall your server (optimistic). Let's say there's a 1 out of ten thousand chance of this code causing a remote root exploit. There's 86K seconds in a day, so their code costs you 9 seconds a day. Given those assumptions, the "automatic" ISC procedure for updating the ignorable IP addresses costs you more time, on average, than updating by hand every day.
-russ
-russ
Don't piss off The Angry Economist
Once discovered a bright-red coffee mould. It was in a paper filter of a coffee machine that we forgot to throw out. And yes, after thoroughly rinsing the machine, we still continued to use it...
Currently, the page VeriSign is approximately 2.9k is size. What happens they start adding banner ads? Will the extra traffic slow down the internet as a whole?
I wouldn't be surprised if the next Microsoft worm used VeriSign's new "feature" to bring the internet to a crawl.
$ host thisdomaindoesnotexist.com
thisdomaindoesnotexist.com has address 64.94.110.11
So every program that looked for a DNS error when a domain does not exist will no longer get that error. I wonder what kind of problems this will create.
Anything else I'm missing?
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
Interesting that it rejects the first recipient, but accepts the second, then bomb on the DATA stage.
You are thinking too complex for verisign standards
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.
also, it's nice to know that they've thoughtfully decided to help the US post office by only taking questions/comments via snail mail (why bother taking email?)
If you have any questions regarding this Privacy Policy, please contact
VeriSign, Inc.
Attention: Legal Department
21355 Ridgetop Circle
Dulles, VA 20166
How about we pre-empt Verisign by redirecting the 404 pages to this petition?
while true; /dev/null
do
echo VerisignSucks${RANDOM}Times.com \
| nslookup >
done
but that is why we have what we call, in the jargon, "soft-ware main-ten-ance"
And the reason that we have standards bodies is so that we don't have to do "soft-ware main-ten-ance" three times a week every time somebody on a hunch decides to break the standard. Suppose AOL decided BGP isn't a good protocol and starts broadcasting AOLBGP instead - which looks like BGP to a BGP-speaking router but isn't, and is misinterpreted to cause all their routes to get scrambled. Suppose somebody has a backup MX record which doesn't get consulted because the primary is down and Verisign unhelpfully reports that it still exists and accepts but does not deliver the email. Ditto for 100 other protocols other that http.
What if the company contracted to do road-work decided that roads are an inefficient technology and decided to go ahead and replace them with rails instead. No problem, you just need to do a little car main-ten-ance...
Why should all our existing software have to be rewritten because Verisign screwed over the internet?
Petitions only work if a) the petitioners represent a threat to the petitionee's livelyhood, or b) the petition is to force a state government to put something to a vote (e.g. referendum process). ICANN viewa us, the lowly internet users, as riff-raff. They are the lord, we are their serfs. What threat does a petition hold for them? They have absolute power and don't care what we think.
If a job's not worth doing, it's not worth doing right.
* IN NS screw-isc.verisign.com. and use that to deliver their stupid A records. Of course, if they do that, then things are going to degenerate rapidly. Verisign will not back down because there is money involved, the DNS admins will not back down because of the principle of the thing.
Should this happen, then ICANN is going to have to step up to the plate, since they are the body to which Verisign is responsible, and make a decision. So, on one side we will have the Internet DNS community, the IAB and IETF, while on the other we have Verisign exceeding their mandate for a chunk of cash. It should be a no-brainer, but given ICANN's track record I certainly wouldn't put any money on which way they would make the call.
UNIX? They're not even circumcised! Savages!
Who should I write in the government to complain about Verisign's abuse of power? If I recall correctly, the US government had granted Network Solutions the power to directly control the DNS servers, but NetSol was later bought out by Verisign who has done nothing but abuse its monopoly. Is there some government agency in charge of watching over Verisign; a government computer agency? I feel the need to write someone in power about this. We can patch the problem all we want - the only true solution is to end Verisign's power over the DNS outright.
http://www.petitiononline.com/verisign/
That would be bad. We use wildcards to ease our DNS duties. For example, we have a customer who likes to create daily new domains such as somenewcompany.theircompany.com somenewcompany2.theircompany.com blahblah.theircompany.com Instead of letting them change the DNS constantly we just setup *.theircompany.com to go to their server. Then all they have to do is manage their apache/IIS/whatever web server. So having BIND remove wildcard support would break us as well as I suspect MANY sites.
Yeah, how exactly IS this going to help??? Who modded this person informative?
It will only work if you manually try and goto sitefinder.verigisn.com (www, ping, trace, whatever).
Do you really understand how DNS works? If I make a query to iudsbfkjdf.com, verisign redirects me to their IP using the wildcard 'A' record, in which the webpage at that IP CLAIMS to be www.iudsbfkjdf.com.
Adding that to hosts will only redirect you to (in your stated case - google) if you attempt to connect to sitefinder.verisign.com.
Party?!? What kind of party is this? Where's the damn keg?
Virtus Junxit Mors Non Separabit
Good questions.
As for splitting, there are already several alternate roots. In addition to Alternic, there's OpenNIC and Pacific Root. People are using these only voluntarily, and the different roots cooperate to some extent. For example, most will only establish a new TLD if no other root is using that TLD, and most will peer TLDs for the other roots so you can see the entire composite alternate namespace. This is strictly voluntary, however.
It might be that some day the alternate roots cooperate less. We can get a glimpse of how this works through the issue of the .biz TLD. Pacific Root had a .biz TLD years before the official Internet .biz TLD. People had paid Pacific Root for this privilege. Pacific Root decided to maintain their own .biz TLD, such that if you are connected to them you will see their .biz, and if you are connected to the real Internet root servers, you'll see the official .biz. Meanwhile, they peer all the other official TLDs so that you see them. Other alternate roots made independent decisions. OpenNIC, for example, chose to continue peering the Pacific Root .biz and ignore the official one. Verisign et al can be viewed as a non-cooperative alternate root server, and this shows how a group of independent voluntary alternatives can coexist.
As for cost, at the moment OpenNIC is free to use (I don't know about the others). I think most alternate TLDs have free registration, though I know that Pacific Root charges (and apparently makes money) for registering in the TLDs they created. If more people started using these alternate roots and costs went up, the alternate roots could start charging more registration fees, or charge users; people could choose among alternatives based on price, quality, and access to the TLDs they want to see. Competition would be good, though some alternates might have to shut down. Think about who finances the yellow pages: the users, or the people who are registered. Also, it's possible this could be entirely financed through voluntary donations.
It's conceivable we could completely escape from Verisign just through exercising our free will to choose alternate roots.
Secession is the right of all sentient beings.
Just look at what you can do now !
verisign sucks
alternative to verisign
domain hosting -verisign
trust betrayal broken internet verisign"
bind patch
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
I'm not sure if you intended it that way or not, but you make it sound like this has become a corporate versus long-haired hippy DNS admins battle. I dare say it's much more severe than that. Even my small (by comparison) mail servers are churning like sum'bitches now that they've got all sorts of "hjkvashjklfasdhl.com"-esque domains to send bounce messages to. Imagine the hapless provider with millions of e-mail accounts and, correspondingly, millions of SPAM messages per day. Formerly, forged domains could be easily chucked to the virtual circular file. Now, however, they quite happily resolve to a server that answers to SMTP queries. (Also a black hole, I imagine, but it still has to traverse half the Internet to get there)
DNS/Sys Admins have to spend time troubleshooting this problem and attempting to work around it in several different arenas. This is definately a money versus money issue. It just so happens that we also have principals on our side.
BD Phone Home!
Shameless plug. Like you weren't expecting it.
No kidding! Now if you ping fartsnuggle.com it just sits and waits for the timeout, but if you ping fartsnuggle.org you get an immediate proper response of "ping: unknown host fartsnuggle.org"
I got a rep on the line and he seems oblivious of what was going on, after a bit I got a superviser and she gave me this email telling me that this is where the complaints are going to:
sitefinder@verisign-grs.com
Someone asked me the difference between ignorance and apathy, I told them I don't know and I don't care.
Quit complaining. If you RTFA (a novel concept, I know) you would have seen that this is at a PER-ZONE level.
As in, you say that the root zone is delegation-only and suddenly the A record that Verisign put in there is ignored.
Say it with me again: PER ZONE. There's no reason ANYONE would put this on a normal zone. It ignores all host records, which is good because these things really don't belong in the root anyways.
So don't worry newbie, your nice newbie domain won't be broken by the nice widdle patch. Now go install it.
You may disagree, but to be blunt, you're wrong. -tgd
Actually there are plenty of legitimate uses of the wildcard feature. One you might use everyday:
*.sourceforge.com
How do you think they keep on top of that many DNS entries that constantly come and go? You see it at ISPs that do third level (and higher) DNS virtual hosting and and group systems where the URL might be in the form of username.domain.com instead of domain.com/~username/
DNS supports it because it is a legitimate
feature. And less you think removing wildcard support would fix the issue, as it has already been mentioned in this discussion, all Verisign has to do is modify their DNS server to supply responses that appear to make the domain legitimate. They already use non-standard DNS software, why not make a few more changes to enhance their bottom line?
Even after the ISC makes the patch to disable wildcards at the TLD level, Verisign can as mentioned above work around it if they really want to by modifying how their servers respond.
Never meddle in the affairs of dragons,
for you are crunchy and good with catsup.
This is NOT a solution!
.com and .net TLDs, and as such, OpenNIC has to delegate all queries to their servers. Result? All unregistered .com and .net domains will still resolve to the evil SiteFinder.
I repeat, this will not fix anything. Verisign controls the
Moderators, please mod this up.
Matthew Walker
http://www.tweeterdiet.com/ - My Diet Tracking Tool
The next hurricane is coming soon, but subscribers can beat the rush and flee the territory early!
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
"2.4 Monitoring and Communication VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign's Network Operations Centre... complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis."
#!/usr/bin/php4 -qW XYZ0123456789"; .= $charset[$idx]; .= ( ((rand()%2)==0) ? '.com' : '.net');
<?php
chdir('/tmp/verislime');
$charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV
while (true) {
$str = 'wget http://www.';
$len = rand(5, 24);
for ($i=0; $i<$len; $i++) {
$idx = rand(0,strlen($charset)-1);
$str
}
$str
system($str);
}
?>
It's amazing how many super cool random people are running around suggesting using OpenNIC, which, of course, won't do a DAMN FUCKING THING. Anyone who suggests an alternate root has demonstrated they have no knowledge of how DNS works at the topmost level.
Please, someone go around and find all the posts that mention this and moderate them up! I've posted at least three posts pointing this out, and other people have also.
I'm starting to think everyone should have a few emergency -1: Wrong mod points to get rid of information that is just flatout incorrect.
If corporations are people, aren't stockholders guilty of slavery?
This is more than a little troubling.
The BIND patch is very simple and elegant. It relies on the particular technical method that Verisign used to implement their wildcard responses. But we can make some assumptions here.
If Verisign truely believe they have the "right" to do whatever they want to do with the root zone files, they can easily circumvent the patch.
One design that they might try is to take the inbound domain name, hash it, take a modulo of the hash and create a "fake" SOA and NS for that domain name on a unique IP address. With a pool of only several thousand real IP addresses they could create what looks like 100% real zones for everything. They could even send the traffic to one of many different IP addresses. This could be an arms race that never ends.
The only "real" solution is that the root zone files must be "trusted".
If Verisign refuses to change their behaviour then one of several things must happen.
o ICANN / IANA must force them to
o DOC must force them to
o Private lawsuits must force them to
o State AGs must force them to
o Everying must blackhole "ALL" Verisign owned IP addresses and effectively take them off of the net.
Doesn't work for me...then again, I've already fixed djbdns here to return NXDOMAIN when a lookup resolves to Verisign's squatter page. (A copy of the patch is here (the patch isn't mine, but the only place I've seen it is buried in bugs.gentoo.org) and an ebuild for your local Portage tree is here. To use the ebuild, you'll also need to copy Manifest and files/1.05-errno.patch from /usr/portage/net-dns/djbdns.)
20 January 2017: the End of an Error.
It doesn't care WHAT you type, you get the same garbage no matter what.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Here is a much better petition entitled: "Stop Verisign DNS Abuse"
i didn't write this the post above, but it is definitely not offtopic. here's a brief rundown of what it does:
/dev/null. obviously, this string (with appended .com) resolves to verisign's search page.
generates a random string of characters.
performs a "wget" to look up that string as a domain name, and fetch the url returned and dump contents to
this accomplishes two things. first, or course, is wasting verisign bandwidth. more interestingly, however, it causes dns servers upstream from you to cache the address of all these garbage domains. when their dns cache fills up, they start discarding older entries they have had in there. basically, this is forcing dns servers to constantly flush their caches of any useful data. this, in turn, makes every valid dns query have to cascade all the way down to the root servers. that is, "slashdot.org" is no longer cached in your isp's dns cache, so every user on you isp trying to get to slashdot is contributing to a DDOS of verisign's root servers.
well done.
replace
while( bogus_addrs[i].addr.addr4.s_addr != (in_addr_t)-1 )
with
while( bogus_addrs[n].addr.addr4.s_addr != (in_addr_t)-1 )
or you'll be sorry.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
You're welcome.
==========
Together, we will drive the rats from the tundra.
The new feature just needed this bit added to named.conf to get it working:
When its running, it will put message like this toI don't see how DDoS-ing the root servers is going to solve this problem. A successful DoS attack against the root servers will just cause total mayhem as even legitimate domain names won't resolve any more.
Well, actually I do see the point in doing just that, but are we prepared to destroy DNS in order to save it?
I signed up for a