On 2019-06-15 12:11, I wrote:
One of my subscribers recently signed his or her zone, and sadly, has a wildcard A in that zone. Unfortunately at this point I do have to keep that zone name private, although offlist I'd tell it to someone I know and consider trustworthy to maintain the user's confidence.
The immediate problem has been solved with a bandaid, smtp_tls_policy_maps, with an entry:
example.com may
This overrides the global "smtp_tls_security_level = dane" setting, and I've confirmed that I can send mail to the subscriber now.
Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I already DID tell you the zone name. :) Starts with "a" and is in com. TLD. The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA".
So Postfix is refusing to deliver, believing that there should be a TLSA. But AFAIK this user never published TLSA.
The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that. But I don't know how that feature interacts with wildcard records.
Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.
I still think this is an interesting problem, perhaps a BIND problem. The user didn't set a TLSA and might have had no idea about DANE ("isn't that what Hamlet was?") and yet was unable to get mail from my DANE- enabled host.