Just to be clear, would regular clients (Macs, Windows, Linux) behind a NAT firewall (e.g. a Netgear, Linksys or similar routers used for sharing a network connection) be vulnerable if they have DNS set to a non-vulnerable external server in their local client settings? (i.e. does the NAT make them now vulnerable?)

Would most routers used for sharing a network connection in a LAN need firmware updates due to this issue, if the routers themselves are DNS servers?

I think folks do take the advisory seriously, but want a “no brainer” guide “for dummies” to make sure they’ve done all they can, especially given that many vendors haven’t made an official statement yet.

Just to be clear, would regular clients (Macs, Windows, Linux) behind a NAT firewall (e.g. a Netgear, Linksys or similar routers used for sharing a network connection) be vulnerable if they have DNS set to a non- vulnerable external server in their local client settings? (i.e. does the NAT make them now vulnerable?)

yes and no. if you have a de-randomizing NAT/PAT device in front of your randomizing DNS questioner, then you will be less safe as a result of the de-randomization. however, non-caching (end-user; client only) DNS questioners are inherently less vulnerable to spoofing since they won’t save or re-use any bad data that someone might be able to fool them with. so while there is a danger, it’s not quite as dramatic. most non-caching DNS questioners will never be upgraded to randomize their UDP ports, so most of the time a de-randomizing NAT/PAT device will not make them even less safe.

Would most routers used for sharing a network connection in a LAN need firmware updates due to this issue, if the routers themselves are DNS servers?

almost certainly, but you’ll have to contact your router vendor to be sure. note, if you can do a “dig porttest.dns-oarc.net in txt” from a client of that router or any other DNS server, you can learn a lot about how random its UDP ports are. a rating of FAIR or GOOD means you have no worries. any other rating means you need to call your vendor and set their hair on fire.

I think folks do take the advisory seriously, but want a “no brainer” guide “for dummies” to make sure they’ve done all they can, especially given that many vendors haven’t made an official statement yet.

for early notification we mostly picked on the large enterprise DNS vendors since a small number of patches and upgrades would protect a large number of endpoints. also we knew all of them personally :-). for the router vendors who embed a DNS server in their product, we were mostly told “it’s hopeless, noone ever installs our firmware updates, but we will try.” so, call your vendor, large or small, and tell them you need a fix to CERT #800113.

Thanks for posting the test, Paul. I appreciate that it’s nice and straightforward, as many other people’s descriptions have been very technical and less than clear. That’s something that everyone can easily run from the command line, to see if they’re vulnerable:

dig porttest.dns-oarc.net in txt

I just ran it, and got the result:

(IP address) is POOR: 26 queries in 1.5 seconds from 1 ports with std dev 0.00”

which is obviously a failure of the test (you might want to make the language of the failure even more obvious, e.g. DANGER!! YOU ARE LEAST SAFE!!). I suspect I’m not alone! (probably millions of people with consumer-grade cable/DSL routers face the same issue). I already put in a call to my cable/DSL router manufacturer (before I posted the initial question even) and await a reply.

Once again, for the “for dummies” crowd, if the vendor doesn’t do anything, are there any countermeasures we can easily employ today? I noticed OpenDNS.com suggested using their nameservers, and then firewalling off any other DNS responses. Is that a possible solution that consumers can deploy? (I assume we’d need to put their nameservers into the router’s DNS configuration, as well as the DNS settings of all the clients? Or should we point all clients to the DNS of the router, and then point the router’s DNS to OpenDNS? And then figure out what access rules to employ on the router’s firewall to ensure that poisoning can’t occur?)

Does securing zone transfers with TSIG eliminate the need for the BIND upgrade?  Or does TSIG just mitigate the NAT issue after upgrading?

Just a quick followup, I changed the DNS settings on both my cable/DSL router and on my LAN clients behind its NAT firewall to OpenDNS, and now I get:

(IP Address) is GOOD: 26 queries in 2.3 seconds from 26 ports with std dev 19822.26

which appears to be a lot more secure (although, it would be nice if DNSSEC or an alternative was available for even greater security). I did not need need to alter my firewall rules on the cable/DSL router.

I also know that ICANN and USG lack the political will to sign the root zone with Secure DNS,

While I obviously cannot speak for the USG (and I don’t speak for ICANN), stating that ICANN lacks the political will to sign the root is obviously wrong, see the IANA signed root zone demo.  But Paul knows this, having been asked long ago if ISC would be interested in discussing providing secondary service for said signed demo root (which, for the record he indicated he would, but the demo effort got derailed by other politics).

that demo is of technology, not political will, and is therefore somewhat off-topic.

One of the points of the demo was to indicate IANA was undertaking to be in a position to sign the root, even at non-trivial cost (you think multiple FIPS 140-3 hardware security modules come free?).  I’m not sure how that cannot be a demonstration of political will on the part of ICANN to see that the root gets signed, but it is actually irrelevant.  Even if the root were signed today, it would be essentially meaningless to address this particular vulnerability in the foreseeable future since:

a) last I checked, a total of 4 TLDs are currently signed (SE, PR, BR, and BG);
b) infinitesimally few caching servers are configured to validate responses and a goodly portion of the caching servers that people use either do not now support DNSSEC (e.g., Microsoft’s DNS server, PowerDNS, OpenDNS, etc.) or will never (according to the author) support DNSSEC (e.g., djbdns);
c) even if every zone on the planet were signed and trust anchors were appropriately configured and maintained, the mechanisms by which validation failure is returned to the end user is indistinguishable from a variety of network problems for the vast majority of applications.  As a result, an ISP turning DNSSEC on will likely be subject to a flood of expensive support calls, greatly encouraging that ISP to turn DNSSEC off.

