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.
