<div dir="ltr">Hi Franck,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 2:39 AM, Franck Martin <span dir="ltr"><<a href="mailto:fmartin@linkedin.com" target="_blank">fmartin@linkedin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I found this tool quite good to report the most common DNSSEC issues. It looks at SOA, A, AAAA, and MX records of a zone and is visually nearly intuitive.<br>
<br>
<a href="http://dnsviz.net/d/dns-oarc.net/dnssec/" target="_blank">http://dnsviz.net/d/dns-oarc.net/dnssec/</a><br>
<br></blockquote><div><br></div><div>Thanks!  If you have suggestions to make it more intuitive, please feel free to pass them along.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The type of errors I see are like:<br>
<a href="http://dnsviz.net/d/eucom.mil/dnssec/" target="_blank">http://dnsviz.net/d/eucom.mil/dnssec/</a><br>
<br>
Where an important record is not signed<br></blockquote><div><br></div><div>The legend on the site is a little out of date, leaving some uncertainty about some of the conventions used.  I'll clarify that in this particular case the issue isn't the lack of signatures, but a signature that doesn't validate the resource record set cryptographically (One possible cause for this is that the SOA record was updated manually after the record was signed).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or like:<br>
<a href="http://dnsviz.net/d/au/dnssec/" target="_blank">http://dnsviz.net/d/au/dnssec/</a><br>
<br></blockquote><div><br></div><div>While the lack of DS records is intentional, as you noted, the insecure delegation from the root to au also isn't an error--as long as the NSEC/NSEC3 records properly prove the non-existence of DS.  That proof is represented by the arrow from the NSEC3 node in the root to the .au box, and its teal color indicates that the proof is valid.  This is the case with any unsigned zone whose parent is signed.<br><br>Cheers,<br>Casey<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Where the delegation is not set (DS). For dot au, it is on purpose so testing can occur before going live by the end of this month: <a href="http://www.auda.org.au/industry-information/au-domains/dnssec/" target="_blank">http://www.auda.org.au/industry-information/au-domains/dnssec/</a><br></blockquote></div></div></div></div>