[dns-operations] org/DNSKEY RR not found

[Casey Deccio]

On Mon, Aug 10, 2015 at 10:47 AM, Edward Lewis <edward.lewis at icann.org>
wrote:

> On 8/10/15, 8:40, "dns-operations on behalf of Casey Deccio"
> <dns-operations-bounces at dns-oarc.net on behalf of casey at deccio.net> wrote:
>
> >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.
>
> Casey's explanation makes me think about the clumsiness.  Looking at a
> snapshot, no one knows why a key is present - whether it is in pre publish
> mode, used for some obscure data set in the zone, or waiting to be
> retired.  Worse, we don't know if it is just from that one server or all
> servers.  (One cannot, using queries alone, know if all the servers are
> simultaneously holding one set, it's simply infeasible, if only because
> the speed of light is not infinite.)  So, I don't think DNSviz can do "any
> better" in flagging the state seen.  (Perhaps not red, maybe pink, for
> potential problems? ;) )
>

Actually, it can do "some" better.  It doesn't have to be "always error" or
"always warning".  DNSViz can use the responses it has received to infer
the role of each DNSKEY and then use that to determine the severity of
DNSKEY RRset mismatch.  In the case where there is a DS or (non-DNSKEY)
RRSIG that corresponds to a DNSKEY, then it is marked as an error.
Otherwise, it is marked as a warning.  Here is the result:

http://dnsviz.net/d/org/VcfF4Q/dnssec/

Thanks for the suggestion.

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150810/a60baa5d/attachment.html>