On Sun, Jan 23, 2022 at 06:48:50PM +0100, Joachim Lindenberg wrote:
> To the best of my knowledge I added syntactically correct TLSAs
> indirectly via CNAMEs except for mx01.et.lindenberg.one, and the
> validator at <https://dane.sys4.de/smtp/et.lindenberg.one>
> https://dane.sys4.de/smtp/et.lindenberg.one is happy with DNSSEC and
> TLSA (SMTP obviously depends on availability and status of my
> experimental receiver).
I see:
et.lindenberg.one. IN MX 13 mx03.et.lindenberg.one. ; NoError AD=1
et.lindenberg.one. IN MX 14 mx04.et.lindenberg.one. ; NoError AD=1
et.lindenberg.one. IN MX 15 mx05.et.lindenberg.one. ; NoError AD=1
et.lindenberg.one. IN MX 16 mx06.et.lindenberg.one. ; NoError AD=1
A signed MX RRset with 4 MX hosts.
mx03.et.lindenberg.one. IN A 82.165.56.12 ; NoError AD=1
mx03.et.lindenberg.one. IN AAAA 2001:8d8:1801:28c::1:3 ; NoError AD=1
_25._tcp.mx03.et.lindenberg.one. IN CNAME _invtlsa.lindenberg.one. ;
NoError AD=1
_invtlsa.lindenberg.one. IN TLSA 2 1 1
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286f ; NoError AD=1
A signed TLSA "2 1 1" record for mx03 matching the Let's Encrypt "R3"
intermediate issuer. You should really also publish at least also a
TLSA record matching "R4" key. See
https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
mx04.et.lindenberg.one. IN A 82.165.56.12 ; NoError AD=1
mx04.et.lindenberg.one. IN AAAA 2001:8d8:1801:28c::1:4 ; NoError AD=1
_25._tcp.mx04.et.lindenberg.one. IN CNAME _selftlsa.lindenberg.one. ;
NoError AD=1
_selftlsa.lindenberg.one. IN TLSA 3 1 1
fe950f86708244329b4675b7adc120ee2d3f66a90c01449c8c24fea99f3e2909 ; NoError AD=1
A signed TLSA "3 1 1" record for "mx04".
mx05.et.lindenberg.one. IN A 82.165.56.12 ; NoError AD=1
mx05.et.lindenberg.one. IN AAAA 2001:8d8:1801:28c::1:5 ; NoError AD=1
_25._tcp.mx05.et.lindenberg.one. IN CNAME _invtlsa.lindenberg.one. ;
NoError AD=1
_invtlsa.lindenberg.one. IN TLSA 2 1 1
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286f ; NoError AD=1
mx06.et.lindenberg.one. IN A 82.165.56.12 ; NoError AD=1
mx06.et.lindenberg.one. IN AAAA 2001:8d8:1801:28c::1:6 ; NoError AD=1
_25._tcp.mx06.et.lindenberg.one. IN CNAME _tlsa.lindenberg.one. ; NoError
AD=1
_tlsa.lindenberg.one. IN TLSA 2 1 1
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; NoError AD=1
More Let's Encrypt "R3" records for "mx05" and "mx06".
> When I send a mail from my postfix however, postfix reports “no TLSA
> records found“. Or full log entries:
>
> warning: TLS policy lookup for et.lindenberg.one/et.lindenberg.one: no
> TLSA records found 49B4E0EAC: to=<t...@et.lindenberg.one>, relay=none,
> delay=49105, delays=49104/0.04/0.51/0, dsn=4.7.5, status=deferred (no
> TLSA records found)
Typically this suggests that you're not querying a validating DNS
resolver, or are using a recent glibc with requires the "trustad" option
to be set, ...
> I can confirm smtp_dns_support_level = dnssec is set, and
> smtp_host_lookup is not set (default). I also confirmed DNSSEC is
> working by sending a test mail to some other DANE site successfully
> (with a TLS policy dane-only).
>
> The only difference I noticed is that the other site uses a TLSA 2 0 1
> … whereas I use 2 1 1.
You're doing better than they are. When I wrote RFC 7671 it seemed at
the time that "2 0 1" would be the better choice. History proved
otherwise.
> Is postfix more picky than other tools? A configuration issue? Or
> anything else I should watch out for?
Is the recursive nameserver you're querying (typically BIND) also an
authoritative server for "et.lindenberg.one"? If so, it may not set the
"AD" bit in responses for this domain, setting the "AA" bit instead.
Postfix does not presently treat the "AA" bit as an indication of a
secure answer. Typically your recursive resolver is not also an
authoritative server for any zones (best-practice separation of duties).
I've considered treating "AA" as equivalent to "AD" (perhaps subject
to a non-default configuration option). But this has not been
implemente as of yet.
--
Viktor.
