On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
I had a message defer indefinitely, ostensibly due to the lack of a
TLSA
record,
No, not the lack of it, but rather inability to verify presence or
lack of it in a downgrade-resistant manner. DANE being a defense
against active attacks (not just passive wiretap), would be pretty
pointless if active attacks could downgrade it to cleartext.
which seems like a poor excuse. I expect this indicates that
there's something I don't get about DANE and/or specifically
"smtp_tls_security_level = dane" in Postfix. I seek enlightenment.
For a signed MX host zone, existence or non-existence of its TLSA RRs
must be validatable via proper responses from its DNS servers. Some
domains run with shoddy nameservers, that mishandle denial of
existence.
I have a little list... It is dominated by 300-400 domains each that
are
DNS-hosted by axc.nl and neustar (aka ultradns, ...), but there are
also
some others. A tiny fraction of ~12.5 million domains without such
DNSSEC issues, but not zero.
Indeed there was and is no TLSA record for the target machine, but it
does have a CA-issued certificate.
That CA issued certificate is not pertinent.
Oddly, it answers with a banner full of asterisks but it also
advertises STARTTLS if you give it a EHLO.
The banner is not important. I think Postfix always uses EHLO
these days, regardless of whether "ESMTP" is present in the banner.
After I switched smtp_tls_security_level from "dane" to "may" the
mail
went through BUT only as plaintext because apparently Postfix saw
that
**** banner and decided to enable the PIX workarounds (including
disable_esmtp.)
I'm sure you know how to turn that workaround off. So far, you
haven't gotten to the DANE-related part.
Sep 2 13:58:49 be03 postfix/smtp[46493]: 4BhQWH3Gq7zBsQ1:
to=<redactedus...@deaecom.gov>, relay=none, delay=46,
delays=0.15/0.01/46/0, dsn=4.7.5, status=deferred (TLSA lookup error
for
mail.deaecom.gov:25)
For the domain above, I am able to resolve the TLSA RRs via my
resolver.
Able to resolve the non-existence, yes. Me too.
So it it seems that you need to troubleshoot your resolver.
deaecom.gov. IN MX 10 mail.deaecom.gov. ; NoError AD=1
mail.deaecom.gov. IN A 149.101.26.25 ; NoError AD=1
mail.deaecom.gov. IN AAAA ? ; NODATA AD=1
_25._tcp.mail.deaecom.gov. IN TLSA ? ; NXDomain AD=1
Yes, I see the same:
[root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
; <<>> DiG 9.16.6 <<>> @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38074
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_25._tcp.mail.deaecom.gov. IN TLSA
;; AUTHORITY SECTION:
deaecom.gov. 94 IN SOA dnsgm-dc2.admin.oss.doj.gov. root.usdoj.gov.
2000118898 10800 1080 2592000 600
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 02 20:23:11 UTC 2020
;; MSG SIZE rcvd: 125
I do not understand why Postfix didn't see that as a reason to give up
on DANE.
There's a local instance of Unbound operating as a caching recursive
resolver, so I don't think the UDP edge cases apply: it should be doing
the right thing in regards to using TCP as needed.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
