RRSIG name was not being checked

[rixtox]

The RRSIG's header name specifies the signer of this signature record. For the leaf query, it should be equal to the FQDN of the querying domain name. e.g. If I query for A records for example.com, I should get back an RRSIG with header name example.com.. Then I follow the auth chain of that name to verify the chain of trust.

However, this library didn't check the equality between the return RRSIG header name, and is using it directly for checking the chain of trust. This means, an attacker can forge RRSIG for any domain by owning a valid domain name. e.g. when a victim query for A records for example.com, an attacker who owns pwn.com can generate a signature for a fake RR response set using its valid DNSKEY, and attach the RRSIG with header name of pwn.com and send it back to the victim. Because this library takes the RRSIG header name without any checks, it query for DNSKEY for pwn.com and use that key to verify the RR set that should answer the query for example.com, and the check would pass.

[rixtox]

The RRSIG header name check is done in other DNSSEC libraries. e.g. sdns: https://github.com/semihalev/sdns/blob/3caf4c38f38c9317d241ffc386621f7f47ff6227/middleware/resolver/resolver.go#L1187

[rixtox]

In addition, this library doesn't give the option to specify root DNSSEC public keys as root of trust. This means it accepts any self-signed root key and an attacker can forge a root key and the chain of keys to pass any validation of any querys.

[neild]

The Go Vulnerability database has designated the lack of RRSIG header name validation GO-2022-0979 and CVE-2022-3346, and the lack of root certificate validation GO-2022-1026 and CVE-2022-3347. To add a fixed version or otherwise update these reports, you can reopen and comment on golang/vulndb#979 or golang/vulndb#1026.