[conspire] DNS vulnerability details
rick at linuxmafia.com
Mon Aug 4 13:19:15 PDT 2008
(Getting back to your question from yesterday):
Quoting Eric De MUND (ead-conspire at ixian.com):
> Please educate me if I've missed anything in phase 1. In particular,
> given "GREAT" test results in step d, below, why might I still need to
> install BIND on any of the SOHO systems behind my router?
> d. From all three systems behind the router (2 x debian 4.0r4 +
> 1 x Mac OS X 10.5.4), I ran the [Test My DNS] test at
> <https://www.dns-oarc.net/oarc/services/dnsentropy>. All tests
> DNS Resolver(s) Tested:
> 1. 22.214.171.124 (bld1.pao.opendns.com) appears to have GREAT
> source port randomness and GREAT transaction ID randomness.
That's always nice to know, but actually has very little to do with the
Dan Kaminsky-reported DNS nameserver vulnerability, _because_, for good
or bad, those resolver libraries are not caching recursive-resolver
Although it's A Good Thing for any software that originates a recursive
query to randomise its source port, the only attack targets of
significant concern are _caching_ nameservers (that do recursive service).
o Your Debian and MacOS boxes -- being TCP/IP-capable -- have DNS
resolver libraries (DNS clients). Neither of those OSes' libraries
is particularly competent at randomising their UDP ports on outgoing
DNS queries whose recursive bits are set, _but_ results received
back are not cached. So, there's very little payoff to a theoretical
attacker from sending them forged responses with cache-poisoning data
-- there being no cache to poison. Get it?
If there were a patch to fix those two OSes' resolver libraries,
that would be A Good Thing. The one in Linux glibc is a bit of
dismal code taken from <shudder> BIND8, for which, for now, there is
no replacement. And there's been not a peep out of Apple about
prospects for fixing their resolver library.
o I gather that your Linksys runs dnsmasq. dnsmasq
is a basically fairly decent DNS forwarder (and DHCPd) for small
networks (usually behind NAT). Fairly decent, except that the
author (originally) fscked up the way it forwards received recursive DNS
queries, failing to randomise the source ports. (By comparison,
the somewhat similar pdnsd package got that point right.) It's
recently been patched, adding Dan Bernstein's "SURF" random-
number generator, starting with v. 2.43. (Current is 2.45.)
It's important to note that dnsmasq _does_ do caching of received
responses. So, if an attacker were to succeed in sending it
forged responses with cache-poisoning data in the ADDITIONAL
INFORMATION section of the response, that would be a problem.
So, the improvement in query algorithm starting with 2.43 _is_
significant for security. So, it's good that you applied the
dd-wrt distro's v24 SP1 update.
I have no idea whether dd-wrt runs dnsmasq on the outside interface
or the inside, NATted one. On the outside would make more sense.
o Queries from the two OSes' resolver libraries (DNS client pieces) have
to traverse your Linksys router's NAT/IP-filter layer. At some
point, either before or after NAT translation, they pass through
dnsmasq. Anyway, dd-wrt's algorithm for generating source UDP ports
is likely to be also security-significant. Which raises the
question: How good _is_ that? (You have no data on that question.)
You appear to have the Linksys configured to forward all outbound
DNS requests out to OpenDNS's public nameservers, 126.96.36.199
and 188.8.131.52 (resolver1.opendns.com and resolver2.opendns.com).
You applied the Web-based test of source-port randomness to
OpenDNS. Wouldn't it be also relevant to test the outside IP of
In any event, to recap:
1. You have poor source-port randomisation on Debian and MacOS,
but that doesn't matter a great deal because they don't cache. In an
ideal world, those OSes' shoddy DNS-client software would get junked and
replaced. Some day.
2. Those client libraries forward to the Linksys/dd-wrt gateway, which
at least has dnsmasq patched to do decent port randomising -- important
because it caches data. dd-wrt v24 SP1's _own_ port randomising quality
is unknown and untested.
And the Linneus Bottomus:
3. You've outsourced all your (non-cached) DNS queries to OpenDNS.
(That is, your installation of dnsmasq has that San Francisco firm's two
public IPs specified as its forwarders.)
Personally, I would _not_ outsource my DNS. To anyone. I would (and
do) run my own caching recursive-resolver nameserver. dnsmasq does not
qualify because _it_ does no recursive service: It merely forwards all
such queries to an IP you specify.
And, no, I would not (for new installations) run BIND9. I wish people
would stop thinking of BIND as synonymous with nameservers. Even BIND9,
which ended the perennial security nightmares of BIND8, is a slow,
bloated, overfeatured, monolithic piece of garbage. There are much more
suitable, tailored, alternatives. (See prior e-mail.)
To expand on one of several reasons I would avoid OpenDNS: They break
the RFC-mandated requirement to return NXDOMAIN (no such domain) on
non-existent FQDNs. Notice what happens when one asks a _reasonable_
nameserver (mine) about a non-existent domain:
:r! dig i-dont-exist.com @ns1.linuxmafia.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24606
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1217879779 1800 900 604800 900
Note underlined "status" return value. (It's "NXDOMAIN" = Non-eXistent
DOMAIN", get it?)
Now, compare what one gets from OpenDNS:
:r! dig i-dont-exist.com @resolver1.opendns.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
i-dont-exist.com. 0 IN A 184.108.40.206
The return values are the NOERROR result code and (the actual response)
IP address 220.127.116.11.
How can this be? It doesn't actually exist, so shouldn't the correct
response be NXDOMAIN? Yes, but OpenDNS's business model requires that
they break the RFCs.
Why 18.104.22.168? Because that's where they've put up a Web server
that returns advertising, on any DNS lookup that _would_ otherwise
This is of course exactly what we all beat up Verisign over (the
"Sitefinder" fiasco) -- with the distinction that, in OpenDNS's case,
nobody's being forced to use lobotomised DNS: You have to volunteer for
it by pointing your queries it their nameservers, deliberately.
The alternative is, of course, to run a local caching recursive-resolver
nameserver. I've already suggested that, and you've thus far elected
not to do it. It would avoid breaking the RFCs for no better reason
than feeding OpenDNS's business model, it would give you better
performance, it would avoid massive privacy loss, and it would
put your DNS and its security under _your_ control instead of OpenDNS's.
 However, Apple rolled out the July 8 BIND9 "P1" patches into one of
their omnibus security updates, a few days ago. (Most MacOS users
do not elect to enable BIND9, so this doesn't make a difference to most
MacOS users' security, and does nothing about the client resolver
library, but it does show that Apple are fairly on top of the recent
In fairness, there would _not_ be a peep out of Apple about prospects
for replacing the OS X DNS resolver library, even if it were due out
this afternoon, because they do not comment about upcoming software,
including security updates, until release time.
 Because you really weren't very clear on this, at first reading I
assumed that you meant one of your _Debian_ boxes was running dnsmasq,
rather than the Linksys.
 I do currently run BIND9, for both recursive-resolver caching
service and for authoritative service. I would not select it for either
role, in any new installations. NSD is an absolutely superb
authoritative server. I'm not sure which way I'd jump for the
recursive-resolver caching portion: I'd consider Unbound, PowerDNS
Recursor, the non-authoritative portion of MaraDNS, _and_ even DJB's
dnscache. I have high hopes for Unbound, as it's from the NSD people
-- but it's brand-new.
 Fully-qualified domain names.
More information about the conspire