That is not to say that I wish to discourage you from tilting at that particular windmill (after all, any journey starts with a single step and all of the above can be fixed with sufficient effort), but there is a lot more to seeing DNSSEC usefully deployed than “signing the root”.  Further, as you well know, the shorthand “sign the root” means quite a bit more than running dnssec-signzone over the root zone data and it is simply silly to assume ICANN is or even should be in a position to undertake the steps to “sign the root” unilaterally.

What I do know is that if ICANN and USG had the political will to make this happen, it would happen.

While I know in some circles it is considered a fun sport to bash ICANN, asserting ICANN doesn’t have the political will to see the root signed is both wrong as well as somewhat insulting to the folks at IANA and ICANN who have spent considerable amount of time, resources, and energy to see forward motion.

Our windows admin claims they are recently updated.  I’ve tested the AD server providing caching DNS service and zone transfer from our bind, and it responds to the test like so:

dig +short porttest.dns-oarc.net in txt @adc1
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.

There is no GOOD or POOR.  What does this mean?

Since July 9, I’ve been trying to get clarity from many people on this question, and have tried to infer the facts from the publicly available information. But after more than 8 days, I just really have to ask this question here directly. Either no one is answering it because the answer is too obvious, or maybe because it would cause mass panic. (If it would cause mass panic, please delete this e-mail!!)

My question:
Could you please tell me is the Dan’s DNS protocol vulnerability applies to the following scenario?

Suppose we have these nodes in a DNS request path.

1. A desktop computer (on a LAN) with a typical internet application, like a browser.
2. An ADSL (or other kind of) router, which contains a DNS server which fetches DNS translations for the computers on the LAN.
3. Two IP addresses supplied by the ISP for domain name resolution. The customer premises router gets its translations by sending requests to these two nodes.
4. An IP host belonging to the ISP which runs a nicely patched DNS server which uses random UDP source ports to request DNS translations from the world-wide DNS.
5. The world-wide domain name system.

In this set-up, typically the ISP’s node 4 is fine. (This is the DNS server whose IP address shows up in the dig porttest.dns-oarc.net test when dig is run against the ADSL router, node 2, on the LAN-facing interface.)

It seems to me that since the application software in node 1 will use the S-NAT-translated source IP address of node 2 (the router) for its application requests (like on TCP port 80), and node 2 contains a DNS server which is

not

using randomized UDP source ports, then the router must surely be fully vulnerable to the worst of whatever Dan has in store for us. Even though the DNS requests from this router normally only go to the ISP’s two hosts (nodes 3), surely the attacker can mess around with that router to the maximum extent permitted by the vulnerability. The attacker can send DNS traffic to the router’s internet-facing interface.

In other words, even though node 1 is using safe node 4 for the last hop of the DNS request chain before hitting the wide open DNS (nodes 5), the intermediate node 2 can be poisoned, and the ISP’s virtuous patching will have been to no avail.

Question 2:
If the above scenario is correct, does this imply that hundreds of millions of routers of users at home or in small offices will be toast on 7 August?

Just curious…

Could you please tell me is the Dan’s DNS protocol vulnerability applies to the following scenario?
...
... then the router must surely be fully vulnerable to the worst of whatever Dan has in store for us.

yes and no. the worst is when you not just believe something that’s not true but you also remember it and pass it for a while until you eventually forget. in the scenario you’re outlining, the ADSL router isn’t a full DNS server, it just SNATs to the ISP’s fully-randomizing DNS server. so, yes, your ADSL router is vulnerable. but since it has no cache, it’s not a very fat target.

Question 2:
If the above scenario is correct, does this imply that hundreds of millions of routers of users at home or in small offices will be toast on 7 August?

“toast” isn’t exactly the right word for most of them. try “garlic bread.” however, some of them are running RDNS (patched or not) inside their SNAT, which will de-randomize their UDP port numbers, and they are toast. Others are running RDNS (with caching) in unpatchable SOHO routers, and they are also toast. but i’d say hundreds of thousands, not hundreds of millions, since those configurations aren’t all that common.

So, is it possible that one might pass the above “dig” port test (i.e. receive a “GOOD” or “FAIR” result), yet have a false sense of security because one is still vulnerable to the DNS cache poisoning attack?

Or is passing that test sufficient to sleep reasonably well at night? If it’s not a sufficient test (i.e. it catches only a subset of all vulnerable people), perhaps a more exhaustive test is required?

My question is basically the flip of some that have been asked (if I understand correctly).  If I run the test on my own nameserver (CentOS 5, bind-9.3.4-6.0.2.P1.el5_2, 12-Jul-2008 12:46), I get a GOOD, which is good:

dig @72.83.159.115 porttest.dns-oarc.net in txt
porttest.dns-oarc.net.  60     IN     CNAME   z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. 60 IN TXT “72.83.159.115 is GOOD: 26 queries in 2.3 seconds from 26 ports with std dev 14019.46”

But if I use my provider (Verizon) nameserver I get POOR, which isn’t good:

dig @71.252.0.12 porttest.dns-oarc.net in txt
porttest.dns-oarc.net.  60     IN     CNAME   z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. 60 IN TXT “71.252.0.38 is POOR: 26 queries in 2.2 seconds from 21 ports with std dev 17.55”

Does that mean I’ve done all I can to my machine but I need to bug Verizon?  I’d think this is the sort of thing Verizon would care about and would deal with pretty quickly.

So, I have 2 name servers, both running bind 9.5.0-p1, yet they both are rated “POOR: 26 queries in 3.0 seconds from 1 ports with std dev 0.00”...  What now?  I ran the test from the machines themselves….  Thanks.