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
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
