Mail deferred: TLSA lookup error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Mail deferred: TLSA lookup error

Bill Cole-3
I had a message defer indefinitely, ostensibly due to the lack of a TLSA
record, 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.

Indeed there was and is no TLSA record for the target machine, but it
does have a CA-issued certificate. Oddly, it answers with a banner full
of asterisks but it also advertises STARTTLS if you give it a EHLO.
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.) Thus outbound gateway has been delivering hundreds of
messages per day with TLS to other targets without any difficulties for
months. Today it has made 683 successful TLS client connections so far.

The Postfix instance is an outbound gateway on a FreeBSD 12.1p6 VM. It
is currently running Postfix 3.5.4, from the FreeBSD binary package.

Log lines for the relevant message:

[root@be03 ~]# grep 4BhQWH3Gq7zBsQ1 /var/log/maillog
Sep  2 13:58:03 be03 postfix/smtpd[46490]: 4BhQWH3Gq7zBsQ1:
client=mail.uscrules.com[REDACTEDIP]
Sep  2 13:58:03 be03 postfix/cleanup[46492]: 4BhQWH3Gq7zBsQ1:
message-id=<BCFA6F0E-B696-4510-88EE-2446CD6154C8@REDACTEDDOM2>
Sep  2 13:58:03 be03 postfix/qmgr[6807]: 4BhQWH3Gq7zBsQ1:
from=<REDACTEDUSER2.com>, size=2075122, nrcpt=1 (queue active)
Sep  2 13:58:49 be03 postfix/smtp[46493]: 4BhQWH3Gq7zBsQ1:
to=<[hidden email]>, 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)
Sep  2 14:07:59 be03 postfix/qmgr[6807]: 4BhQWH3Gq7zBsQ1:
from=<REDACTEDUSER2.com>, size=2075122, nrcpt=1 (queue active)
Sep  2 14:08:45 be03 postfix/smtp[47343]: 4BhQWH3Gq7zBsQ1:
to=<[hidden email]>, relay=none, delay=642,
delays=596/0.02/46/0, dsn=4.7.5, status=deferred (TLSA lookup error for
mail.deaecom.gov:25)
Sep  2 14:08:45 be03 postfix/bounce[47374]: 4BhQWH3Gq7zBsQ1: sender
delay notification: 4BhQld2sgmzBsV5
[ Many repeats elided ...]
Sep  2 20:15:06 be03 postfix/qmgr[81586]: 4BhQWH3Gq7zBsQ1:
from=<REDACTEDUSER2.com>, size=2075122, nrcpt=1 (queue active)
Sep  2 20:15:53 be03 postfix/smtp[82546]: 4BhQWH3Gq7zBsQ1:
to=<[hidden email]>, relay=none, delay=22670,
delays=22623/0.06/46/0, dsn=4.7.5, status=deferred (TLSA lookup error
for mail.deaecom.gov:25)
Sep  2 20:21:45 be03 postfix/qmgr[81586]: 4BhQWH3Gq7zBsQ1:
from=<REDACTEDUSER2.com>, size=2075122, nrcpt=1 (queue active)
Sep  2 20:21:46 be03 postfix/smtp[83698]: 4BhQWH3Gq7zBsQ1: enabling PIX
workarounds: disable_esmtp delay_dotcrlf for
mail.deaecom.gov[149.101.26.25]:25
Sep  2 20:21:56 be03 postfix/smtp[83698]: 4BhQWH3Gq7zBsQ1:
to=<[hidden email]>,
relay=mail.deaecom.gov[149.101.26.25]:25, delay=23033,
delays=23023/0.01/0.1/11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as ADE4E10405B)
Sep  2 20:21:56 be03 postfix/qmgr[81586]: 4BhQWH3Gq7zBsQ1: removed


postconf -n:

command_directory = /usr/local/sbin
compatibility_level = 2
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 90s
enable_long_queue_ids = yes
header_checks = pcre:$config_directory/header_checks
html_directory = /usr/local/share/doc/postfix
inet_interfaces = be03-outbound.REDACTEDDOMAIN
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 1d
meta_directory = /usr/local/libexec/postfix
myhostname = be03-outbound.REDACTEDDOMAIN
mynetworks = REDACTEDNET
mynetworks_style = subnet
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_security_level = dane
smtpd_relay_restrictions = permit_mynetworks,reject
unknown_local_recipient_reject_code = 550

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Viktor Dukhovni
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=<[hidden email]>, 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Bill Cole-3
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=<[hidden email]>, 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
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Marcel de Riedmatten
Le mercredi 02 septembre 2020 à 23:11 -0400, Bill Cole a écrit :
> On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:

> > On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:

> 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.

Hi 

a shot in the dark: may be your unbound has   

