[DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)

[Evan Hunt <[e-mail]>]

On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:
> DNSSEC is a mitigation against spoofed responses, man-in-the-middle
> interception-and-rewriting and cache compromises. These threats are
> endpoint and path specific, so it's entirely possible that one of your
> resolvers (or its path) has been compromised, but not others. If all of
> your paths have been compromised, then there is no recovery; only
> detection. But that is always true for DNSSEC.

Consider the scenario in which one authoritative server for a zone
has been compromised and the others have not, and that one happens to
have the lowest round-trip time, so it's favored by your resolver.

If you query with CD=0, a validating resolver detects the problem
and tries again with another auth server.  It doesn't give up until
the whole NS RRset has failed.

If you query with CD=1, you get the bogus data and it won't validate.
If you try again, you'll get the same bogus data out of the cache.
Use a different resolver, and if it happens to use the same auth
server, then the same thing happens again.

Your best chance of getting an answer that you can validate is to
send CD=0 to a recursive resolver that is itself validating.  If you get
SERVFAIL, *then* you try with CD=1, and if the result validates, you
know it was the resolver that was broken rather than the data.

-- 
Evan Hunt -- [e-mail]
Internet Systems Consortium, Inc.