[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10
edmonds at mycre.ws
Mon Jun 6 17:08:45 UTC 2016
Peter van Dijk wrote:
> On 5 Jun 2016, at 20:40, Paul Wouters wrote:
> > Of course, this kind of systemd-resolvd bad practise is why security
> > aware
> > applications (like libreswan) will want to do their own validation
> > because
> > it simply cannot trust the AD bit from sources like systemd-resolved.
> > Which is exactly what systemd-resolvd was supposed to solve....
> Are you saying systemd-resolved will set an AD bit even when a downgrade has
I was under the impression that systemd-resolved doesn't have a DNS
responder (it doesn't "listen on port 53"), so it would never set a
response-only bit like AD in an RFC 1035 §4 response message. But I've
only read some of the documentation and skimmed some of the code, it's
possible I missed something. There appears to be a roughly analogous
"AUTHENTICATED" flag in the resolved API, however.
Here is what the resolved.conf(5) man page says about "allow-downgrade":
[...] If set to "allow-downgrade" DNSSEC validation is attempted,
but if the server does not support DNSSEC properly, DNSSEC mode is
automatically disabled. Note that this mode makes DNSSEC validation
vulnerable to "downgrade" attacks, where an attacker might be able
to trigger a downgrade to non-DNSSEC mode by synthesizing a DNS
response that suggests DNSSEC was not supported. [...]
Client programs looking up DNS data will be informed whether lookups
could be verified using DNSSEC, or whether the returned data could
not be verified (either because the data was found unsigned in the
DNS, or the DNS server did not support DNSSEC or no appropriate
trust anchors were known). In the latter case it is assumed that
client programs employ a secondary scheme to validate the returned
DNS data, should this be required. [...]
The second paragraph above appears to be referring to a flag in the
resolved API, "SD_RESOLVED_AUTHENTICATED". Here is what the API
documentation says about that flag:
The AUTHENTICATED bit is defined only in the output flags of the
four functions [ResolveHostname, ResolveAddress, ResolveRecord,
ResolveService]. If set, the returned data has been fully
authenticated. Specifically, this bit is set for all
DNSSEC-protected data for which a full trust chain may be
established to a trusted domain anchor. It is also set for locally
synthesized data, such as localhost or data from /etc/hosts.
Moreover, it is set for all LLMNR or mDNS RRs which originate from
the local host. Applications that require authenticated RR data for
operation should check this flag before trusting the data. Not that
resolved will not return invalidated data in any case, hence this
flag simply allows to discern the cases where data is known to be
trustable, or where there's proof that the data is "rightfully"
unauthenticated (which includes cases where the underlying protocol
or server does not support authenticating data).
I.e., the AUTHENTICATED bit will only be set for data from the DNS that
has been DNSSEC-validated as secure, or for locally originated data.
It seems if you need data that must be authentic (e.g. an SSHFP record)
you call resolved's ResolveRecord function and check the AUTHENTICATED
flag, and "allow-downgrade" has no influence on whether that flag can be
forced on (only on whether it can be forced off).
Am I missing something?
More information about the dns-operations