[dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus
casey at deccio.net
Thu Mar 11 23:36:44 UTC 2021
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations