On Fri, Nov 07, 2014 at 03:29:15PM -0800, Stephane Bortzmeyer wrote:

> The second one is the lack of monitoring solutions. DANE brings some
> new risks of discrepancies (people renewing the certificate and
> forgetting to update the TLSA record for the *-EE usages...) since the
> people who manage the certs may not be the same who manage the DNS. We
> really need Nagios plugins to monitor DANE sites. Unlike the first
> reason given above, I strongly buy this one.

Funny you should mention that.  That's something I'm working on,
and at least for SMTP with DANE.

Some of the early adopter domains I've been curating are getting
DNSSEC wrong.  The forget to re-sign, or secondaries fall out of
sync, or nameservers are buggy, ...  I've also seen some validation
failures with BIND 9.10.1 as the validating resolver that I don't
see with unbound.

The monitoring is at the DANE layer, getting detailed diagnostics
from DNSSEC validation errors would also be useful, but I don't
have the tools handy for that, "drill -S" is almost the right tool,
but I'm open for recommendations of validators that describe problems
more simply and concisely than:

    $ drill -S -D -t tlsa _25._tcp.fuhrt.de.
    ;; Number of trusted keys: 1
    ;; Chasing: _25._tcp.fuhrt.de. TLSA

    DNSSEC Trust tree:
    _25._tcp.fuhrt.de. (TLSA)
    |---Error in denial of existence: RR not covered by the given NSEC RRs
    |---cgokmsudli89pi41egv37cvqrq5bfug3.fuhrt.de. (NSEC3)
    |   |---fuhrt.de. (DNSKEY keytag: 22118 alg: 7 flags: 256)
    |       |---fuhrt.de. (DNSKEY keytag: 10069 alg: 7 flags: 257)
    |       |---fuhrt.de. (DS keytag: 10069 digest type: 2)
    |           |---de. (DNSKEY keytag: 56395 alg: 8 flags: 256)
    |               |---de. (DNSKEY keytag: 24220 alg: 8 flags: 257)
    |               |---de. (DS keytag: 24220 digest type: 2)
    |                   |---. (DNSKEY keytag: 22603 alg: 8 flags: 256)
    |                       |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
    |---Error in denial of existence: RR not covered by the given NSEC RRs
    |---2q3imqr0q2dntoohifcm0a6or78lropv.fuhrt.de. (NSEC3)
        |---fuhrt.de. (DNSKEY keytag: 22118 alg: 7 flags: 256)
            |---fuhrt.de. (DNSKEY keytag: 10069 alg: 7 flags: 257)
            |---fuhrt.de. (DS keytag: 10069 digest type: 2)
                |---de. (DNSKEY keytag: 56395 alg: 8 flags: 256)
                    |---de. (DNSKEY keytag: 24220 alg: 8 flags: 257)
                    |---de. (DS keytag: 24220 digest type: 2)
                        |---. (DNSKEY keytag: 22603 alg: 8 flags: 256)
                            |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
    No trusted keys found in tree: first error was: RR not covered by the given 
NSEC RRs
    ;; Chase failed.

So we've not yet shaken out all the DNSSEC implementation and
operational errors.

On the DANE front, some users are confused about the difference
between the Cert(0) vs SPKI(1) selector, and occasionally forget
to update TLSA RRs when keys are rotated.

The raw scan for ietf.org reads:

    ietf.org. IN MX 0 mail.ietf.org.
    mail.ietf.org. IN A 4.31.198.44
    _25._tcp.mail.ietf.org. IN TLSA 3 1 1 
0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6
    ;; SSL: protocol = TLSv1.2, cipher = ECDHE-RSA-AES256-GCM-SHA384 (256 bits)
    ;; Passed(depth 0): mail.ietf.org. IN TLSA 3 1 1 
0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6

-- 
        Viktor.

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to