DANE is a policy, which should be promoted and become widespread. In order to improve Postfix and help other people attempting to implement DANE I am writing to this list.
In order to obtain the goal above it is important, that DANE must be easy to implement. As a consequence software used to implement DANE must support the implementation process, both in easy understandable documentation and functionally as e.g. logging and simple configuration. I found missing elements in both Postfix (logging and documentation) and BIND (missing full implementation of RFC 4035 3.1.6). 1) Postfix Later I have found the posttls-finger program in the Postfix distribution, but the logging in this program should be present in the Postfix smtp itself when using the smtp_tls_loglevel parameter (and still improvements in the documentation are needed) 2) BIND It has only a partial implementation of the RFC 4035 AD bit handling. This, however, must be handled in another forum than this. We have been using BIND since 2001 (DNSSEC since 2013) as an authoritative name server for many domain names as well as a recursive resolver for all PCs on the LAN. It has been working flawlessly. It is not an option to have to mess around with additional resolvers and name servers just to implement DANE. 3) TLS-SNI Single point of failures occur, when there is only one certificate for all virtual domains on a server and not one for every virtual domain. If the single certificate has expired or is damaged, mail for all customers is locked out from using TLS connections. - Jørgen Thomsen On Thu, 15 Nov 2018 12:53:51 -0800,Gene Hightower <g...@digilicious.com> wrote: >On 15/11/2018 07.32, J. Thomsen wrote: > >> Recently I have been struggling with configuring DANE and DNSSEC for >> a domain, for which my DNS is authoritative. > >I applaud your struggle. > >> DNSSEC is not the problem, but there are issues in setting up DANE >> in postfix, hvis could be improved > >Your client side DNSSEC setup may be a problem, see below: > >> 2) problem with no ad flag when the resolver is querying an >> authoritative DNS > >To use DNSSEC you typically need secure access to a recursive resolver >that supports DNSSEC. This could be a library linked to your app, or >a server (that you can trust) running someplace. > >On Fedora you may want to check out the dnssec-trigger package. > >> In this case Postfix is running on the same server as the >> authoritative server and using it as a recursive resolver. > >So you want to make sure that any recursive resolver functionality is >not made publicly available. Your authoritative server for your own >domain must, of course, be publicly facing. > >I run separate DNS servers for serving authoritative data for public >domains and for recursive lookup (and caching) for local applications. > >Either application or both can be bind (named) or unbound or whatever >software. > >> I had to change the resolv.conf file to an external DNS, but for >> various reasons this will not work properly in all cases. > >Remember, you must trust that external DNS server and every (plain >text or unenciphered) network hop in between. > >More typically you want to point your resolv.conf to a local unbound >or named server. > >> This issue should be solved, and at least be mentioned in the >> documentation for DANE, as it can be a showstopper. > >If I understand you correctly, this is a DNSSEC issues, more so than a >postfix issue. > >> 3) TLS SNI > >> The documentation states, that there are no plans to implement SNI >> in the Postfix SMTP server. >> Is this still valid? > >With email, the MX record decouples the domain in an email address >with the domain(s) in the cert that your mail server may present. > >> From my recent experience I can see, that other mailservers do >> implement it. > >Do they? I do in my own mail server and client. Not sure how >generally useful it all is. What email software cares about such >things? > >> With the easy certificates obtainable from LetsEncrypt and many >> virtual host on the same server, it may be time to reevaluate this >> policy. > >Your email domains may use MX records to point email delivery to any >other set of servers, identified by any other domains. > >> Also to eliminate single points of failure. > >I have no idea how SNI could relate to such issues. Please explain. >
