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.

treewide: fix typos and spacing

resolved: allow building without libgcrypt

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

resolved: reorder functions Preparation to make gcrypt optional.

update TODO This gets rid of the private DNSSEC TODO and moves it in the main TODO dump site, as the DNSSEC implementation is pretty complete now, and the remaining bits are low-priority.

resolved: don't insist in RRSIG metadata for NSEC3 RRs that have not been authenticated In some cases we get NSEC3 RRs that have not been authenticated (because the chain of trust to the root is somewhere broken). We can use these for checking negative replies, as long as we don't claim they were ultimately authenticated. This means we need to be able to deal with NSEC3 RRs that lack RRSIG metadata.

update DNSSEC TODO

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.

resolve: use different bitmap checking rules when we find an exact NSEC3 match, or just a covering enclosure If we are looking for a DS RR we need to check the NSEC3 bitmap of the parent zone's NSEC3 RR, not the one from the child. For any other RR we need to look at the child's however, hence enforce this with the bitmaps. Note that not coverign checks only the lower zone's NSEC3 bitmaps matter, hence the existing check is fine.

update DNSSEC TODO

resolved: rework IDNA logic Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs. Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix. With this change IDNA conversion is done only: - When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname() - When the user passes a non-ASCII domain suffix when resolving a service using ResolveService() No IDNA encoding is done anymore: - When the user does raw ResolveRecord() RR resolving - On the service part of a DNS-SD service name Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.

resolved: update DNSSEC TODO

resolved: update RFCs list and TODO list

resolved: complete NSEC non-existance proofs This fills in the last few gaps: - When checking if a domain is non-existing, also check that no wildcard for it exists - Ensure we don't base "covering" tests on NSEC RRs from a parent zone - Refuse to accept expanded wildcard NSEC RRs for absence proofs.

resolved: make sure the NSEC proof-of-non-existance check also looks for wildcard domains

resolved: on negative NODATA replies, properly deal with empty non-terminals empty non-terminals generally lack NSEC RRs, which means we can deduce their existance only from the fact that there are other RRs that contain them in their suffix. Specifically, the NSEC proof for NODATA on ENTs works by sending the NSEC whose next name is a suffix of the queried name to the client. Use this information properly.

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: be stricter when using NSEC3 We can user signer and synthesizing source information to check that the NSEC3 RRs we want to use are actually reasonable and properly signed.

resolved: when validating an RRset, store information about the synthesizing source and zone in each RR Having this information available is useful when we need to check whether various RRs are suitable for proofs. This information is stored in the RRs as number of labels to skip from the beginning of the owner name to reach the synthesizing source/signer. Simple accessor calls are then added to retrieve the signer/source from the RR using this information. This also moves validation of a a number of RRSIG parameters into a new call dnssec_rrsig_prepare() that as side-effect initializes the two numeric values.

resolved: do not use NSEC RRs from the wrong zone for proofs When proving NODATA DS lookups we need to insist on looking at the parent zone's NSEC RR, not the child zone's. When proving any other NODATA lookups we need to insist on looking at the child zone's NSEC RR, not the parent's.

resolved: ignore DS RRs without generating an error if they use an unsupported digest algorithm

resolved: some RR types may appear only or not at all in a zone apex Add extra checks when validating with RRSIGs. This follows recommendations from: http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/NotesOnDNSSSEC.htm

resolved: implement the full NSEC and NSEC3 postive wildcard proofs

resolved: refuse validating wildcard RRs for SOA, NSEC3, DNAME

resolved: properly handles RRs in domains beginning in an asterisk label 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.

resolved: optimize dnssec_verify_rrset() a bit Let's determine the source of synthesis once instead of for each RR in the RRset.

resolved: allocate bounded strings on stack instead of heap, if we can

resolved: consider inverted RRSIG validity intervals expired

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: split up nsec3_hashed_domain() into two calls 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.

resolved: drop flags unused parameter from nsec3_is_good

basic: introduce generic ascii_strlower_n() call and make use of it everywhere

resolved: use dns_answer_size() where appropriate to handle NULL DnsAnswer

resolved: rename suffix_rr → zone_rr 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.

resolved: fix NSEC3 iterations limit to what RFC5155 suggests

update DNSSEC TODO

update DNSSEC TODO

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.

update DNSSEC TODO

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: fix DNSSEC canonical ordering logic 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.

resolved: never authenticate RRsets with revoked keys

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

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: dnssec - properly take wildcards into account in NESC3 proof 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.

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: don't accept NSEC3 iteration fields unbounded

resolved: dnssec - add reference to the algorithm we implement

resolved: dnssec - prepend hashed labels to zone name All hashed names consist of the hashed label prepended to the zone name, not to the closest enclosure.

resolved: dnssec - rename some variables Makes the NSEC3 proof somewhat simpler to follow.

resoled: dnssec - don't refuse to verify answer due to too many unrelated RRs 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.

resolved: dnssec - fix off-by-one in RSA key parsing 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: NSEC3 hash algorithms are distinct from DS digest algorithms 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.

update DNSSEC TODO

resolved: add comments referencing various RFCs to various places

resolved: update DNSSEC TODO

resolved: use RRSIG expiry and original TTL for cache management 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.

resolved: only keep a single list of supported signature algorithms 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.

resolved: add ECDSA signature support

resolved: split out RSA-specific code from dnssec_verify_rrset() In preparation for ECDSA support.

resolved: simplify MD algorithm initialization a bit

resolved: add SHA384 digest support

resolve: remove unused variables

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: be stricter when searching for a DS RR for a DNSKEY RR

update DNSSEC TODO

resolved: tighten search for NSEC3 RRs a bit 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.

resolved: when doing NSEC3 proof, first find right NSEC3 suffix When doing an NSEC3 proof, before detrmining whether a name is the closest encloser we first need to figure out the longest common suffix we have with any NSEC3 RR in the reply.

resolved: properly implement RRSIG validation of wildcarded RRsets Note that this is still not complete, one additional step is still missing: when we verified that a wildcard RRset is properly signed, we still need to do an NSEC/NSEC3 proof that no more specific RRset exists.

resolved: update TODO

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: update DNSSEC TODO

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: initialize libgcrypt before using it

resolved: rework how we get the gcrypt digest algorithm ID from DNSSEC digest ids Let's move this into a function digest_to_gcrypt() that we can reuse later on when implementing NSEC3 validation.

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: when matching up DNSKEY and DS RRs, it's fine if we don't support the DNSKEY's algorithm As long as we support the digest we are good.

resolved: when matching up RRSIG and DNSKEY RRs, use the RRSIG's signer name, not the owner name When the DNSKEY is in higher zone, then that's OK, and we need to check the RRSIG's signer name against the DNSKEY hence.

resolved: fix sorting of RRsets We actually maintain an array of pointers to RRs, not of RRs themselves, fix the qsort() invocation accordingly.

resolved: fix libgcrypt error checking libgcrypt encodes the error source in the error code, we need to mask that away before comparing error codes.

resolve: remove unused variable

resolved: update DNSSEC TODO list a bit

resolved: maintain a short TODO list for DNSSEC support in the dnssec C files for 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: add a limit on the max DNSSEC RRSIG expiry skew we allow

resolved: make expiration error recognizable

resolved: support the RSASHA1_NSEC3_SHA1 pseudo-algorithm RSASHA1_NSEC3_SHA1 is an alias for RSASHA1, used to do NSEC3 feature negotiation. While verifying RRsets there's no difference, hence support it here.

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.