Hello Viktor, thanks for looking into it! >A signed TLSA "2 1 1" record for mx03 matching the Let's Encrypt "R3" >intermediate issuer. You should really also publish at least also a TLSA >record matching "R4" key. See
> https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html Thanks for the advice, but actually I implemented monitoring that I never install a renewed certificate that does not match the published TLSA. Will consider anyway. >> mx04.et.lindenberg.one. IN A 82.165.56.12 ; NoError AD=1 >> mx04.et.lindenberg.one. IN AAAA 2001:8d8:1801:28c::1:4 ; NoError AD=1 >> _25._tcp.mx04.et.lindenberg.one. IN CNAME _selftlsa.lindenberg.one. ; >> NoError AD=1 >> _selftlsa.lindenberg.one. IN TLSA 3 1 1 >> fe950f86708244329b4675b7adc120ee2d3f66a90c01449c8c24fea99f3e2909 ; NoError >> AD=1 >A signed TLSA "3 1 1" record for "mx04". Yes. I want to test some interoperability and error scenarios. The fact that some of the TLSA records don’t match the certificates (whether LE or self-signed) is not the issue, as postfix doesn´t connect. >> When I send a mail from my postfix however, postfix reports “no TLSA >> records found“. Or full log entries: >> >> warning: TLS policy lookup for et.lindenberg.one/et.lindenberg.one: no >> TLSA records found 49B4E0EAC: to=<t...@et.lindenberg.one>, relay=none, >> delay=49105, delays=49104/0.04/0.51/0, dsn=4.7.5, status=deferred (no >> TLSA records found) >Typically this suggests that you're not querying a validating DNS resolver, or >are using a recent glibc with requires the "trustad" option to be set, ... Sure. That´s why I tested a differend dane domain (with TLS policy dane-only) and it worked. And see below. >> I can confirm smtp_dns_support_level = dnssec is set, and >> smtp_host_lookup is not set (default). I also confirmed DNSSEC is >> working by sending a test mail to some other DANE site successfully >> (with a TLS policy dane-only). >> >> The only difference I noticed is that the other site uses a TLSA 2 0 1 >> … whereas I use 2 1 1. >You're doing better than they are. When I wrote RFC 7671 it seemed at the >time that "2 0 1" would be the better choice. History proved otherwise. Thanks, but I researched a little, and also noticed you are the expert. >> Is postfix more picky than other tools? A configuration issue? Or >> anything else I should watch out for? >Is the recursive nameserver you're querying (typically BIND) also an >authoritative server for "et.lindenberg.one"? If so, it may not set the "AD" >bit in responses for this domain, setting the "AA" bit instead. >Postfix does not presently treat the "AA" bit as an indication of a secure >answer. Typically your recursive resolver is not also an authoritative server >for any zones (best-practice separation of duties). This is a mailcow-dockerized installation. It uses unbound as the recursive resolver, and as it resolved the other dane domain flawlessly I suspect it is configured properly. My authoritative NS are cloudflare´s. >I've considered treating "AA" as equivalent to "AD" (perhaps subject to a >non-default configuration option). But this has not been implemente as of yet. >-- > Viktor. I am really wondering why it works for one domain and doesn´t for mine. Thanks a lot! Joachim
