summaryrefslogtreecommitdiffstats
path: root/units/cryptsetup-pre.target
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2016-01-07 22:27:33 +0100
committerLennart Poettering <lennart@poettering.net>2016-01-11 19:39:59 +0100
commit0c7bff0acc8fd04bac9bfd16d696139951149ceb (patch)
treefebff4a2dcb7e845575949e01d3c65da216c5ed2 /units/cryptsetup-pre.target
parentresolved: split up nsec3_hashed_domain() into two calls (diff)
downloadsystemd-0c7bff0acc8fd04bac9bfd16d696139951149ceb.tar.xz
systemd-0c7bff0acc8fd04bac9bfd16d696139951149ceb.zip
resolved: properly look for NSEC/NSEC3 RRs when getting a positive wildcard response
This implements RFC 5155, Section 8.8 and RFC 4035, Section 5.3.4: When we receive a response with an RRset generated from a wildcard we need to look for one NSEC/NSEC3 RR that proves that there's no explicit RR around before we accept the wildcard RRset as response. This patch does a couple of things: the validation calls will now identify wildcard signatures for us, and let us know the RRSIG used (so that the RRSIG's signer field let's us know what the wildcard was that generate the entry). Moreover, when iterating trough the RRsets of a response we now employ three phases instead of just two. a) in the first phase we only look for DNSKEYs RRs b) in the second phase we only look for NSEC RRs c) in the third phase we look for all kinds of RRs Phase a) is necessary, since DNSKEYs "unlock" more signatures for us, hence we shouldn't assume a key is missing until all DNSKEY RRs have been processed. Phase b) is necessary since NSECs need to be validated before we can validate wildcard RRs due to the logic explained above. Phase c) validates everything else. This phase also handles RRsets that cannot be fully validated and removes them or lets the transaction fail.
Diffstat (limited to 'units/cryptsetup-pre.target')
0 files changed, 0 insertions, 0 deletions