[dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus

[Casey Deccio]

Hi Peter!

> On Mar 11, 2021, at 11:54 AM, Peter van Dijk <peter.van.dijk at powerdns.com> wrote:
> 
>> 
>> That's a fair point.  *Normally* the error would be something more like: "No RRSIGs were found covering the RRset".  But in this case, there *was* an RRSIG, so it didn't get *that* error.  DNSViz used to complain when an RRSIG didn't align to a DNSKEY, but that was changed because sometimes there were legitimate reasons for that (like pre-publishing RRSIGs as part of an algorithm rollover).  So all we were left with was an error about the RRSIG itself (i.e., name didn't match).
> 
> Thank you for explaining that history. I certainly appreciate how your
> errors have to guess at the real world things that are happening.

Yes, guessing is hard :). And actually the command-line version does a little better in this particular case than the Web/database version because there are some challenges with keeping track of a DNSKEY/DS for a non-zone (see below) in the way that the software is currently implemented.

>>  Probably the "no RRSIG" error should be modified to be "no RRSIG for an existing DNSKEY".
> 
> But, in this case, the DNSKEY does exist, and a DS is pointing at it
> correctly, and the problems are almost unrelated to those, as far as I
> can see. My impression is that DNSViz is confused for the same reason a
> default PowerDNS Recursor gets confused on this name - conflicting
> facts from queries *other than* those DS and DNSKEY queries.

Oh, I see now.  The actual delegation is missing completely, as far as I can tell.

$ dig +short @ns1.dla.mil gtm-ext.dla.mil a
$ dig +short @ns1.dla.mil gtm-ext.dla.mil aaaa
$ dig +short @ns1.dla.mil gtm-ext.dla.mil ns

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