xs4all enabled DANE outgoing verification

Viktor Dukhovni ietf-dane at dukhovni.org
Mon Sep 3 13:58:03 CEST 2018

> On Sep 3, 2018, at 6:57 AM, Jan-Pieter Cornet <johnpc at xs4all.net> wrote:
> On smtp.xs4all.nl we enabled DANE outgoing verification, but currently only with a "soft fail": if DANE fails, we fallback to non-DANE delivery... for now. Except for a few hardcoded domains (currently only our own, and havedane.net).

Great news, welcome to the club, and thanks!  When you do enable a default
hardfail, you might consider exempting a particular sender address or subject
tag, or perhaps a custom header:


so that you can still send email to the contacts of any domains that are 
failing, prior to disabling DANE for the domain for all senders.

You might find that some domains have intermittent outages as a result of poorly
executed key/cert rollovers where the TLSA records are updated *after* they first
become invalid.  For any of those, soft fail may make sense until your logs show
no failures for a year or more.

> As a word of caution to other would-be DANE implementers: we also had problems with a domain that was not on the dane-fail list. This domain had DNSSEC and TLSA records for the MX host, but did not offer STARTTLS. That would be a huge red flag, and fortunately we had the softfail fallback so mail kept on being delivered. After investigating, it turned out that this domain had *my* IPs in an exception list of "do not offer TLS", because a few years ago we hit some sort of timeout bug that caused hanging connections. The hanging connection bug has since been solved, but the IP exception was still there...
> So the moral of the story is: next to the domains in the dane-fail list, there might be local exceptions that might apply, so keep an eye on your logfiles.

Indeed the danefail list is not expected to be "complete".  If any of you run
into domains for which you need to make an exception, please open an issue or
pull request on github if unable to resolve with the remote domain.

For those publishing TLSA records for inbound DANE, please make *sure* that
you're offering STARTTLS *unconditionally*, to all SMTP clients with no
restrictions by client IP address or reputation.  Configurations that
restrict STARTTLS to a set of "good" IPs are not compatible with DANE.
If STARTTLS was disabled with some client IPs for interoperability reasons,
resolve those first.


More information about the dane-users mailing list