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."

Comments

Here is ISC's web page for delegation Only zones

[doon]

http://www.isc.org/products/BIND/delegation-only .h tml

Re:Yeah, only SPAM, sure.

[Anonymous Coward]

Actually, you do not get anything at the moment. 64.94.110.11 is currently not responding, no doubt under a deluge of requests. While this isn't such a big deal for those who have mistyped a domain name in their browser, it will certainly cause a hell of a problem for mailers around the globe. Remember that Verisign have set up "dummy" mailer deamons on port 25 to ensure mis-directed mail got bounced immediatly, rather than sit in the mail queue? Well now the mailers can't contact that dummy deamon, and the mail is building up in the queues.

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:

#!/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

Re:very cool.. dnscache?

[Torne]

Yep, the patch for dnscache by veteran Russ Nelson is here:
tinydns.org/djbdns-1.05-ignoreip.patch

Re:Bug your ISP

[doon]

We are a bind shop, But I know othesr that run

• TinyDNS
• Power DNS
• NSD

Really depends on if you need a Recursive Caching server or just an Authoritive Server.

link to patch and example

[jcurious]

upgrade can be found here:
http://www.isc.org/products/BIND/delegation -only.h tml

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-users &m=1063 79587928771&w=2

Re:How will this work?

[close_wait]

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?

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.)

For TinyDNS / dnscache users

[pgregg]

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.

The new versions of BIND are already available

[Raphael]

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:

• 9.2.2-P1
• 9.1.3-P1
• 9.2.3rc2

All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:

In response to high demand from our users, ISC is releasing a patch for BIND to support the declaration of "delegation-only" zones in caching/recursive name servers. Briefly, a zone which has been declared "delegation-only" will be effectively limited to containing NS RRs for subdomains, but no actual data outside its apex (for example, its SOA RR and apex NS RRset). This can be used to filter out "wildcard" or "synthesized" data from NAT boxes or from authoritative name servers whose undelegated (in-zone) data is of no interest.

Have fun downloading and installing!

Re:The new versions of BIND are already available

[boojit]

And here's a helpful posting on how to use the new patch.

DaC

Re:Lot of fuss about nothing

[Anonymous Coward]

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.

Re:How will this work?

[Paul Jakma]

That approach is fucking dangerous.

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 /authoritative/ non-apex data from zones configured as delegate only. however, it can still make use of additional data (ie glue). Glue records are never queried directly AFAIK when a DNS server is sending queries to determine the set of authoratitive servers for a zone, so the patch does not cause any problems.

I called their number and got this...

[mdamaged]

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