Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.

[Simon Kelley <simon@thekelleys.org.uk>]

On 06/02/14 12:35, Toke Høiland-Jørgensen wrote:

>
> So, just to make sure I understand things: What kind of guarantees does
> the DNSSEC support give? If an upstream server is injecting things into
> DNS (for a signed zone of course), is dnsmasq guaranteed to discard the
> reply? And can a malicious upstream server strip out DNSSEC results to
> fool dnsmasq into accepting a bogus response?

Yes, and yes, AFAICS.

There are four possible results of verification, given in RFC 4025 para 4.3

Quote:

  Secure: An RRset for which the resolver is able to build a chain of
       signed DNSKEY and DS RRs from a trusted security anchor to the
       RRset.  In this case, the RRset should be signed and is subject to
       signature validation, as described above.

    Insecure: An RRset for which the resolver knows that it has no chain
       of signed DNSKEY and DS RRs from any trusted starting point to the
       RRset.  This can occur when the target RRset lies in an unsigned
       zone or in a descendent of an unsigned zone.  In this case, the
       RRset may or may not be signed, but the resolver will not be able
       to verify the signature.

    Bogus: An RRset for which the resolver believes that it ought to be
       able to establish a chain of trust but for which it is unable to
       do so, either due to signatures that for some reason fail to
       validate or due to missing data that the relevant DNSSEC RRs
       indicate should be present.  This case may indicate an attack but
       may also indicate a configuration error or some form of data
       corruption.

    Indeterminate: An RRset for which the resolver is not able to
       determine whether the RRset should be signed, as the resolver is
       not able to obtain the necessary DNSSEC RRs.  This can occur when
       the security-aware resolver is not able to contact security-aware
       name servers for the relevant zones.



Dnsmasq doesn't distriguish between Insecure and Indeterminate, both are 
lumped together as "INSECURE". The reason it's done that way is that it 
would cost extra work and round-trips upstream to make the distinction, 
and, unless I've misunderstood, there are no differences in the external 
behavior required for these two results.


bogus - return SERVFAIL in the answer
secure - set the AD bit
insecure and indeterminate - do neither of the above.


Cheers,

Simon.


>
> -Toke