3

we are running a mail server and always the same error in the logs (for a specific recipient):

Aug 23 05:39:17 Mailer postfix/smtp[13561]: warning: DANE
    TLSA lookup problem: Host or domain name not found. Name 
    service error for name=_25._tcp.dhmx02.web.de type=TLSA:
    Host not found, try again
Aug 23 05:39:17 Mailer postfix/smtp[13561]: warning: TLS
    policy lookup for xyz.com/dhmx02.web.de: TLSA lookup
    error for dhmx02.web.de:25
Aug 23 05:39:17 Mailer postfix/smtp[13561]: 9BEA23EC68:
    to=<[email protected]>, relay=none, delay=4509,
    delays=4236/0.05/272/0, dsn=4.7.5, status=deferred
    (TLSA lookup error for dhmx02.web.de:25)

The emails come back with the following information:

This is the mail system at host mx00.unser-mail-server.com.
I'm sorry to have to inform you that your message could not
 be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
 delete your own text from the attached returned message.
The mail system
<[email protected]>: TLSA lookup error for dhmx02.web.de:25
Reporting-MTA: dns; mx00.unser-mail-server.com
 X-Postfix-Queue-ID: 9BEA23EC68
 X-Postfix-Sender: rfc822; [email protected]
 Arrival-Date: Mon, 23 Aug 2021 04:24:08 +0200 (CEST)
Final-Recipient: rfc822; [email protected]
 Original-Recipient: rfc822;[email protected]
 Action: failed
 Status: 4.7.5
 Diagnostic-Code: X-Postfix; TLSA lookup error for dhmx02.web.de:25

The following software is used on the server (Debian 10):

root|mailer|/etc/rspamd|# dpkg --list | egrep -i -- "(unbound|postfix|rspam|dovecot)"                                                             
ii  dovecot-core                   1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - core files                            
ii  dovecot-imapd                  1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - IMAP daemon                           
ii  dovecot-lmtpd                  1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - LMTP server                           
ii  dovecot-managesieved           1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - ManageSieve server                    
ii  dovecot-mysql                  1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - MySQL support                         
ii  dovecot-sieve                  1:2.3.4.1-5+deb10u5               amd64        secure POP3/IMAP server - Sieve filters support                 
ii  libunbound8:amd64              1.9.0-2+deb10u2                   amd64        library implementing DNS resolution and validation              
ii  postfix                        3.4.14-0+deb10u1                  amd64        High-performance mail transport agent
ii  postfix-mysql                  3.4.14-0+deb10u1                  amd64        MySQL map support for Postfix
ii  rspamd                         2.5-1~bpo10+1                     amd64        Rapid spam filtering system
ii  unbound                        1.9.0-2+deb10u2                   amd64        validating, recursive, caching DNS resolver
ii  unbound-anchor                 1.9.0-2+deb10u2                   amd64        utility to securely fetch the root DNS trust anchor

Unbound is used as resolver on the server, can this be the reason?

How can I fix the TLSA lookup error for dhmx02.web.de:25? IT seems that it's realated to the receivers server, but he claims that he can't receive emails only from our mail server.

Does anyone have a clue how to solve the problem?

3
  • That doesn't quite add up. Post all the mail server logs for that particular message. Commented Aug 23, 2021 at 14:24
  • @MichaelHampton thanks for letting me know, I just uploaded additional log entries - I could not add any more of it, there's no more information regarding this message. It seems like the domain xyz.com is misconfigured in terms how it uses dhmx02.web.de as an email relay. What do you think?
    – manifestor
    Commented Aug 23, 2021 at 15:36
  • As far as I can see, xyz.com is using googlemail, not web.de MX.. (bad obfuscation?)
    – anx
    Commented Aug 31, 2021 at 17:25

1 Answer 1

0

This appears to be a bug in systemd-resolved when you use the "stub" resolver. I saw loads of comparable messages in my Postfix 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 (default on Ubuntu 22.04):

$ cat /etc/resolv.conf | grep nameserver
nameserver 127.0.0.53

$ 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:

$ 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
;; resolution failed: ncache nxrrset
; negative response, fully validated
; _25._tcp.cluster5.us.messagelabs.com. 299 IN \-TLSA ;-$NXRRSET
; _25._tcp.cluster5.us.messagelabs.com. RRSIG NSEC ...
; _25._tcp.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
; messagelabs.com. SOA ns-1714.awsdns-22.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
; 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 solution was to not use the systemd-resolved stub resolver. 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:

systemctl restart systemd-resolved
systemctl restart postfix

BTW: not sure if this could be considered a Postfix bug (as well), but surely it seems systemd-resolved should not return the SERVFAIL here.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .