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

[Mark Andrews]

In message <20160606170845.GA27834 at mycre.ws>, Robert Edmonds writes:
> 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.

AD isn't a response-only bit.  It is used in non EDNS queries and
should only be returned by DNSSEC aware servers when the answer has
been determined to be authentic.  A RFC 1035 server won't copy it
into the response but there is a lot of crud out there that doesn't
actually implement RFC 1035.  See
https://ednscomp.isc.org/compliance/tld-fullreport.txt for TLD
servers that copy the last reserved bit (974 of the test queries
has the bit echoed back (zflag=mbz), the server count is lower) in
the DNS header when it is present in the query in violation of RFC
1035.

> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org