<div dir="ltr">On Sun, Aug 9, 2015 at 7:06 PM, Jim Popovitch <span dir="ltr"><<a href="mailto:jimpop@gmail.com" target="_blank">jimpop@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been learning/playing around with DNSSEC and I've run across this<br>
error using <a href="http://dnsviz.net" rel="noreferrer" target="_blank">dnsviz.net</a>.  I'm assuming that there's nothing I can do<br>
about it, but also wondering if this is really a major or minor thing<br>
(dnsviz codes it "red").<br></blockquote><div><br></div><div>The potential problem, as Mark suggests, is a mismatch between RRSIG and DNSKEY.  For example, suppose some subset of your servers are serving the set of DNSKEYs consisting of A, B, and C, and some subset is serving the set of DNSKEYs consisting of A, B, and D.  Your resolver will only get a DNSKEY RRset from one of them (until its TTL expires), so it will only have either A, B, and C or A, B, and D.  Let's suppose it now has A, B, and C in cache.  Now it queries any server again and receives an A RRset with (only) RRSIG matching DNSKEY D.  It has no way to verify this RRSIG.  This is problematic.<br><br></div><div>However, if the "missing" key(s) do not have any RRSIGs in the wild (e.g., because they are being introduced into the DNSKEY RRset as part of pre-publishing or being retired due to post-publishing), then it is not an issue.  It is not always easy to tell from a snapshot in time, even from the RRSIGs that are returned in response to the diagnostic queries that are sent, how much of a problem it is, so DNSViz flags it as a potential problem.  However, despite the "red" error, note that the color of the nodes--which represents their authentication status--is still blue, indicating that the chain of trust is in tact.<br></div><div><br></div><div>Cheers,<br></div><div>Casey<br></div></div></div></div>