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.
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
There could be a UDP buffer size issue here, these days BCP is for
resolvers that may sit behind various sources of stateful firewalls, ...
to limit EDNS buffer sizes low enough to ensure that replies are
never fragmented en-route.
Here's a request with an EDNS buffer size of 1232 directly to the
target domain:
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc31 <<>> +ignore +bufsize=1232 +dnssec
-t tlsa _25._tcp.mail.deaecom.gov. @ns-jdcw-01.usdoj.gov.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41956
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: e8634cf7e0bf55b5b8022e455f502f70ed341f29f85b0c4d (good)
;; QUESTION SECTION:
;_25._tcp.mail.deaecom.gov. IN TLSA
;; Query time: 35 msec
;; SERVER: 2607:f330:6000:107f::86#53(2607:f330:6000:107f::86)
;; WHEN: Wed Sep 02 23:49:05 UTC 2020
;; MSG SIZE rcvd: 82
They send back an 82-byte truncated response, and if you leave off
"+ignore", TCP fallback works and receives a full answer. But also
(from my network), using a default EDNS buffer size (which results
in UDP fragments):
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc31 <<>> +dnssec -t tlsa
_25._tcp.mail.deaecom.gov. @ns-jdcw-01.usdoj.gov.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19408
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 667c34af4d53ffe400a2a3355f502f95a1ea20aeb8922408 (good)
;; QUESTION SECTION:
;_25._tcp.mail.deaecom.gov. IN TLSA
;; AUTHORITY SECTION:
deaecom.gov. 600 IN SOA
dnsgm-dc2.admin.oss.doj.gov. root.usdoj.gov. 2000118899 10800 1080 2592000 600
deaecom.gov. 600 IN RRSIG SOA 8 2 600 20200912211637
20200902201637 20724 deaecom.gov. <sig>
deaecom.gov. 600 IN RRSIG SOA 8 2 600 20200912211637
20200902201637 35760 deaecom.gov. <sig>
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 600 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 EHMJ33K8REDE558E2VD9TSTFLG1HO30U A TXT RRSIG
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov. <sig>
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov. <sig>
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 600 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 Q4UAST9AOGHUCL7KL6FKFSLJ2DPTU9HP A RRSIG
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov. <sig>
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov. <sig>
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 600 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov. <sig>
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 600 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov. <sig>
;; Query time: 32 msec
;; SERVER: 2607:f330:6000:107f::86#53(2607:f330:6000:107f::86)
;; WHEN: Wed Sep 02 23:49:41 UTC 2020
;; MSG SIZE rcvd: 1788
They're double-signing the zone with two RSA ZSKs, which results in 8
signatures for 1 SOA and 3 NSEC3 RRs. The result is bigger than the MTU
on the vast majority of networks.
This will definitely be fragmented, ... and then, ... it depends...
Configure your resolver with an EDNS buffer size somewhere between 1232
(recommended by some) and 1400 (recommended by others).
--
Viktor.
