| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Properly handle RRs that begin with an asterisk label. These are the unexpanded forms of wildcard domains and appear in
NSEC RRs for example. We need to make sure we handle the signatures of these RRs properly, since they mostly are
considered normal RRs, except that the RRSIG labels counter is one off for them, as the asterisk label is always
excluded of the signature.
|
|
Let's determine the source of synthesis once instead of for each RR in the RRset.
|
|
|
|
|
|
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.
|
|
There's now nsec3_hashed_domain_format() and nsec3_hashed_domain_make().
The former takes a hash value and formats it as domain, the latter takes
a domain name, hashes it and then invokes nsec3_hashed_domain_format().
This way we can reuse more code, as the formatting logic can be unified
between this call and another place.
|
|
|
|
|
|
|
|
The domain name for this NSEC3 RR was originally stored in a variable
called "suffix", which was then renamed to "zone" in
d1511b3338f431de3c95a50a9c1aca297e0c0734. Hence also rename the
RR variable accordingly.
|
|
|
|
|
|
|
|
This adds a DNSSEC= setting to .network files, and makes resolved honour
them.
|
|
After discussing this with Tom, we figured out "allow-downgrade" sounds
nicer.
|
|
When storing negative responses, clamp the SOA minimum TTL (as suggested
by RFC2308) to the TTL of the NSEC/NSEC3 RRs we used to prove
non-existance, if it there is any.
This is necessary since otherwise an attacker might put together a faked
negative response for one of our question including a high-ttl SOA RR
for any parent zone, and we'd use trust the TTL.
|
|
|
|
With this patch resolved will properly handle revoked keys, but not
augment the locally configured trust anchor database with newly learned
keys.
Specifically, resolved now refuses validating RRsets with
revoked keys, and it will remove revoked keys from the configured trust
anchors (only until reboot).
This patch does not add logic for adding new keys to the set of trust
anchors. This is a deliberate decision as this only can work with
persistent disk storage, and would result in a different update logic
for stateful and stateless systems. Since we have to support stateless
systems anyway, and don't want to encourage two independent upgrade
paths we focus on upgrading the trust anchor database via the usual OS
upgrade logic.
Whenever a trust anchor entry is found revoked and removed from the
trust anchor a recognizable log message is written, encouraging the user
to update the trust anchor or update his operating system.
|
|
When applying canonical DNSSEC ordering for an RRset only order by the
wire format of the RRs' RDATA, not by the full wire formatting. The RFC
isn't particularly clear about this, but this is apparently how it is
done. This fixes validation of pentagon.gov's DS RRset.
|
|
|
|
amount of iterations
|
|
Fixes to NSEC3 proof v2
|
|
configuration files
This adds negative trust anchor support and allows reading trust anchor
data from disk, from files
/etc/systemd/dnssec-trust-anchors.d/*.positive and
/etc/systemd/dnssec-trust-anchros.d/*.negative, as well as the matching
counterparts in /usr/lib and /run.
The positive trust anchor files are more or less compatible to normal
DNS zone files containing DNSKEY and DS RRs. The negative trust anchor
files contain only new-line separated hostnames for which to require no
signing.
By default no trust anchor files are installed, in which case the
compiled-in root domain DS RR is used, as before. As soon as at least
one positive root anchor for the root is defined via trust anchor files
this buil-in DS RR is not added though.
|
|
For NXDOMAIN, it is not sufficient to prove that the next-closest
enclosure does not exist, we must also prove that there is no
wildcard domain directly below the closest enclosure which would
synthesise the name that has been requested.
For positive responses, in addition to exact matches, we should
accept wildcard ones. In that case we must first prove that
there is no precise match (i.e., that the closest encounter
is not the record itself) and secondly that the source of
synthesis exists.
|
|
|
|
Instead introduce the new return-code DNSSEC_NSEC_CNAME to indicate
this condition. See RFC 6840, Section 4.3.
|
|
|
|
|
|
All hashed names consist of the hashed label prepended to the zone name, not to the
closest enclosure.
|
|
Makes the NSEC3 proof somewhat simpler to follow.
|
|
Let VERIFY_RRS_MAX be about the max number of RRs in an RRSet that we
actually try to verify, not about the total number of RRs in the RRSet.
|
|
If the first byte of the key is zero, the key-length is stored in
the second and third byte (not first and second).
|
|
Previously, we'd use the same set of identifiers for both, but that's
actually incorrect. It didn't matter much since the only NSEC3 hash
algorithm defined (SHA-1) is mapped to code 1 which is also what it is
encoded as in DS digests, but we really should make sure to use two
distinct enumerations.
|
|
|
|
|
|
Resolve misc2
|
|
|
|
When we verified a signature, fix up the RR's TTL to the original TTL
mentioned in the signature, and store the signature expiry information
in the RR, too. Then, use that when adding RRs to the cache.
|
|
This removes dnssec_algorithm_supported() and simply uses the
algorithm_to_gcrypt() result as indication whether a DNSSEC algorithm is
supported.
The patch also renames "algorithm" to "md_algorithm", in a few cases, in
order to avoid confusion between DNSSEC signature algorithms and gcrypt
message digest algorithms.
|
|
|
|
In preparation for ECDSA support.
|
|
|
|
|
|
|
|
This adds a mode that makes resolved automatically downgrade from DNSSEC
support to classic non-DNSSEC resolving if the configured DNS server is
not capable of DNSSEC. Enabling this mode increases compatibility with
crappy network equipment, but of course opens up the system to
downgrading attacks.
The new mode can be enabled by setting DNSSEC=downgrade-ok in
resolved.conf. DNSSEC=yes otoh remains a "strict" mode, where DNS
resolving rather fails then allow downgrading.
Downgrading is done:
- when the server does not support EDNS0+DO
- or when the server supports it but does not augment returned RRs with
RRSIGs. The latter is detected when requesting DS or SOA RRs for the
root domain (which is necessary to do proofs for unsigned data)
|
|
But keep track that the proof is not authenticated.
|
|
|
|
|
|
Be stricter when searching suitable NSEC3 RRs for proof: generalize the
check we use to find suitable NSEC3 RRs, in nsec3_is_good(), and add
additional checks, such as checking whether all NSEC3 RRs use the same
parameters, have the same suffix and so on.
|