qname-minimisation: yes

In the  past Viktor has been giving the tip to deactivate that. When i
set up my outgoing DANE i got some unexplain dns issue which have
disapeared after removing the minimisation. The minimisation was a
default setting.

-- 
Marcel de Riedmatten
  

Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Viktor Dukhovni
In reply to this post by Bill Cole-3
On Wed, Sep 02, 2020 at 11:11:32PM -0400, Bill Cole wrote:

> > For the domain above, I am able to resolve the TLSA RRs via my
> > resolver.
>
> Able to resolve the non-existence, yes. Me too.

See below.

> Yes, I see the same:
>
> [root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa

That's NOT the same, you're not asking for "+dnssec", which Postfix does
do when resolving DANE TLSA records.

> ; <<>> DiG 9.16.6 <<>> @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38074
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Your resolver claims to have validated the answer (the AD bit is set),
what do you get with "posttls-finger"?

> ;; MSG SIZE  rcvd: 125

For lack of the DO bit, the respose is considerably smaller than it
would otherwise be.  What resolver does Postfix use?  Is the SMTP
client chrooted?  What's in /etc/resolv.conf?

> I do not understand why Postfix didn't see that as a reason to give up
> on DANE.

Postfix uses the traditional BSD stub resolver API, (i.e. libc on many
modern systems, formerly libresolv).  Whatever it sees is what Postfix
sees.

> 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.

Well unbound might well have been failing to resolve this domain for
some reason, you can also test with "unbound-host" and also try dnsviz:

    https://dnsviz.net/d/_25._tcp.mail.deaecom.gov/X1BycA/dnssec/

which shows a working domain, be it with a few too many signatures
in the graph.  All the usual public resolvers are able to validate
it:

    https://dnsviz.net/d/_25._tcp.mail.deaecom.gov/e/218995/dnssec/

Is your unbound forwarding to any of them, configured to use DoH or DoT
perhaps?  Bottom line, if name resolution is failing, Postfix is usually
just the messenger, the bad news is coming from upstream.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Bill Cole-3
In reply to this post by Marcel de Riedmatten
On 3 Sep 2020, at 0:34, Marcel de Riedmatten wrote:

> Le mercredi 02 septembre 2020 à 23:11 -0400, Bill Cole a écrit :
>> On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
>
>>> On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
>
>> 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.
>
> Hi 
>
> a shot in the dark: may be your unbound has   
>
> qname-minimisation: yes
>
> In the  past Viktor has been giving the tip to deactivate that.

Yes, I had found that and put "qname-minimisation: no" into the Unbound
config before posting. It did not fix the problem.

Thanks for the shot in the dark. :)

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Bill Cole-3
In reply to this post by Viktor Dukhovni
On 3 Sep 2020, at 0:43, Viktor Dukhovni wrote:

