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: 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: when validating, first strip revoked trust anchor keys from validated keys list When validating a transaction we initially collect DNSKEY, DS, SOA RRs in the "validated_keys" list, that we need for the proofs. This includes DNSKEY and DS data from our trust anchor database. Quite possibly we learn that some of these DNSKEY/DS RRs have been revoked between the time we request and collect those additional RRs and we begin the validation step. In this case we need to make sure that the respective DS/DNSKEY RRs are removed again from our list. This patch adds that, and strips known revoked trust anchor RRs from the validated list before we begin the actual validation proof, and each time we add more DNSKEY material to it while we are doing the proof.

resolved: rework trust anchor revoke checking Instead of first iterating through all DNSKEYs in the DnsAnswer in dns_transaction_check_revoked_trust_anchors(), and then doing that a second time in dns_trust_anchor_check_revoked(), do so only once in the former, and pass the dnskey we found directly to the latter.

resolved: when dumping the NTA database, sort output Now that we populate the trust database by default with a larger number of entires, we better make sure to output a more readable version.

resolved: populate negative trust anchor by default Let's increase compatibility with many private domains by default, and ship a default NTA list of wel-known private domains, where it is unlikely they will be deployed as official TLD anytime soon.

resolved: log all OOM errors

resolved: reuse dns_trust_anchor_knows_domain() at another location

resolved: when dumping trust anchor contents, clarify when it is empty

resolved: also skip built-in trust anchor addition of there's a DNSKEY RR 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.

resolved: move trust anchor files to /etc/dnssec-trust-anchors.d/ These files are not specific to resolved really, and this is then more in-line with how /etc/sysctl.d and suchlike is handled.

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: refuse revoked DNSKEYs in trust anchor

resolved: add negative trust anchro support, and add trust anchor 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.

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 a simple trust anchor database as additional RR source When doing DNSSEC lookups we need to know one or more DS or DNSKEY RRs as trust anchors to validate lookups. With this change we add a compiled-in trust anchor database, serving the root DS key as of today, retrieved from: https://data.iana.org/root-anchors/root-anchors.xml The interface is kept generic, so that additional DS or DNSKEY RRs may be served via the same interface, for example by provisioning them locally in external files to support "islands" of security. The trust anchor database becomes the fourth source of RRs we maintain, besides, the network, the local cache, and the local zone.