Viktor Dukhovni:
> > On Apr 17, 2020, at 5:21 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> > Possibly, but rest assured that all such features will remain disabled
> > by default for at least one year after there is wide deployment of
> > code that manages the new resolv.conf flag, and there is a documented
> > record of the new failure modes that come with this.
>
> One interesting idea is to set the "smtp_tls_security_level" and
> "smtp_dns_support_level" (when not explicitly set by the user in
> main.cf) based on the value of the "RES_TRUSTAD" bit reported by
> the stub resolver:
>
> - defaults = (may, enabled) if RES_TRUSTAD is not set
> - defaults = (dane, dnssec) if RES_TRUSTAD is set.
>
> We would still then (for some time by default, subject to further
> configuration) set RES_TRUSTAD when not already set in resolv.conf,
> so we'd not breaking DANE for anyone who turned it on explicitly,
> but we might *infer* interest in DANE support from the RES_TRUSTAD
> bit, and then turn on DANE by default only when the resolver settings
> are liable to be correct.
>
> The downside might be that the stability of "options RES_TRUSTAD"
> may not be as good as we might wish. So you'd have DANE on some of
> the time, and off other times, but perhaps appropriately so, if your
> resolver settings are that unstable.
Use cases
1) Infrastructure mail server. DNS configuration is not supposed
to change. People who care about TLSA/DANE will provision a secure
and stable DNS resolver.
2) Personal laptop, roaming between trusted and untrusted networks.
People who care about their email won't send directly to arbitrary
remote destinations. Instead they will relay through a trusted
infrastructrure server (see above), and not rely on TLSA/DANE.
3) ???
What use cases did you have in mind?
Wietse
