validation problem

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Sep 4 16:39:43 CEST 2018



> On Sep 4, 2018, at 3:54 AM, Andreas Schulze <andreas.schulze at datev.de> wrote:
> 
> unsure it that topic may better discussed on postfix-users....

This probably belongs on the Postfix-users list, but perhaps not a bad
idea if other DANE users also know.

> I'm messages for <*@sushi-circle.de> in my outbound deferred queue.
> Sep  2 11:15:38 idvmailout02 postfix/smtp[73811]: 422V1C0rjyzNkGv: to=<***@sushi-circle.de>, relay=none, delay=88795, delays=88794/0.24/0.61/0, dsn=4.7.5, status=deferred (TLSA lookup error for login.enterprise-email.com:25)
> Sep  2 11:15:38 idvmailout02 postfix/smtp[73811]: warning: TLS policy lookup for sushi-circle.de/login.enterprise-email.com:TLSA lookup error for login.enterprise-email.com:25
> Sep  2 11:15:38 idvmailout02 postfix/smtp[73811]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again
> Sep  2 11:15:37 idvmailout02 postfix/smtp[73811]: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again
> 
> I wonder, why postfix try to lookup TLSA Records for the MX at all. The destination domain sushi-circle.de is unsigned and so any TLSA for the MX don't matter.
> Is there any switch to influence that behavior?

http://www.postfix.org/postconf.5.html#smtp_tls_dane_insecure_mx_policy.

Bottom line, DNSSEC-signed domains need to have working DNSSEC.  You
can disable DNSSEC for enterprise-email.com in your resolver and fix
all the domains (~40 according to viewdns.info) that happen to use its
MX hosts.  In unbound that would be:

/etc/unbound/unbound.conf:
   server:
	domain-insecure: "enterprise-email.com"

However, in this case the real issue is that the nameservers for
enterprise-email.com don't handle empty non-terminals correctly:

  http://dnsviz.net/d/_25._tcp.login.enterprise-email.com/dnssec/

An alternative fix is to disable qname-minimization (which does
run into interop issues in such cases):

   server:
      qname-minimisation: no

Then you'll find that the TLSA records actually exist!  And mail
to this domain will be partly protected by DANE (barring forged
MX records, which leave forensic evidence in your logs).

-- 
	Viktor.



More information about the dane-users mailing list