Re: [exim] Upcoming Glibc changes and DANE support in Exim, …

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Viktor Dukhovni
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [exim] Upcoming Glibc changes and DANE support in Exim, Postfix, and perhaps other MTAs
On Thu, Apr 16, 2020 at 07:53:08PM +0100, Jeremy Harris via Exim-users wrote:

> On 15/04/2020 18:46, Viktor Dukhovni via Exim-users wrote:
> > I read this to mean that the new "trust-ad" option, if set, causes the
> > Glibc stub resolver to set AD=1 in queries, but *otherwise*, causes it
> > to strip the AD bit from replies.
>
> So much for back-compatibility, eh? They broke it for all existing
> consumers of DNSSEC?


Well, everyone who trusts the AD bit, rather than bolting a full
DNSSEC-validator into their application, along with tracking
trust-anchor rollovers, ... Yes, it is a breaking change for Exim and
Postfix.

> > Once you upgrade to Glibc 2.31 or higher, you'll need to explicitly
> > add the "trust-ad" option to your /etc/resolv.conf, while of course also
> > making sure that all the listed nameservers are local (loopback interface).
>
> While wise to have an on-system caching resolver on performance grounds,
> for any mail volume beyond trivial - isn't that a rather tight
> restriction? Why should you not trust other systems which are
> under your administrative control (assuming your threat model doesn't
> extend to in-organisation attacks)?


Well, so long as there's a network path from outsiders to your machine
they can forge packets from your internal forwarders, unless you have
robust anti-spoofing firewall rules at the edge.

But yes, on a physically secure network, with no untrusted devices,
and strong anti-spoofing at the network edge, one might relax "local"
to include some internal networks, and not just "loopback". One might
even have IPSEC tunnels to trusted nameservers.

But the most common configuration in which one can reason about the
security of the AD bit is a loopback DNSSEC-validating resolver.

FWIW, Wietse's fix for existing stable Postfix releases is to just set
"RES_TRUSTAD" along with the previous "RES_USE_EDNS0" when the calling
code is requesting RES_USE_DNSSEC. This restores prior semantics.
More fine-grained policy about when to set or not set RES_TRUSTAD will
be in tested in the development snapshots over the next year and be
part of 3.6 early in 2021.

For Exim you will of course decide what's most appropriate.

-- 
    Viktor.