Hi Peter!
> On Mar 11, 2021, at 11:54 AM, Peter van Dijk <[email protected]>
> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
