Hi!
I'm testing the new exim 4.85 DANE support and it took only some days to
get in trouble...
One of our users tried to send mail to the domain education.lu.
Their domain and MX hosts are DNSSEC enabled and have TLSA RRs.
The DANE validator
https://dane.sys4.de/smtp/education.lu
says: "Unusable TLSA Records". Most likely because it is type 1 not allowed
for DANE-SMTP?
I've set hosts_try_dane = * in my SMTP transport.
Exim refuses to talk to those hosts at all with "failure while setting up
TLS session". Is this expected behavior in terms of DANE-SMTP? What's
postfix doing in this case?
Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha(a)gmx.net> | http://www.blafasel.at/
Vienna University Computer Center | Austria
Hi,
can you confirm that addons.mozilla.org has a broken DANE entry?
The DNSSEC Validator plugin in Firefox says "no DNSSEC at
addons.mozilla.org" but "invalid DNSSEC signature".
CU
Andreas
After a 2 and a half year process, the DANE SMTP and DANE OPS drafts
are now published IETF RFCs:
https://tools.ietf.org/html/rfc7671
-----------------------------------
The DNS-Based Authentication of Named Entities (DANE) Protocol:
Updates and Operational Guidance
This document clarifies and updates the DNS-Based Authentication of
Named Entities (DANE) TLSA specification (RFC 6698), based on
subsequent implementation experience. It also contains guidance for
implementers, operators, and protocol developers who want to use DANE
records.
https://tools.ietf.org/html/rfc7672
-----------------------------------
SMTP Security via Opportunistic DNS-Based Authentication of Named
Entities (DANE) Transport Layer Security (TLS)
This memo describes a downgrade-resistant protocol for SMTP transport
security between Message Transfer Agents (MTAs), based on the DNS-
Based Authentication of Named Entities (DANE) TLSA DNS record.
Adoption of this protocol enables an incremental transition of the
Internet email backbone to one using encrypted and authenticated
Transport Layer Security (TLS).
It is now time to shift my attention back to implementation in TLS
libraries. The community can help by promoting adoption, and making
sure that your deployment stays valid at all times. Please pay close
attention to:
https://dane.sys4.de/common_mistakes#3https://dane.sys4.de/common_mistakes#8https://tools.ietf.org/html/rfc7671#section-8.1https://tools.ietf.org/html/rfc7671#section-8.4https://tools.ietf.org/html/rfc7672#section-3.1.1https://tools.ietf.org/html/rfc7672#section-3.1.2https://tools.ietf.org/html/rfc7672#section-3.1.3
Just in case you overlooked something, please always retest your
domain's TLSA records after deploying fresh certificates and/or
private keys.
https://dane.sys4.de
--
Viktor.
Hi,
one of my DNSSEC/DANE secured domains started breaking as of today and I
do not fully understand why.
Probably bright people here can point me to the correct resolution?
I'm using bind and its
auto-dnssec maintain;
inline-signing yes;
Also I'm not aware that my KSK and ZSK keys have any expiration date but
today DNSSEC started to fail apparently because my RRSIG signatures are
said to be expired.
Actually my first idea is that the automatic maintenance in bind failed
for some reason. So I deleted the journal and signed zone files and
started over by signing the zone from scratch. This at least improved
the situation a little bit according to
http://dnsviz.net/d/rosenauer.org/dnssec/
But still it seems to be broken and I'm lost currently to understand
what is wrong.
Thanks for any pointers,
Wolfgang