> On Wed, Sep 02, 2020 at 11:11:32PM -0400, Bill Cole wrote:
[...]
>
>> Yes, I see the same:
>>
>> [root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
>
> That's NOT the same, you're not asking for "+dnssec", which Postfix
> does
> do when resolving DANE TLSA records.

[root@be03 ~]# dig +dnssec _25._tcp.mail.deaecom.gov. tlsa

; <<>> DiG 9.16.6 <<>> +dnssec _25._tcp.mail.deaecom.gov. tlsa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46298
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.mail.deaecom.gov. IN TLSA

;; AUTHORITY SECTION:
deaecom.gov. 518 IN SOA dnsgm-dc2.admin.oss.doj.gov. root.usdoj.gov.
2000118899 10800 1080 2592000 600
deaecom.gov. 518 IN RRSIG SOA 8 2 600 20200912211637 20200902201637
20724 deaecom.gov.
F8r14NTQ7L3MRkYewzs1TUjBEvqXRy9NM4H99DsJFNwj+PVeJiPNmhjI
yvtdXw2kjzexpkX9X4TPGsufkM6lDXOOlOuxagujX01kb/LnTavFQ6p6
y9hnDj7K6ygFSuNlNDXk8C+Zr/aGQh3HO+1rOsx2IM8yV6c13SFStP6s nRM=
deaecom.gov. 518 IN RRSIG SOA 8 2 600 20200912211637 20200902201637
35760 deaecom.gov.
ZC6O+yYCy3TgiuJQorMAD1MRq4pIzz2DWrU8vunG1HfWmph8EDJ64W3L
njacnYNCYF0MzTUbgvG+cVdGjE0eoMnp7sBke+ZQieO5vpgwK+FTcbDm
4pL87jiW7uUyHI1gcIGxQVCBHI1iO+xhZkEAz0S0auaWHy1FKUFXi8Rw Q9Q=
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 518 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 EHMJ33K8REDE558E2VD9TSTFLG1HO30U A TXT RRSIG
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov.
hDRSxC4FdaLm2xzMIZoehQamJ25NND+HaSNzV6q+hyET+YhBICB3OZSh
xiwKBTaJeBE+R8XK6YJEw50BQXAIvq6I3cTJzO+GKDud7tCmXrTPiiew
AYNwrz4uD+SSaseeA9X1c1VPyogdxEigiN9iN4rkg8YBqh5avOSRq3qJ U60=
D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov.
X6ZaSuo5BKaxkZ23q0XCiykE6UZacWPdI1Sk9aU9zvzXmriu4tGw9oZn
sgrsRgFPa/rjORhUns2OgV88v2Yo9VwpF/qJYPyVa31Mt+DcBhFElIfV
rdyVKZT4One6oRFDVJqCce950xw4cIuGBi7Vcw3+n3eADkGc3onjq/MC 9KY=
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 518 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 Q4UAST9AOGHUCL7KL6FKFSLJ2DPTU9HP A RRSIG
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov.
MYBtptocGyGZ2+nLtvvQP27cUhmIGDyNaMrHhL0qLjZ+ool5KvM2zLL6
CTxnllRjSh4Cv2DrBr3clH2EeOhY8RaxEZcWFgiOB+3SIzhVOrMq6TeP
Oq+xETfd8PgmVsAYz+jzOZ1rhDtSK2s6EM1fMKwOniEIJt+/9rlWTFFF gbM=
J6B04P8U736RJ4J4MS9LJT6SE10K99J4.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov.
El52YZFjY1NPsMzS6BchrBfk9n+yilbS6ME92fElzTYWOfuz0276bu2L
G9UVJTDAvFZW+h1n3+vCo2iVOM32nNCPcbzX+sQMAKXQnJ6T9UpKeoHx
dt6VEPV+S4yXOTrU/pBthA5eJmo8DV850ZmhRMc6/PSyHlUxbXXByzkw Hbo=
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 518 IN NSEC3 1 0 10
F6ED3BBC0C659326C5 D5DIDRUE45LH5RM0HLV12VVSPSO8F8AI
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 20724 deaecom.gov.
GtSHIDoQoCfTs+0JFudr9WNQYnxtZlcEEZIyplNgfnlFgtqRAry4W2GG
UZYE+8cUdcC92oDhy23uOOLctHCvOOeWpe2GGQdi0Q8s+KqjVv4L42GB
mD1f9mssKFCimxrcQktlZb/9jyJ8Gw6r4J/YOrPP8B5pzFcQdYs1/3EQ iv8=
9V32NT7182EOP2KHPTJMS4COSC0L466I.deaecom.gov. 518 IN RRSIG NSEC3 8 3 600
20200910024713 20200831014713 35760 deaecom.gov.
fC54/kHzZJZICujpsK2KU0Mv05vvFSRHVw8Pv4r10prpbcCCmByNTec5
WKD/lu/bqAB4DX3Fw3F+3ghLXQv36McfoCZVDyCl7ZTu8DMVo9/JK3/2
3bIi/6+5j0PIynnFm7Ulnon4A2Poad1KlySSLRjvs8HsvtO5rzwOYcOj UGs=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 03 01:38:29 UTC 2020
;; MSG SIZE  rcvd: 1749


>
>> ; <<>> DiG 9.16.6 <<>> @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38074
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL:
>> 1
>
> Your resolver claims to have validated the answer (the AD bit is set),
> what do you get with "posttls-finger"?

[root@be03 ~]# posttls-finger  mail.deaecom.gov
posttls-finger: Connected to mail.deaecom.gov[149.101.26.25]:25
posttls-finger: < 220 ****************
posttls-finger: > EHLO be03-outbound.cipherspace.net
posttls-finger: < 250-griffon.deaecom.gov
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 10485760
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: mail.deaecom.gov[149.101.26.25]:25: Matched
subjectAltName: mail.deaecom.gov
posttls-finger: mail.deaecom.gov[149.101.26.25]:25 CommonName
mail.deaecom.gov
posttls-finger: certificate verification failed for
mail.deaecom.gov[149.101.26.25]:25: untrusted issuer /C=US/O=DigiCert
Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
posttls-finger: mail.deaecom.gov[149.101.26.25]:25:
subject_CN=mail.deaecom.gov, issuer_CN=DigiCert SHA2 Extended Validation
Server CA,
fingerprint=77:47:67:27:88:B2:89:52:E3:02:79:2F:BC:8D:A9:AC:CE:6C:AC:F7,
pkey_fingerprint=B8:7E:51:C7:E4:5D:52:4F:9C:22:57:45:B6:3C:BE:A0:2E:12:52:F4
posttls-finger: Untrusted TLS connection established to
mail.deaecom.gov[149.101.26.25]:25: TLSv1.2 with cipher
DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO be03-outbound.cipherspace.net
posttls-finger: < 250-griffon.deaecom.gov
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 10485760
posttls-finger: < 250-ETRN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

>> ;; MSG SIZE  rcvd: 125
>
> For lack of the DO bit, the respose is considerably smaller than it
> would otherwise be.  What resolver does Postfix use?

Local Unbound instance.

> Is the SMTP
> client chrooted?

No:

[root@be03 ~]# grep 'smtp$' /usr/local/etc/postfix/master.cf
smtp      unix  -       -       n       -       -       smtp
relay     unix  -       -       n       -       -       smtp

> What's in /etc/resolv.conf?

[root@be03 ~]# cat /etc/resolv.conf
nameserver 127.0.0.1
nameserver REDACT1
nameserver REDACT2

The redacted IPs (public addresses but not for pubic use) are our
general-purpose caching recursive resolvers, both BIND 9.16.6. There's
no indication of the local Unbound failing to respond, so they never
should have been hit.

>> I do not understand why Postfix didn't see that as a reason to give
>> up
>> on DANE.
>
> Postfix uses the traditional BSD stub resolver API, (i.e. libc on many
> modern systems, formerly libresolv).  Whatever it sees is what Postfix
> sees.
>
>> 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.
>
> Well unbound might well have been failing to resolve this domain for
> some reason, you can also test with "unbound-host"

Doesn't seem to be an issue:

[root@be03 ~]# unbound-host -t tlsa -D -v _25._tcp.mail.deaecom.gov
Host _25._tcp.mail.deaecom.gov not found: 3(NXDOMAIN). (secure)

> and also try dnsviz:
>
>     https://dnsviz.net/d/_25._tcp.mail.deaecom.gov/X1BycA/dnssec/
>
> which shows a working domain, be it with a few too many signatures
> in the graph.  All the usual public resolvers are able to validate
> it:
>
>     https://dnsviz.net/d/_25._tcp.mail.deaecom.gov/e/218995/dnssec/
>
> Is your unbound forwarding to any of them,

No. This is an outbound relay on the same machine as another MTA that's
doing MX and spam-filtering service, so the local resolver is fully
recursive and autonomous.

> configured to use DoH or DoT
> perhaps?

No.

> Bottom line, if name resolution is failing, Postfix is usually
> just the messenger, the bad news is coming from upstream.

Oh, I get that. Really.

Since I can't see any other incidents like this even with seemingly
similar DNS circumstances, I've reset to "smtp_tls_security_level =
dane" and chalked up this incident to "gremlins" pending a recurrence. A
test message to a bogus address in the target domain with the PIX
workaround "disable_esmtp" shut off did establish a TLS session, so
whatever actually caused it seems to have been transient.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Mail deferred: TLSA lookup error

Viktor Dukhovni
On Thu, Sep 03, 2020 at 06:09:23PM -0400, Bill Cole wrote:

> > Your resolver claims to have validated the answer (the AD bit is set),
> > what do you get with "posttls-finger"?
>
> [root@be03 ~]# posttls-finger  mail.deaecom.gov
> posttls-finger: Connected to mail.deaecom.gov[149.101.26.25]:25
> posttls-finger: < 220 ****************

Already here we see that "posttls-finger" did not report trouble looking
up the TLSA RRs, as it would with e.g. "assugo.be" (one of the 300+
domains affected by broken denial of existence via axc.nl nameservers):

    $ posttls-finger assugo.be
    posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.assugo.be type=TLSA: Host not found, try again
    posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.assugo.be type=TLSA: Host not found, try again
    posttls-finger: Failed to establish session to assugo.be via assugo.be: TLSA lookup error for assugo.be:25
    posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.assugo.be type=TLSA: Host not found, try again
    posttls-finger: Failed to establish session to assugo.be via assugo.be: TLSA lookup error for assugo.be:25

> > Bottom line, if name resolution is failing, Postfix is usually just
> > the messenger, the bad news is coming from upstream.
>
> Oh, I get that. Really.
>
> Since I can't see any other incidents like this even with seemingly
> similar DNS circumstances, I've reset to "smtp_tls_security_level =
> dane" and chalked up this incident to "gremlins" pending a recurrence. A
> test message to a bogus address in the target domain with the PIX
> workaround "disable_esmtp" shut off did establish a TLS session, so
> whatever actually caused it seems to have been transient.

Indeed "transient" seems to be the verdict, and perhaps explains why
others (myself included) could not reproduce the reported symptoms.

--
    Viktor.