DnssecDnsHandle
: check RRSIG validity as per RFC4035
#2213
+245
−113
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this PR adds the validity checks specified in section 5.3.1 of RFC4035, including the time check that was reported as missing in issue #2209
these new checks overlap with some of the existing ones but I opted for not removing the existing ones because I do not know how well the existing code is covered by tests.
I checked that I did not break this query:
It would be good to check that expired signatures are rejected. There are plans to add those kind of tests to the conformance test suite (ferrous-systems/dnssec-tests#61) but given that
Recursor
does not useDnssecDnsHandle
those tests won't exercise the code paths added here. I'm looking into reusing some of the existing code inDnssecDnsHandle
to implement DNSSEC validation inRecursor
(then conformance tests will cover some ofDnssecDnsHandle
code) but that's still ways off time-wise.Another way to check the code here end to end would be to modify
util/src/bin/resolve.rs
to do DNSSEC validation (e.g. via a new CLI flag) then it would behave just likedelv
. That updatedresolve
could be comparatively againstdelv
using thedns-test
framework, that is without relying on external services / the internet.I'm leaving this in draft state because the implementation will be cleaner when #2211 is implemented.