> On Jan 3, 2022, at 6:22 AM, Viktor Dukhovni <postfix-us...@dukhovni.org>
> wrote:
>
> On Mon, Jan 03, 2022 at 05:49:05AM -0800, Dan Mahoney (Gushi) wrote:
>
>> We run validating resolvers at the day job, but by default not on the box
>> where postfix runs. (I.e. we rely on the AD bit).
>
> "Relying in the AD bit" is independent of whether the validating
> resolver is local or remote. However, it is only secure when it is
> local. You get no security if "remote" means across the public
> Internet, operated by some third party provider. When remote is a
> nearby resolver on an internal LAN, you may still be vulnerable in
> some ways.
>
> The only sound approach is to use a local (loopback network) validating
> resolver, and if desirable have it forward queries to a nearby shared
> resolver, whose replies are locally revalidated.
>
>> In reading over what's required to enable DANE support in postfix, I see
>> that there's a compile-time requirement for the DNS lib in the OS to
>> support it, which our OS does according to resolv.h. I don't see any
>> options in the port to enable/disable this feature.
>
> Most extant Unix-like systems have a DNS stub resolver that supports
> DNSSEC queries. Postfix just needs the AD bit set in requests, but
> the legacy libresolv API only supports setting the DO bit, which is
> more than strictly necessary.
>
>> Is there a -V command or something I can have postfix log to see if this
>> is the case? Also, is there a way to add a header implying the status of
>> a DANE lookup to outbound mail?
>
> If you enable DNSSEC lookups, Postfix will log a warning when the root
> zone appears unsigned. See:
>
> http://www.postfix.org/postconf.5.html#dnssec_probe
>
> This feature is available in Postfix 3.6 and later. It was
> backported to Postfix versions 3.5.9, 3.4.19, 3.3.16. 3.2.21.
This is a problem when your local resolver is slaving the root zone, as a
standard root zone "type slave" will hand . NS out with the AA bit set, but
will not set the AD bit.
There's a feature in more recent versions of BIND (mirror zones) that may fix
this, but right now if you're following RFC7706, this check is lying to you.
That said, whomever put this in was good enough to put in a knob to disable it
-- but from the docs, it's unclear as to what happens: is dane simply ignored,
or is this just a warning that "hey, your dnssec may not be real, but we're
still going to use it"
Also...the server I'm sending to has a legit signed cert that matches its
hostname, so the message I get is:
Trusted TLS connection established to prime.gushi.org[149.20.68.142]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Whereas if pure DANE had been used, I think the wording there would be
"Verified", not Trusted. I'm guessing if there's a full cert path, that
"wins"? Is TLSA still validated at all in this case?
The TLSA record verification (or even the lookup) never gets logged, at least
at loglevel 2. This would be useful for admins to see how much traction DANE
is getting. Is there a logging knob that will enable this?
And again, dropping a header into the body of the mail message so that the
admin on the *receiving* server could see that their TLSA records are good for
more than just getting periodic "hey your record's broke" emails from Viktor :)
-Dan
