[pfx] Re: Behavior of smtp_tls_security_level = dane
Hallo, On my machine, the authoriative server (BIND) only listends on the the ethernet IP interface, while the recursive server (unbound) listends only on 127.0.0.1. It validates queries for my own domain, just like for any other. I wanted to prevent installing and caring for two software instances on such a minor system. So two tasks for me: a) fix the internal DNSSEC issue Nothing to fix in DNSSEC, rather, split the auth and recursive resolvers. We'll see. Maybe I can convince bind to be a recursive resolver on the local interface and ask itself via the external interface for the own domains. Essentially your setup, but only with bind. I thought I did so in the past, but it also may be I simply forgot about it. I believe bind doesn't offer the easy way to simply check and add ad flags for it's own domains when used as recursive resolver. Or maybe I'll document situation and simply ignore the missing DANE for these two hosts ;-) For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
Hello, DANE TLSA records are strictly enforced when "well-formed", where well-formed also requires a plausible TLSA "associated data" field (expected length for SHA2-256 and SHA2-512 digests and valid DER encoding of certs or keys for matching type Full(0)). That's what I did expect. Starting with the fact that what I expect is also what should haven happened I reviewed the whole system. The reason somewhere lies in DNSSEC. The mail sending server is also the domain server for the internal target domain. When I send mail to the target from somehwere else DANE works (with updated TLSA). From the server which has the local name server the answer has the aa flag, but not the ad flag. I have to investigate what's broken here. Either a configuration change or an update broke something. It was hidden as no negative side effects were visible (I hate it when stuff fails and it's invisible, except in some logs). So two tasks for me: a) fix the internal DNSSEC issue b) monitor internal DANE as well Lesson learned: Not only external stuff must be monitored thoroughly. ;-) P.S. For https://www.postfix.org/TLS_README.html#client_tls_dane maybe the third paragraph could have added: "If there are usable, but mismatching TLSA entries, no mail is sent."? For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Behavior of smtp_tls_security_level = dane
Hello, I recently did a misconfiguration of an internal mail server for a test system and as a result broke the TLSA record. Postfix still delivered mail to the system now with Trusted instead of Verified (BTW I find these two outputs texts misleading, each time I check the logs I look for a reference server to know which of the two is which, couldn't you find something more explicit?). That was a really unexpected behavior for me so I looked in the documentation for "smtp_tls_security_level = dane" in https://www.postfix.org/TLS_README.html#client_tls_dane and really there it says "If TLSA records are published for a given remote SMTP server (implying TLS support), but are all "unusable" due to unsupported parameters or malformed data, the Postfix SMTP client will use mandatory unauthenticated TLS." Now I understand the rationale behind this. You want to prevent mail breaking because of too many bad configurations, but in this case I think a more strict DANE setting is missing: * I agree that at the moment it can be a good idea not to enforce DANE for "unsupported parameters" or "malformed data" (even though I think there should be a way to make this an error). * But I would expect that DANE is enforced when data is well-formed and with supported parameters but simply wrong, like in my case old. Would it be possible to add a "dane-strict" setting which enforces correct DANE always, when there are TLSA records or at least acceptable but not matching TLSA records (I assume changing "dane" option is out of the question)? For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
