[conspire] DNS vulnerability details

[Rick Moen]

Quoting Eric De MUND (ead-conspire at ixian.com):

> Ok, in repeated tests, I'm getting 2/3 POORs and 1/3 GOODs for source
> port randomness, and all GREATs for transaction IDs. This is Comcast.
> 
>     DNS Resolver(s) Tested:

Please don't read this as a complaint, but rather as a caution about
terminology:  Most people reserve the term "DNS resolver" to refer only
to the DNS _client_ piece (the one that on Linux is built into libc and
has conffile /etc/resolv.conf).  Being careful about terminology can
help avoid confusing one's self.

>     1. 68.87.76.179 (sjos-cns01.sanjose.ca.sanfran.comcast.net)
>        appears to have POOR source port randomness and GREAT transaction
>        ID randomness.
> 
>     2. 68.87.76.181 (sjos-cns03.sanjose.ca.sanfran.comcast.net)
>        appears to have POOR source port randomness and GREAT transaction
>        ID randomness.
> 
>     3. 68.87.78.131 (utah-cns01.saltlakecity.ut.utah.comcast.net)
>        appears to have GOOD source port randomness and GREAT transaction
>        ID randomness.

As I said, ISP nameservers in general really suck.  I'm not at all
surprised that Comcast isn't on the ball.

> So what DNS-related debian package(s) do I need to get and run?

On Debian, just "bind" (http://packages.debian.org/etch/bind).  You can
optionally grab "bind-doc" if you want a whole lot of informative stuff
that you'll probably never read put into /usr/share/doc/bind-doc/ .  ;->

Debian constructs a quite reasonable default /etc/bind/named.conf file 
(BIND9's configuration file), in such a way that hardly anyone needs to
touch it -- because it references as "include" files two others that
local admins can put all their local configuration in:

/etc/bind/named.conf.options :  This is where you put things like what
                                IPs are permitted to query the nameserver
                                for various sorts of nameservice.
/etc/bind/named.conf.local   :  This is where you'd put stuff related
                                to zones for which you want BIND9 to do
                                authoritative service, e.g., if you felt
                                like registering ericdemund.com and doing 
                                its authoritative DNS from your home 
                                machine.

Here is my own (BIND9) nameserver's /etc/bind/named.conf.options :


options {
	directory "/var/cache/bind";

	// If there is a firewall between you and nameservers you want
	// to talk to, you might need to uncomment the query-source
	// directive below.  Previous versions of BIND always asked
	// questions using port 53, but BIND 8.1 and later use an unprivileged
	// port by default.

	// query-source address * port 53;

	// If your ISP provided one or more IP addresses for stable 
	// nameservers, you probably want to use them as forwarders.  
	// Uncomment the following block, and insert the addresses replacing 
	// the all-0's placeholder.
	version     "Shirley, you're joking";

	forwarders {
		198.144.192.2;
		198.144.192.4;
		// 209.81.9.1;
		// 165.90.49.12;
	};
	auth-nxdomain no;    # conform to RFC1035

        allow-recursion {
        127.0.0.0/8;
	192.168.0.0/24;
	10.0.0.0/8;
	198.144.195.186/29;
        };
	allow-query {
        127.0.0.0/8;
	192.168.0.0/24;
	10.0.0.0/8;
	198.144.195.186/29;
        };
};

logging {
category lame-servers {null; };
};


One important thing to note is the "allow-recursion" and "allow-query"
rosters:  Those are (respectively) the ranges of IP addresses permitted
to send recursive-resolvers queries, and those permitted to send it
queries of any sort.

Also, note the commented-out "query-source address * port 53;"
statement.  This is where you can _deliberately lock_ your nameserver to
originate queries from a specific port address -- which we've known for 
many years is an extremely bad idea.  (The asterisk is where you could
specify which of your machine's IP addresses the queries should say they
come from, in the case of a machine with multiple IPs.)

People upgrading their existing BIND9 nameservers for the July 8 patches
need to check manually to ensure that such a line hasn't been activated
-- because its presence negates the benefit of the upgrade (which adds
support for randomised source ports!).

The BIND near-monopoly has been rather bad for DNS, over the years, so
I've kept an eye on alternative nameservers for a long time, here:
"DNS Servers" on http://linuxmafia.com/kb/Network_Other/ .

One of the things the world really needs is a bulletproof, easy-to-use 
recursive-resolver nameserver that does only that.  (The BIND
near-monopoly has gotten people lulled into thinking that DNS service is 
all one big, homogeneous thing, which it is not.)  Dan Bernstein's
"dnscache" (one component of the djbdns suite) qualifies in some ways,
except it's rather peculiarly designed, and I suspect it's
novice-hostile.

MaraDNS might qualify, but is untested by this reporter.  Nick Moffitt
tried it some years ago, and didn't have a good experience.

"Unbound" is extremely promising, and I have high confidence in its
authors, but is absolutely brand new, and again I've not tested it at
all.