tree-wide: remove Emacs lines from all files This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.

resolved: make dnssec_nsec_test_enclosed() static It's not used anywhere else.

resolved: log each time we increase the DNSSEC verdict counters Also, don't consider RRs that aren't primary to the lookups we do as relevant to the lookups.

resolved: rename dnssec_verify_dnskey() → dnssec_verify_dnskey_by_ds() This should clarify that this is not regular signature-based validation, but validation through DS RR fingerprints.

resolved: implement the full NSEC and NSEC3 postive wildcard proofs

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.

resolved,networkd: add a per-interface DNSSEC setting This adds a DNSSEC= setting to .network files, and makes resolved honour them.

resolved: rename "downgrade-ok" mode to "allow-downgrade" After discussing this with Tom, we figured out "allow-downgrade" sounds nicer.

resolved: when caching negative responses, honour NSEC/NSEC3 TTLs 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.

resolved: partially implement RFC5011 Trust Anchor support 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.

resolved: print a log message when we ignore an NSEC3 RR with an excessive amount of iterations

resolved: dnssec - factor out hashed domain generation

resolved: don't conclude NODATA if CNAME exists Instead introduce the new return-code DNSSEC_NSEC_CNAME to indicate this condition. See RFC 6840, Section 4.3.

resolved: add an automatic downgrade to non-DNSSEC mode 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)

resolved: if we accepted unauthenticated NSEC/NSEC3 RRs, use them for proofs But keep track that the proof is not authenticated.

resolved: add support NSEC3 proofs, as well as proofs for domains that are OK to be unsigned This large patch adds a couple of mechanisms to ensure we get NSEC3 and proof-of-unsigned support into place. Specifically: - Each item in an DnsAnswer gets two bit flags now: DNS_ANSWER_AUTHENTICATED and DNS_ANSWER_CACHEABLE. The former is necessary since DNS responses might contain signed as well as unsigned RRsets in one, and we need to remember which ones are signed and which ones aren't. The latter is necessary, since not we need to keep track which RRsets may be cached and which ones may not be, even while manipulating DnsAnswer objects. - The .n_answer_cachable of DnsTransaction is dropped now (it used to store how many of the first DnsAnswer entries are cachable), and replaced by the DNS_ANSWER_CACHABLE flag instead. - NSEC3 proofs are implemented now (lacking support for the wildcard part, to be added in a later commit). - Support for the "AD" bit has been dropped. It's unsafe, and now that we have end-to-end authentication we don't need it anymore. - An auxiliary DnsTransaction of a DnsTransactions is now kept around as least as long as the latter stays around. We no longer remove the auxiliary DnsTransaction as soon as it completed. THis is necessary, as we now are interested not only in the RRsets it acquired but also in its authentication status.

resolved: add basic proof of non-existance support for NSEC+NSEC3 Note that this is not complete yet, as we don't handle wildcard domains correctly, nor handle domains correctly that use empty non-terminals.

resolved: rework dnssec validation results This adds a new validation result DNSSEC_UNSUPPORTED_ALGORITHM which is returned when we encounter an unsupported crypto algorithm when trying to validate RRSIG/DNSKEY combinations. Previously we'd return ENOTSUPP in this case, but it's better to consider this a non-error DNSSEC validation result, since our reaction to this case needs to be more like in cases such as expired or missing keys: we need to keep continue validation looking for another RRSIG/DNSKEY combination that works better for us. This also reworks how dnssec_validate_rrsig_search() propagates errors from dnssec_validate_rrsig(). Previously, errors such as unsupported algorithms or expired signatures would not be propagated, but simply be returned as "missing-key".

resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled This adds initial support for validating RRSIG/DNSKEY/DS chains when doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not implemented yet. With this change DnsTransaction objects will generate additional DnsTransaction objects when looking for DNSKEY or DS RRs to validate an RRSIG on a response. DnsTransaction objects are thus created for three reasons now: 1) Because a user asked for something to be resolved, i.e. requested by a DnsQuery/DnsQueryCandidate object. 2) As result of LLMNR RR probing, requested by a DnsZoneItem. 3) Because another DnsTransaction requires the requested RRs for validation of its own response. DnsTransactions are shared between all these users, and are GC automatically as soon as all of these users don't need a specific transaction anymore. To unify the handling of these three reasons for existance for a DnsTransaction, a new common naming is introduced: each DnsTransaction now tracks its "owners" via a Set* object named "notify_xyz", containing all owners to notify on completion. A new DnsTransaction state is introduced called "VALIDATING" that is entered after a response has been receieved which needs to be validated, as long as we are still waiting for the DNSKEY/DS RRs from other DnsTransactions. This patch will request the DNSKEY/DS RRs bottom-up, and then validate them top-down. Caching of RRs is now only done after verification, so that the cache is not poisoned with known invalid data. The "DnsAnswer" object gained a substantial number of new calls, since we need to add/remove RRs to it dynamically now.

resolved: introduce a dnssec_mode setting per scope The setting controls which kind of DNSSEC validation is done: none at all, trusting the AD bit, or client-side validation. For now, no validation is implemented, hence the setting doesn't do much yet, except of toggling the CD bit in the generated messages if full client-side validation is requested.

resolved: don't accept expired RRSIGs

resolved: add basic DNSSEC support This adds most basic operation for doing DNSSEC validation on the client side. However, it does not actually add the verification logic to the resolver. Specifically, this patch only includes: - Verifying DNSKEY RRs against a DS RRs - Verifying RRSets against a combination of RRSIG and DNSKEY RRs - Matching up RRSIG RRs and DNSKEY RRs - Matching up RR keys and RRSIG RRs - Calculating the DNSSEC key tag from a DNSKEY RR All currently used DNSSEC combinations of SHA and RSA are implemented. Support for MD5 hashing and DSA or EC cyphers are not. MD5 and DSA are probably obsolete, and shouldn't be added. EC should probably be added eventually, if it actually is deployed on the Internet.