On Thu, Nov 27, 2014 at 10:12:01AM +0100, Dirk St?cker wrote:
> after nearly a year I was now able to setup a testing domain which supports
> DANE with a German domain provider. Now I'm in the testing stage to see if I
> did everything right.
>
> DNSSEC-validation is fine:
> http://dnssec-debugger.verisignlabs.com/cryptedmail.eu
Note, the testing done by this site is rather limited, it only
verifies records at the "zone apex" (the top of the domain where
the DNSKEY records live and whose DS records are published in the
parent zone). Some large (especially .nl and .cz) DNS hosting
sites have nameservers that exhibit bugs below the zone apex,
returning incorrent denial of existence (DoE) replies. These can
cause interoperability issues with DANE TLSA.
Though it takes a few seconds longer to return results, I recommend
"dnsviz.net" instead:
http://dnsviz.net/d/_25._tcp.mail.cryptedmail.eu/dnssec/
Since your TLSA record "exists", I've also tested:
http://dnsviz.net/d/_225._tcp.mail.cryptedmail.eu/analyze/
which shows a non-broken DoE response, so it looks your domain is
all set. Though sometimes the issue is triggered by a wildcard at
the zone apex ("*.example.com") that is incorretly applied to
generate "NODATA" rather than "NXDOMAIN" in reply to queries for
"_someport._tcp.mail.example.com" even though "mail.example.com"
exists and should "hide" the wildcard from itself and all child
nodes. You could create a wildcard record (temporarily) and
retest (no need to go to dnsviz for that, a validating nameserver
would SERVFAIL if presented with an incorrect response here).
If you decide to replace your certificate some time around 2023
(with TLSA usage DANE-EE(3) this is optional, "expired" certificates
with matching TLSA records are still valid):
;; Not before = 2013-12-30T12:29:25Z
;; Not after = 2023-12-31T12:29:25Z
don't forget to handle key rotation correctly! See
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4
for details.
--
Viktor.
