This issue surface when researching the issue that Postfix on my system (with DANE enabled) deferred mail deliveries with 100s of this warning in the log:
Warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.cluster5.us.messagelabs.com type=TLSA: Host not found, try again
The DNS resolver on my machine was pointing at the systemd-resolved stub:
$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
resolv.conf mode: stub
Note DNSSEC is enabled (else Postfix couldn't be doing DANE). Now if I query the TLSA record for the messagelab server, I get a SERVFAIL from the stub resolver:
I assume Postfix (with smtp_tls_security_level = dane i.e. "Opportunistic DANE") deals with the negative response by downgrading to "encrypt", whereas the SERVFAIL response makes it refuse to connect altogether.
My workaround was to switch from the systemd-resolved stub resolver to the upstream servers. In /etc/systemd/resolved.conf set:
DNS=... your upstream servers if not already given through DHCP ...
DNSStubListener=no
Then restart the service and restart Postfix if it is chrooted (so the new /etc/resolv.conf gets copied into the chroot):
I am not sure if this could be considered a Postfix bug as well (it could consider a SERVFAIL on a TLSA record the same as a negative), but surely it seems to me the systemd-resolved stub resolver should not return the SERVFAIL here.
This issue surface when researching the issue that Postfix on my system (with DANE enabled) deferred mail deliveries with 100s of this warning in the log:
Warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25. _tcp.cluster5. us.messagelabs. com type=TLSA: Host not found, try again
The DNS resolver on my machine was pointing at the systemd-resolved stub:
$ cat /etc/resolv.conf | grep nameserver
nameserver 127.0.0.53
$ resolvectl status allow-downgrade /supported
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=
resolv.conf mode: stub
Note DNSSEC is enabled (else Postfix couldn't be doing DANE). Now if I query the TLSA record for the messagelab server, I get a SERVFAIL from the stub resolver:
$ delv +dnssec _25._tcp. cluster5. us.messagelabs. com TLSA
;; resolution failed: SERVFAIL
Whereas if I query my upstream DNS or Google DNS, I get a DNSSEC validated (negative) response:
$ delv @8.8.8.8 +dnssec _25._tcp. cluster5. us.messagelabs. com TLSA cluster5. us.messagelabs. com. 299 IN \-TLSA ;-$NXRRSET cluster5. us.messagelabs. com. RRSIG NSEC ... cluster5. us.messagelabs. com. NSEC \000._25. _tcp.cluster5. us.messagelabs. com. A PTR HINFO MX TXT RP AAAA SRV NAPTR SSHFP RRSIG NSEC SVCB HTTPS SPF IXFR AXFR CAA awsdns- 22.co.uk. awsdns- hostmaster. amazon. com. 1 7200 900 1209600 86400
;; resolution failed: ncache nxrrset
; negative response, fully validated
; _25._tcp.
; _25._tcp.
; _25._tcp.
; messagelabs.com. SOA ns-1714.
; messagelabs.com. RRSIG SOA ...
I assume Postfix (with smtp_tls_ security_ level = dane i.e. "Opportunistic DANE") deals with the negative response by downgrading to "encrypt", whereas the SERVFAIL response makes it refuse to connect altogether.
My workaround was to switch from the systemd-resolved stub resolver to the upstream servers. In /etc/systemd/ resolved. conf set:
DNS=... your upstream servers if not already given through DHCP ... ener=no
DNSStubList
Then restart the service and restart Postfix if it is chrooted (so the new /etc/resolv.conf gets copied into the chroot):
systemctl restart systemd-resolved
systemctl restart postfix
I am not sure if this could be considered a Postfix bug as well (it could consider a SERVFAIL on a TLSA record the same as a negative), but surely it seems to me the systemd-resolved stub resolver should not return the SERVFAIL here.
For more background on this bug report, please see https:/ /serverfault. com/a/1158198/ 299950