[dns-operations] DNSViz 0.6.7 (FreeBSD 11.1-RELEASE-p10) reports all but first NSEC3 RRSIG as "BOGUS"

[Viktor Dukhovni]

I am trying to use the DNSViz CLI on my own machine, rather than
farm out all processing to the website.  But I am running into
unexpected wrinkles.  TLSA lookups that elicit multiple NSEC3
records as proof of non-existence seem to consistently report
"BOGUS" RRSIGs for all but the first NSEC3 record.  For example,
after running:

  $ dnsviz probe -a . -A _25._tcp.mail0.transip.nl > /tmp/probe.json

and processing the output via:

  $ dnsviz grok -c -r /tmp/probe.json \
	-t /usr/local/etc/unbound/root.key \
        < /tmp/grok.json > /tmp/grok.json

Extracting the key details for each of the 3 NSEC3 records with "jq"

    $ jq -r '
        ."_25._tcp.mail0.transip.nl.".queries
        ."_25._tcp.mail0.transip.nl./IN/TLSA"
        .nxdomain[0].proof[0].nsec3[] |
        { name: .name,
          rdata: .rdata,
          rrsig: .rrsig[0] | {sig: .signature, status: .status},
          status: .status
        }' < /tmp/grok.json

I get output which shows "SECURE" for the first NSEC3 record, and "BOGUS"
for the next two, even though the actual signatures (as reported by the
DNSViz website and other tools) are fine:

    {
      "name": "9MFR2OMBDF81GDKCUF061OMEJQKILG4R.transip.nl.",
      "rdata": [
        "1 0 100 d49622cfe9b651eb 9MO6DHSRG3KU7A56D5FNASQE5AMA8S4D A MX AAAA RRSIG"
      ],
      "rrsig": {
        "sig": "FHbn898jmUu0NogE8y3WhjpJDWtZWuD84TTi7zaWQWqte5qmfCX12M/mKXKmOP5Z3tmS/0uAz+9GHM2iwsK5HllN//WtNZWGOYQBL0Ah46kAhH9FGbAVz7ZUt7lG2rE3FXrCKWvCulIiFm4P5KmIv3wwDI4tDB233ET+VUFW6+o=",
        "status": "VALID"
      },
      "status": "SECURE"
    }
    {
      "name": "V76GL0PAGI9QD1JD6EAHT3PCHPPVCRKO.transip.nl.",
      "rdata": [
        "1 0 100 d49622cfe9b651eb V7LS6RI0659KANKL96OE5JOK5DB3QLT1 A RRSIG"
      ],
      "rrsig": {
        "sig": "LraWdQZpDada4DTiduutHGExok6A6d6L01W5k5Gd0oDdZzNBQbkth1lu9i5cCzx+RmesXSI9RQ11D+QO/Rbhf0QkedlWdHnWZDXsxQEFU3vKJcF1aR48VRfO/6rMuFecSo3tbIJU6ebW3MrUP1ef7v2jkHaOX064tiyLwsEtBW0=",
        "status": "VALID"
      },
      "status": "BOGUS"
    }
    {
      "name": "23J0JOEEPMKN4SR9SSDPL0SEBEA8R110.transip.nl.",
      "rdata": [
        "1 0 100 d49622cfe9b651eb 271FTOUB3CVOKVRJ5FFOLDUM9VRU3T4M CNAME RRSIG"
      ],
      "rrsig": {
        "sig": "ohWd/eXxZl7zb8GXJjycnfSKNrm7bXfFs8WgRBQsniS62F+/nIJF1XQvarjk42idsKmExSz4xSrrbHWQibxDJf/Vksy8hv8JG1NcECYuKFhllP+A4BOynPWAwwC/IwQRgmK1LWPJ0baj0Gjs5ogCk9pfguOn7xyp9aQ8Aj8hEfI=",
        "status": "VALID"
      },
      "status": "BOGUS"
    }

Has anyone else seen similar (mis)behaviour?  Is this a known issue?

[ Full "grok.json.gz" file attached in case that's useful" ]

-- 
	Viktor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: grok.json.gz
Type: application/x-gzip
Size: 6752 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180805/0699d5df/attachment.bin>
-------------- next part --------------