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 -- [email protected] Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
