Sure, dns poisoning is a major vulnerability, but most residential users should be restricting dns traffic purely to their isp or other dns provider - they shouldn’t be walking the dns tree anyhow, so the odds of an attacker being able to spoof a reply to their query is pretty low. Provided the ISP (or other provider) has a clean resolver, their own feed should also be clean.

Yes, the customer will be talking to their provider’s dns server, but eventually those questions will be asking for dnssec answers, and it is those dnssec answers that may or may not make it back thru the residential gateway proxy to the internal machine that asked the question.

but those *answers* don’t have to be DNSSEC. DNSSEC should be applied at the provider level, not at the consumer level - once the ISP has a (known good, DNSSEC approved) answer, it can serve that to its customers using normal DNS. DNSSEC is a painful protocol anyhow, and requires you to be able to do digital signatures (in its rfc form - fixed admittedly in some of the draft replacements - it also allows you to walk a zone and effectively perform a zone transfer, something we have been locking down on in recent years as it just makes life too easy for certain types of attacker)

It’s not expected that ISPs’ recursive resolvers will unilaterally reject DNS responses that fail DNSSEC validation.

Usually they would only do this if the client (i.e. stub) has indicated that it is security aware by setting the “DO” bit.

However our study did determine that some of the routers couldn’t correctly pass the “DO” bit.  Others also had problems returning the “AD” bit that signifies successful validation.

Ok, that was incorrect.

Validating recursors will only set the AD bit in the response if the request contained the DO bit.

However it is allowable (indeed expected) that an upstream resolver can return SERVFAIL if a domain fails DNSSEC validation, according to the ISP’s locally configured policy.

However if the client wants to use a different policy, they must either run a fully validating caching resolver locally, or “forward” (in the DNS sense) their queries to an upstream recursive resolver with the DO and CD bits set.

The former configuration potentially suffers from Kaminsky-style cache poisoning attacks due to poor NAT source port randomisation.  The latter approach would be affected by the DNSSEC flag compatibilities highlighted in our report.