9

I've recently switched my DNS resolver to systemd-resolved in order to start taking advantage of DNSSEC where it is available. My config is:

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

(including the commented out default of DNSSEC=allow-downgrade)

Everything seems to work great for the majority of sites, both DNSSEC-enabled and not. However, occasionally I hit a site that doesn't resolve:

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

I've attempted to verify this via DNSSEC analyzer (for savannah.gnu.org). However, I do have a hard time understanding the result. I don't really see how it's different from any other domain not enabling DNSSEC.

My question is: is DNSSEC that commonly broken, or is systemd-resolved doing something wrong here?

1

1 Answer 1

7

It's probably both. Overall, based on previous reports, I would lean towards the latter (systemd-resolved being too strict in some cases). However, according to DNSViz, the domains' configuration doesn't quite pass all the checks either.

I'm also not 100% sure about certain DNSSEC mechanisms, but here's my take:

savannah.gnu.org

It's a huge mess. Systemd-resolved correctly detects an issue with the domain... but incorrectly rejects it based on information that it shouldn't trust.

  1. The gnu.org. zone has signatures, but its delegation from org. doesn't include any keys to validate them against, so the resolver is not supposed to even look at those signatures at all – they are no longer part of the chain of trust. However, systemd-resolved looks at them anyway.

  2. The savannah.gnu.org. name exists in two places, and they don't agree with each other. This problem would go unnoticed without DNSSEC, but would always fail validation with DNSSEC. However, due to problem #1, it fails validation even though systemd-resolved is supposed to quietly ignore it.

More detail on #2:

The same nameservers are hosting both the signed parent zone gnu.org. and the unsigned child zone savannah.gnu.org.. The problem is that former lacks an actual NS delegation to the latter; instead it just has plain non-delegation records at this name.

Things only happen to work because both zones are hosted by the same nameservers, so at first, when you're querying for A or AAAA records at "savannah.gnu.org", the answer is automatically served from the unsigned child zone.

It's clear that it's the beginning of a separate zone because it has a SOA record. But the DNSSEC validator needs to know whether this zone should be signed or not, so it attempts to query for DS records (or lack thereof) and this time the response is always served from the parent zone.

An unsigned sub-zone is okay if the parent zone doesn't have any DS records for it, which it proves by returning a signed NSEC record in place of the answer; te NSEC "proof of non-existence" indicates all record types which are present or absent for this name.

So the parent "gnu.org" zone correctly claims that DS records for "savannah.gnu.org" don't exist... but it also claims that NS records don't exist, either, i.e. the name isn't delegated to a child zone at all. (Apparently there is an SSHFP record though...)

Since the validator has the original unsigned answer indicating that it came from a sub-zone, and a signed proof indicating that there is no delegation to a sub-zone, the validation must fail.

...But, as mentioned in #1, none of those checks should be done in the first place, because the parent-parent org. zone also proves that its delegation to gnu.org. is unsigned, which means any NSEC records coming from gnu.org are moot. Systemd-resolved shouldn't be looking at them – it should be treating the entire gnu.org zone as not having any DNSSEC.

1
  • Easy way to debug: do a dig query towards a recursive nameserver. If it returns NXDOMAIN, then do it again with the +cd flag that disables DNSSEC: if that second query then succeeds, it is 99.99% chance the problem is DNSSEC related. Here DNSSEC is broken between gnu.org and savannah.gnu.org Oct 19, 2019 at 6:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .