Re: [Add] data integrity and DNSSEC or DoH/DoT

[Jim Reid <[e-mail]>]

> On 22 Aug 2019, at 08:00, Eric Rescorla <[e-mail]> wrote:
> 
> Suppose that I receive a bogus response to my A record query, how am I to usefully distinguish "this is malware blocking" from "this resolver is malicious"?

I'm surprised that distinction matters to you. I thought any form of DNS blocking or filtering was malicious from your PoV. :-)

To be slightly less glib, the dnsop WG has an I-D on extended error codes. [And FWIW lack of a discrete error code(s) for validation failure is one of the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error already goes some way to answering your question:

4.16.  Extended DNS Error Code 15 - Blocked

   The resolver attempted to perfom a DNS query but the domain is
   blacklisted due to a security policy implemented on the server being
   directly talked to.

4.17.  Extended DNS Error Code 16 - Censored

   The resolver attempted to perfom a DNS query but the domain was
   blacklisted by a security policy imposed upon the server being talked
   to.  Note that how the imposed policy is applied is irrelevant (in-
   band DNS somehow, court order, etc).

4.18.  Extended DNS Error Code 17 - Prohibited

   An authoritative or recursive resolver that receives a query from an
   "unauthorized" client can annotate its REFUSED message with this
   code.  Examples of "unauthorized" clients are recursive queries from
   IP addresses outside the network, blacklisted IP addresses, local
   policy, etc.

I suppose draft-ietf-dnsop-extended-error could add another error code for the specific case of a malicious resolver. Whatever that might mean. Though I doubt the operators of such servers will choose to set that evil bit on their responses.

PS A potential problem with this I-D is these extended error codes won’t be signed. So they can be spoofed by bad actors.