| Age | Commit message (Collapse) | Author |
|---|
|
for the root domain defined
We already skip this when the trust anchor files define a DS RR for the
root domain, now also skip it if there's a DNSKEY RR.
|
|
These files are not specific to resolved really, and this is then more
in-line with how /etc/sysctl.d and suchlike is handled.
|
|
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.
|
|
|
|
Since we honour RFC5011 revoked keys it might happen we end up with an
empty trust anchor, or one where there's no entry for the root left.
With this patch the logic is changed what to do in this case.
Before this patch we'd end up requesting the root DS, which returns with
NODATA but a signed NSEC we cannot verify, since the trust anchor is
empty after all. Thus we'd return a DNSSEC result of "missing-key", as
we lack a verified version of the key.
With this patch in place, look-ups for the root DS are explicitly
recognized, and not passed on to the DNS servers. Instead, if
downgrade-ok mode is on an unsigned NODATA response is synthesized, so
that the validator code continues under the assumption the root zone was
unsigned. If downgrade-ok mode is off a new transaction failure is
generated, that makes this case recognizable.
|
|
|
|
We already try hard not to create cyclic transaction dependencies, where
a transaction requires another one for DNSSEC validation purposes, which
in turn (possibly indirectly) pulls in the original transaction again,
thus resulting in a cyclic dependency and ultimately a deadlock since
each transaction waits for another one forever.
So far we wanted to avoid such cyclic dependencies by only going "up the
tree" when requesting auxiliary RRs and only going from one RR type to
another, but never back. However this turned out to be insufficient.
Consider a domain that publishes one or more DNSKEY but which has no DS
for it. A request for the domain's DNSKEY triggers a request for the
domain's DS, which will then fail, but return an NSEC, signed by the
DNSKEY. To validate that we'd request the DNSKEY again. Thus a DNSKEY
request results in a DS request which results in the original DNSKEY
request again. If the original lookup had been a DS lookup we'd end up
in the same cyclic dependency, hence we cannot statically break one of
them, since both requests are of course fully valid. Hence, do full
cyclic dependency checking: each time we are about to add a dependency
to a transaction, check if the transaction is already a dependency of
the dependency (recursively down the tree).
|
|
dns_transaction_request_dnssec_keys() is running
If any of the transactions started by
dns_transaction_request_dnssec_keys() finishes promptly without
requiring asynchronous operation this is reported back to the issuing
transaction from the same stackframe. This might ultimately result in
this transaction to be freed while we are still in its
_request_dnssec_keys() stack frame. To avoid memory corruption block the
transaction GC while in the call, and manually issue a GC after it
returned.
|
|
|
|
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.
|
|
validation
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
traffic
|
|
|
|
|
|
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).
|
|
resolved
|
|
|
|
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.
|
|
|
|
|
|
We don't implement it, and we have no intention to, but at least mention
that it exists.
(This also adds a couple of other algorithms to the algorithm string
list, where these strings were missing previously.)
|
|
|
|
|
|
|
|
RFC 2181, Section 8 suggests to treat an RR TTL with the MSB set as 0.
Implement this.
|
|
|
|
Resolve misc2
|
|
|
|
This makes sure that we also honour the RRSIG expiry for negative
caching.
|
|
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 renames dns_transaction_stop() to dns_transaction_stop_timeout()
and makes it only about stopping the transaction timeout. This is safe,
as in most occasions we call dns_transaction_stop() at the same time as
dns_transaction_close_connection() anyway, which does the rest of what
dns_transaction_stop() used to do. And in the one where we don't call
it, it's implicitly called by the UDP emission or TCP connection code.
This also closes the connections as we enter the validation phase of a
transaction, so that no further messages may be received then.
|
|
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.
|
