[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10

[Robert Edmonds]

Peter van Dijk wrote:
> Paul,
> 
> 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
> happened?

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. [...]

    https://www.freedesktop.org/software/systemd/man/resolved.conf.html

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).

    https://wiki.freedesktop.org/www/Software/systemd/resolved/

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?

-- 
Robert Edmonds