Slashdot Mirror
Paul Vixie And David Maher On VeriSign Wildcarding
chromatic writes "The O'Reilly Network has just published an interview with Paul Vixie, chairman of the board of the Internet Software Consortium and a primary author of BIND. Topics include the recent VeriSign controversy, ISC's BIND patch in response, and other potential issues that might come to light in the near future." On a related note, dmehus writes with a link to the letter sent by David Maher, chairman of the Public Interest Registry -- the .org registrar, to ICANN President and CEO Paul Twomey. "The letter says that it supports ICANN's call for VeriSign to voluntarily suspend SiteFinder and the Internet Architecture Board preliminary position paper. It goes on to say that PIR will not be implementing any DNS wildcard to the .ORG zone. It urges ICANN to stand its ground, but also to implement a policy preventing registries from taking this kind of unilateral action in the future." The letter is in .doc format, but AbiWord and OpenOffice.org both open it fine.
Get your Patched BIND for Slackware here:
The more ISPs that use this, the more uncommon the SiteFinder 'service' becomes---the less users expect it.
Remember when popups where not expected? After using mozilla for a while I simply cannot stand them now!
---
Ad Majorem Dei Gloriam
Interested in AI? MACR
Though I agree with everything he said (and thought he did so quite eloquently), it's a bit disheartening to see the chairman of the ISC refer to NXDOMAIN as a 404.
Dr. Paul Twomey
.ORG domain, supports ICANN's call for the voluntary suspension of VeriSign's deployment of a DNS wildcard service. We believe that ICANN (and the entire Internet community) should take steps to prevent all registries from unilaterally implementing changes to DNS that redirect requests for invalid domain names to any other site. PIR will not offer any service that makes such a change in the DNS.
... is not
.COM and .NET domains.
.COM and .NET TLDs by adjusting servers to respond to requests for non-existent domains with a reference to the VeriSign Site Finder web site, (in other words, "wildcarding"). To a requesting user, it appears that non-existent domains are valid, because they are directed to the Site Finder. There is no difference between the responses for valid domains versus invalid domains from VeriSign's TLD servers.
.COM and .NET TLDs, the most prevalent of the TLDs, Internet users have little protection against the imposition of this flawed system. VeriSign implemented the Site Finder system with little advance notice or public commentary by the Internet community. We believe such unilateral behavior in changing a critical resource necessary for the world's information systems is inconsistent with the responsibilities of registries under their contracts with ICANN, particularly because of the necessity of DNS for other Internet resources to function properly.
President & CEO
ICANN
4676 Admiralty Way
Suite 330
Marina del Rey, CA 90292
September 22, 2003
Dear Paul,
Public Interest Registry (PIR), the operator of the registry of the
PIR also supports the Internet Architecture Board (IAB) statement on the same subject as set forth at:
http://www.iab.org/documents/docs/2003-09-20- dns-w ildcards.html
DNS is a critical piece of Internet infrastructure. Internet services such as the WWW and Email rely on DNS to function, and there should be no interference with the established protocols until there is complete assurance of no negative impact on the DNS.
In another context, the Internet Architecture Board (IAB) has commented:
"At the core of all of the IAB's concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet's infrastructure that converting it to an application-based search service
Page 2
appropriate even in the case where the query presented would not normally map to a registered domain."
The architectural principle referred to by the IAB is clearly violated by the changes proposed for the
On Monday, September 15, VeriSign changed the behavior of the
Because the VeriSign Site Finder server makes it appear that a non-existent domain exists, the service introduces significant problems to critical Internet infrastructure. Many other important Internet protocols rely heavily on proper DNS behavior. The impact of VeriSign's Site Finder is unclear with respect to security of the DNS. Site Finder unilaterally precludes the use of a prevalent type of anti-spam mail filter that uses DNS to validate the domain of legitimate eMails.
Because VeriSign's servers are authoritative for the
We are informed that other domain registries may be exploring services similar to the VeriSign Site Finder. (As noted above, PIR will
Page 3
not be one of them.) If this is the case, our comments concerning Site Finder apply with equal force to those other services. We believe that any such efforts to alter the TLD DNS systems, of which the VeriSign Site Finder appears to be the most prominent example, adversely affect the Internet infrastructure and the entire Internet community.
Therefore,
Carousel is a lie!
register.com lost a suit similar to what you are talking about.
when you buy a domain from rcom, your page automagically defaults to a page. This page is pretty much an advertisement for rcom and such. it drives revenue towards rcom.
many MANY people thought this was crooked, so there was a civil suit.. which rcom lost.
I couldn't see a case like this wouldn't run the same, since both the rcom parked-page service and this have search links and nifo that drive revnue to their respective companies...
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
In the case of a spell checker if it sucks you get to use another product with a better one.
You don't get to in this case.
Also all the world is not http... the protocol level is the worst possible place to do this.
a second note:
:\
if i register abacadaba.com, and abacadaba.com becomes the biggest thing next to yahoo and slashdot combined with sex.com... everyone would want to go to abacadaba.com, or so i hope.
all mispellings on my idea, and my trademark if ihave it trademarked, will go to versign. they'd effectively be making money off of me via a transitive property.. sorta. people want to see my site which makes money, verisign takes all mispellings of my site.. people make verisign money!
whoa.. i think i just proved step 2
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
By email, phone, fax, telegram, or letter (or better, several of these), let them know what you think. These are the people who can give Verisign reasons to change their behavior.
It's now here having been Slashdotted last time....on a better server this time, though (we hope!), so be gentle....
It's good to see that PIR is taking the high road. If .com/net are ever redelegated, I'd much rather they run it, than someone who would be looking for every opportunity to squeeze out nickels and dimes ($100 million/yr!) from the internet community, via abuse of their monopoly. Or, perhaps a corporation with a solid reputation (maybe IBM?) would step up, to replace Verisign.
As has been said numerous times, this has nothing to do with the "root" servers, only the com and net TLD servers. ISC has already produced a very nice fix for Bind 9 so this doesn't really affect people using it anymore. Just designate the com and net zones as designate only and you won't pick up any A wildcard records. Let Verisign do stupid shit like this and watch as people work around them within 24 hours.
The problem is that Verisign is doing their wildcarding at the DNS level. This effects the entire *internet*, not just the World Wide Web. So not only do you get directed to their site on your web-browser, but also if you lookup domains for telnet, ftp, ssh, smtp, etc. This causes problem for (among other things) spam filters, who check that your domain exists (well, now *all* .com domains exist) before delivering mail.
Verisign is being extremely short-sighted. This whole deal reeks of a moronic manager who thught this would be a 'wonderful' idea.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Verisign can break Vixie's patch. All they have to do is set up a separate name server which pretends to be a .com and .net server, with the very same wildcarded A-record. Now just put in wildcarded NS-records in the actual .com and .net zones in the real GTLD servers (in place of the existing wildcarded A-record). There, now it really looks like a real delegation to a different name server, just like real domains have. The new delegated wildcard server gets the query next, due to the delegation (that looks like a delegation, hence fools the patch), and due to its wildcard (and it doesn't need any other data from the .com or .net zones, since it doesn't get delegated to for real domains), it will answer with an A record of Verisign's choosing. If Verisign wants to keep doing what they are doing, they can defeat this patch by that method.
Then we'll have to make DNS servers filter out specific delegations (as opposed to filtering out non-delegation records where there should be only delegations). Verisign could rotate those delegations daily and fool efforts to block it.
now we need to go OSS in diesel cars
deb http://www.backports.org/debian stable bind9
I wonder which one of these characters made this mess happen?. html
http://www.verisign.com/corporate/about/executive
Forget thrust, drag, lift and weight. Airplanes fly because of money.
You're just trollin'.
VeriSign's mail server is called the Snubby Mail Rejector Daemon v1.5
v1.3 wasn't fully SMTP compliant: See here.
v1.5 now responds a little more properly: See here.
It rejects them anyway.
plain old text mangles my post a bit, so here it is again. Sorry I didn't catch it in preview...
I believe that Verisign's use of a wildcard to map all DNS requests for *.com to their web site violates the relevant RFC's.
Going through all of the DNS RFC's, all of them assume or require that when a name is not found, the DNS server return an error.
Going through them in historical order: RFC 811 specifies that if the name is not found, a 'NAMNFD' code is returned. RFC 1034 also talks about sending "a name error indicating that the name does not exist" and "A name error (NE). This happens when the referenced name does not exist. For example, a user may have mistyped a host name." It also discusses caching name errors for efficiency, which of course only makes sense if the authoritative DNS servers actually issue name errors (which Verisign is now not doing). RFC 1035 specifies that if "the domain name referenced in the query does not exist" that a "Name Error" be returned.
There is a wildcard mechanism in RFC 1034, but it's defined to apply to '"*.<anydomain>", where <anydomain> is any domain name' which makes it pretty clear to me that it's not intended to apply to domains. To emphasise this, all of the examples of DNS wildcards are of the form *.X.COM or *.A.X.COM.
Enable 3D printed prosthetics!
Any host can make non-recursive requests to the root servers.
Technically, if a query for whatever.com arrives at a root server, it should only return the list of NS records for .COM, and if a query for whatever.com arrives at an authoritative server for .COM (many roots are also .COM servers), it should only return the registered NS records for whatever.com.
In fact, that is exactly the problem -- the Verisign roots should return only NS or NXDOMAIN records, but for names in .COM .or .NET, they instead "synthesize" an A record, pointing to sitefinder, with a 15 minute TTL (cache lifetime).
The various hacks either ignore the specific A record, or ignore records from root servers other than NS. The latter is a cleaner approach, IMHO.
I do not deploy Linux. Ever.
Skapare writes:
I run my own root on most of my networks and employers' networks -- it's easy to implement and more efficient. (That said, we do it for security, to keep lookups for bogus TLDs from going out over the internet.) Overriding "." on your own nameserver is easy, as the delegation information for BIZ/INFO/COM/NET/ORG/UK/TV/etc is easy to obtain and doesn't change very often. Overriding the TLDs themselves, going from serving "." to serving ".COM", is a much more difficult project.Unlike the "." root zone, the .COM zone changes twice a day, is HUGE, and the zone file itself is not readily available to the general public.
I do not deploy Linux. Ever.
Not done yet? Uh huh, keep reading.
Fine, I'll snip out the relevant parts for you:
Congratulations! You've just given up your rights to anything you've ever written! Block this service, now, and you have a good chance of convincing the court you didn't agree to the terms. Otherwise, I wouldn't bet my entire life history's worth of recorded works on it.This is one of the most evil things I've ever seen done.
Actually, Christmas Islands already does something very similar to this. Try pigse.cx. You will end up at a "sitefinder"-like page from the Christmas Island TLD Authority which suggests that you register the domain, explaining that all unregistered domains in .cx are redirected to that page. It does not return NXDOMAIN, but there are no commercial advertisements (other than by C.I.) and no search function.
I am a geek attorney, but not your geek attorney unless you've already retained me. This is not legal advice.
Why? Well firstly, .musuem is a highly restricted domain, and secondly it's all to do with how museums operate. If I go to the London Science Museum and start asking for paleontology information, they will redirect me across to the National History Museum. The wildcarding is just a virtual way of helping people find what they are looking for, which makes sense.
".com" on the otherhand, is a largely unregulated free for all of firstcome first served registrations and lawsuits, trying to apply a structure to that is insane. A good analogy I saw from another poster here on Slashdot was the difference between the alt.* and comp.sci.* heirarchies on Usenet. Do *you* want to try being a moderator on .alt?
UNIX? They're not even circumcised! Savages!
Arg, why does everyone says this removes 404's. You need a webserver to return a 404. Before wildcarding you didn't hit a websserver so no 404. And you can still get a 404 by hitting a page that doesn't exist on a webserver that does.