[dns-operations] org/DNSKEY RR not found

Jim Popovitch jimpop at gmail.com
Mon Aug 10 13:33:23 UTC 2015

On Mon, Aug 10, 2015 at 8:40 AM, Casey Deccio <casey at deccio.net> wrote:
> On Sun, Aug 9, 2015 at 7:06 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>> I've been learning/playing around with DNSSEC and I've run across this
>> error using dnsviz.net.  I'm assuming that there's nothing I can do
>> about it, but also wondering if this is really a major or minor thing
>> (dnsviz codes it "red").
> 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.
> 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.

Thank you for the explanation Casey, and (presumably) Thank you for
the excellent DNSSEC tool.

-Jim P.

More information about the dns-operations mailing list