BIND Strikes Back Against VeriSign's Site Finder 582
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."
Excellent! (Score:5, Insightful)
Office of Homeland Insecurity (Score:4, Funny)
"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.
Good for BIND (Score:5, Insightful)
Re:Good for BIND (Score:5, Funny)
Re:Good for BIND (Score:3, Informative)
It's a federal offence to redirect a misspelling to a porn site as it's "illegal to deceive children into viewing harmful material". This is a provision of the "Amber Alert" legislation and will land you in jail for 4 years.
Relevant Link [geek.com]
Re:Good for BIND (Score:3, Funny)
Re:Good for BIND (Score:5, Interesting)
So how does whitehouse.com get away with it? (i'm not going to make the name a link, I do not want to link to pr0n on /.).
Re:Good for BIND (Score:3, Informative)
Read this amendment to H.R. 1104 [gop.gov]:
Re:Good for BIND (Score:5, Interesting)
I hope BIND makes it configurable enough to kill off the .cc and .ws wildcards as well.
Re:Good for BIND (Score:5, Insightful)
I can't help but think of the contraversy over deep linking and how all those stupid suits could have been avoided if server operators would have just detected the referer header and bounced deep links back to the home page...
Re:Good for BIND (Score:5, Interesting)
Explain how they are in violation of the Anti-Cybersquatting laws, and have broken their contract with the Department of Commerce regarding the whois database. Mention how it's abuse of a monopoly power.
Make the states get involved, not the private attorneys.
Re:Good for BIND (Score:3, Interesting)
The problem with using referer headers is that not all clients provide them. Some people may be using an archaic browser which doesn't send the field, some people may have just typed the URL straight in to the address bar rather than being referred from another website, and some people just plainly disable them for privacy reasons.
Of course, most lawyers won't understand these principles, but for us web development geeks, there's no sense in blocking legimate users just by one single HTTP header which
Re:Good for BIND (Score:5, Insightful)
If someone is so gung ho about privacy that they disable the referer header and refuse cookies, then they must accept that sites with policies that require them to come through the front door and accept a token will be unavailable to them. Publishers are under no obligation to provide their material without at least a nominal quid pro quo from the user.
Re:Good for BIND (Score:3, Insightful)
The technical workaround is good, but I think this is one rare case where legal action might be reasonable.
If you don't want deep linking, you're objecting to how various random individuals on the internet interact with your computers. You should restrict that interaction on your own computer and not whine about the rest of the world.
Verisign are not some random external party - they exclusively control chunks of the internet infrastructure. They should be held to a higher standard of behaviour.
Of cou
How will this work? (Score:3, Interesting)
Of course, hopefully this and public opinion will actually cause VeriSign to rethink the whole operation. (We can at least dream)
Re:How will this work? (Score:5, Insightful)
I'd say that's quite an assumption. Were I coding this patch, for example, the IPs for which to return NXDOMAIN would be specified in a config. That config would be able to take single IPs and also ranges.
I wouldn't write this off as ineffective yet. We need to see what methodolgy is being chosen before we can comment on its technical effectiveness.
Cheers,
Ian
Re:I am glad you're not patching (Score:4, Funny)
You'll forgive me if I don't exactly hang my head in shame.
Cheers,
Ian
Re:How will this work? (Score:5, Informative)
No, the patch doesn't do filtering in that sense. It just allows you to mark some zones in your BIND config file (such as .com and .net), that should only contain delegation information. So basically if your BIND server recieves back A record(s) rather than NS delegation records from a server authoritative for .com , BIND simply ignores it.
Simple and elegant, and nothing Verislime can do about it. (I hope.)
Re:How will this work? (Score:3, Insightful)
Why? Glue records. You are _meant_ to receive certain As from the parent servers of a domain delegated to nameservers which live within its own namespace.
For example, let's say I have the domain movezig.com. I fill in a host template to for the two nameservers, base.movezig.com (3.214.8.19) and cats.movezig.com (3.217.21.40), then delegate it to those nameservers. Obviously, if the
Re:How will this work? (Score:5, Informative)
Why? Glue records. You are _meant_ to receive certain As from the parent servers of a domain delegated to nameservers which live within its own namespace.
However, you're missing a crucial part: when you ask the delegating server for the NS records, the glue A records are given out in the additional section, not in the answer section.
The ISC patch disregards
Re:How will this work? (Score:3, Interesting)
Right now verisign has the equivalent of, in the
Now, it seems to me that it would be really simple for them to change that to something more like:
(and, of course, a wildcard A record in ns.searchstation.com)
To me, it looks like the only way to get around this more permanently is to have BIND check periodically for some known-not-to-exist domain name
Bug your ISP (Score:5, Interesting)
Interesting that BIND only runs 80% of DNS servers, what is the other 20% made up of?
Re:Bug your ISP (Score:3, Informative)
Or they are like me and use djbdns, and won't go back..
There is a patch for djbdns, but they're not official so I wouldn't reccomend blindly using them.
Re:Bug your ISP (Score:4, Informative)
Re:Bug your ISP (Score:5, Informative)
-
TinyDNS [cr.yp.to]
-
Power DNS [powerdns.com]
-
NSD [nlnetlabs.nl]
Really depends on if you need a Recursive Caching server or just an Authoritive Server.Re:Bug your ISP (Score:3, Funny)
Re:Bug your ISP (Score:3, Interesting)
Better yet (and I could very well be wrong here) I'd like to see a patch that would force all TLD's to be delegate only. I don't know of any examples off han
Re:Bug your ISP (Score:4, Informative)
include "named.delegation-only [clubneon.com]";
the patch (Score:3, Informative)
I'm asking because the wording is quite hard to understand as my main language isn't english
Re:the patch (Score:5, Interesting)
Clever solution. They rigged it so that you can declare the
So, if BIND makes a non-recursive query for www.verisign-is-really-bad.com from a server authorative for
Verisign could work around this by replacing the A record with a wildcard NS record pointing to ns.sitefinder.verisign.com or some such, and then having that new name server return an IP address for any query made of it.
The question is: is Verisign willing to escalate the matter or will they back off?
Here is ISC's web page for delegation Only zones (Score:5, Informative)
http://www.isc.org/products/BIND/delegation-onl
Internet standards humor alert (Score:5, Funny)
Isn't that what caused the problem in the first place?
Thanks, I'll be here all week!
Re:Internet standards humor alert (Score:5, Funny)
Disgusting coffee mug (Score:3, Interesting)
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...
Is a Technology solution ALWAYS better than law? (Score:5, Interesting)
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...
TRUST (Score:5, Insightful)
Had trust. Who can take them seriously now?
Re:Is a Technology solution ALWAYS better than law (Score:3, Interesting)
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.h tml [iab.org]
(which was posted in the first slashdot thread abot this topic), went unnoticed, and unheeded by Verisign.
Big
Re:Is a Technology solution ALWAYS better than law (Score:5, Interesting)
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.
link to patch and example (Score:5, Informative)
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
For TinyDNS / dnscache users (Score:5, Informative)
Russell Nelson has a patch [tinydns.org] for tinydns [tinydns.org] which does the same thing.
He also notes that several other TLD operators for the same thing and has another patch [tinydns.org] that allows you to do the same thing to several naughtly tld operators at once.
The new versions of BIND are already available (Score:5, Informative)
Although the news are not on the BIND page [isc.org] 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!
Re:The new versions of BIND are already available (Score:5, Informative)
DaC
MX Problems (Score:5, Insightful)
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.
Re:MX Problems (Score:5, Interesting)
Re:MX Problems (Score:5, Insightful)
Some improvement! Patches to BIND aren't the answer. Verisign need to be made to stop breaking the internet.
There's been this silly thread in this conversation that stakes out two sides. Either a) fix anti-social, monopolistic behavior with technology, or b) fix it with laws and legal action. This is a moronic dichotomy. A technological solution mitigates the immediate problem while the lawyers have time to file their briefs and sort out the damage done. A combination of technical solutions and legal action is a possibility and even a sometimes a Good Thing, not some binary choice.
Talk to a lawyer... (Score:3, Insightful)
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.
Who will agree? (Score:5, Interesting)
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 [djbdns.org] available.
ISPs Will Soon Send You To Their Own Site (Score:5, Interesting)
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
Who cares? (Score:3, Funny)
Link rotation? (Score:4, Interesting)
It's a trick... (Score:5, Funny)
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
Sign the online petition to get ICANN into action (Score:5, Interesting)
http://www.petitiononline.com/icanndns/ [petitiononline.com]
Mozilla developers (Score:3, Funny)
Re:Sign the online petition to get ICANN into acti (Score:4, Insightful)
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.
Have your say (Score:5, Interesting)
Is Stratton D. Sclavos doing a good job as CEO of Verisign? Vote yes or no in this Forbes.com poll [forbes.com].
Also, here's a petition [petitiononline.com] that may also be of interest.
Re:Have your say (Score:4, Informative)
But for how long (Score:4, Interesting)
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.
Re:But for how long (Score:3, Informative)
Re:But for how long (Score:3, Insightful)
What the patch does is saying that if I query server Foo, running this version of Bind, and Foo has to go and ask Bar about it, Foo will only consider delegation data from Bar, not other resources.
So if Bar sends NS and SOA records back, all is well, and Foo happily tries to ask the delegated servers to resolve the name. If Bar sends an A record back, Foo will ignore it, and report a failure to the client.
Problem w
use their T&C against them... (Score:5, Interesting)
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
Google (Score:5, Funny)
NOT!
Not Trustworthy (Score:5, Interesting)
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.
Inreased Bandwidth Usage and Other Porblems (Score:3, Interesting)
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?
Who should I write? (Score:5, Interesting)
Petition Verisign to change (Score:5, Informative)
I called their number and got this... (Score:5, Informative)
sitefinder@verisign-grs.com
Re:Sqatting (Score:5, Interesting)
The .nu [whatevercrap.nu] domain registry has been doing this for years.
Re:Yeah, only SPAM, sure. (Score:5, Informative)
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:
Re:Yeah, only SPAM, sure. (Score:4, Interesting)
Re:Yeah, only SPAM, sure. (Score:5, Funny)
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
Re:Yeah, only SPAM, sure. (Score:5, Funny)
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 [dopesmokin...philes.com], as referenced by this Internet Web site they have registered. Let's not forget they're also a bunch of Clueless DNS whores [cluelessdnswhores.com]. Oh yes, and I heard Verisign supports terrorists at this page: here.. [weloveinte...rorism.com].
Verisign needs to be shut down for these un-American and clearly criminal web sites. Someone notify John Ashcroft, quickly!
Re:Yeah, only SPAM, sure. (Score:5, Insightful)
Patched BIND is an elegant solution (Score:4, Informative)
The new feature just needed this bit added to named.conf to get it working:
When its running, it will put message like this toRe:Yeah, only SPAM, sure. (Score:5, Insightful)
* 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.
Re:Yeah, only SPAM, sure. (Score:3, Informative)
*Sigh*. I never get to have any fun...
Re:Yeah, only SPAM, sure. (Score:5, Funny)
Exactly. The correct term for this is Sldahost efcfet [slashdot.org]
Re:could NOT care less you idiot (Score:4, Informative)
It's the other way around. Hormel has a trademark on 'SPAM' and would prefer UBE to be called 'spam'. See the SPAM website [spam.com] for more info.
Re:Yeah, only SPAM, sure. (Score:3, Interesting)
Re:Yeah, only SPAM, sure. (Score:5, Informative)
Doesn't work for me...then again, I've already fixed djbdns [cr.yp.to] here to return NXDOMAIN when a lookup resolves to Verisign's squatter page. (A copy of the patch is here [alfter.us] (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 [alfter.us]. To use the ebuild, you'll also need to copy Manifest and files/1.05-errno.patch from /usr/portage/net-dns/djbdns.)
Re:very cool.. dnscache? (Score:5, Informative)
tinydns.org/djbdns-1.05-ignoreip.patch [tinydns.org]
Re:very cool.. dnscache? (Score:3, Informative)
names.tinydns.org/djbdns-1.05-ignoreip2.patch.
Patches (Score:5, Informative)
Patches for DJBDNS and lots of other daemons here [imperialviolet.org].
Re:very cool.. dnscache? (Score:5, Informative)
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.
Re:very cool.. dnscache? (Score:3, Insightful)
Re:ISC ROCKS (Score:5, Interesting)
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.
Re:Sounds great (Score:4, Interesting)
Good questions.
As for splitting, there are already several alternate roots. In addition to Alternic, there's OpenNIC [unrated.net] and Pacific Root [pacificroot.com]. 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.
Re:Soundex into BIND! (Score:5, Insightful)
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.
Re:Soundex into BIND! (Score:3, Informative)
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 [dns.net]
Re:Soundex into BIND! (Score:3, Informative)
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.
Re:Soundex into BIND! (Score:4, Informative)
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
Re:didn't they already do that? (Score:5, Insightful)
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!
Re:Advice on switching to another registrar (Score:5, Funny)
John.
Re:Lot of fuss about nothing (Score:5, Informative)
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.
Re:Lot of fuss about nothing (Score:5, Informative)
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).
Re:Lot of fuss about nothing (Score:4, Insightful)
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...
Re:Lot of fuss about nothing (Score:3, Interesting)
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
Re:Has anyone.. (Score:5, Insightful)
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.
Re:What about the other 20%? (Score:5, Informative)
Re:It bears repeating (Score:5, Informative)
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.
offtopic? i think not. (Score:5, Informative)
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.