Intent and implementation of dig's +crypto option

[Bob Harold]

On Fri, Sep 22, 2023 at 8:46 AM Anand Buddhdev <anandb at ripe.net> wrote:

> Hi folks,
>
> I wanted to open a GitLab issue about this, but then thought it might be
> nice to have a discussion to hear the views of users.
>
> dig 9.18.19's man page says:
>
>    +crypto, +nocrypto
>      This option toggles the display of cryptographic fields in DNSSEC
>      records. The contents of these fields are unnecessary for debugging
>      most DNSSEC validation failures and removing them makes it easier to
>      see the common failures. The default is to display the fields. When
>      omitted, they are replaced by the string [omitted] or, in the DNSKEY
>      case, the key ID is displayed as the replacement,
>      e.g. [ key id = value ].
>
> When I query using dig, and use the combination "+nocrypto +dnssec" then
> dig suppresses the crypto material for DNSKEY, DS and RRSIG records.
> This is in agreement with the man page.
>
> But when I query for the newly introduced ZONEMD record, dig also hides
> the hash. In my opinion, ZONEMD is not a DNSSEC-related record, and so
> its hash should not be hidden (according to the man page).
>
> On the other hand, the hash displayed for ZONEMD, like with hashes of DS
> records, is not especially useful for eyeballing. For me, it is enough
> to see that there's a ZONEMD record, but I don't need to see all the hex
> (which is only needed by code that actually wants to verify it). So I'm
> actually fine with the ZONEMD hash being suppressed, but the man page
> needs to be updated.
>
> In a similar way, the hashes displayed in TLSA and similar records could
> also be suppressed, but dig currently doesn't.
>
> Do you think that dig should be adjusted to suppress cryptographic
> material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and
> the man page updated to reflect this?
>
> Regards,
> Anand Buddhdev
> --
>
> Just my opinion, but I would like it to apply to all crypto fields.

And that's a useful option, I had not been using it, but I will now, thanks.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230922/a305d85f/attachment-0001.htm>