Re: DNSSEC vs netbsd-8/sparc?

[reed%reedmedia.net@localhost]

On Thu, 16 Apr 2020, John D. Baker wrote:

> Curiously, with "dnssec-validation auto;" commented out (but with
> "dnssec-enable yes;" un-commented) the server resolves external domains,
> but appears to not actually use DNSSEC?
>
> Conversely, with "dnssec-enable yes;" commented out but with
> "dnssec-validation auto;" un-commented, the server fails to resolve
> external domains.

The named is misleading. Even though it logs about using bind.keys file 
or using using built-in keys, it is not. When using defaults of
"dnssec-enable yes;" and "dnssec-validation yes;"  you have to have a 
trusted-keys or managed-keys also configured.

A quick way is

include "/etc/namedb/bind.keys";

(outside of options { }; block)

See /usr/share/doc/reference/ref8/bind9/arm/Bv9ARM.ch06.html

(My book at amazon is the cross-referenced, edited, and expanded version 
of that, but now a few years old.)

The bindkeys-file defines the path to the above file. 
It is used if using dnssec-validation as auto (not yes).

Using dnssec-validation default as yes means "a trust anchor must be 
manually configured using a trusted-keys or managed-keys statement."

Since not trust anchor is manually configured, explains why it probably 
works for you (because no validation).

Now you may have other problems:

1) Your bind.keys file may be too old.

See if it has one of the keys that matches what you can see with:

dig +multi -t DNSKEY .

Now maybe you don't trust that. Also see 
http://ftp.isc.org/isc/bind9/keys/9.11/
and
https://data.iana.org/root-anchors/root-anchors.xml
and https://www.iana.org/reports/2017/root-ksk-2017.pdf
but that is a DS which can be verified:

t1:reed$ dig +multi -t DNSKEY . > tmp-root-keys                      

t1:reed$ dnssec-dsfromkey -f tmp-root-keys  .
. IN DS 20326 8 1 AE1EA5B974D4C858B740BD03E3CED7EBFCBD1724
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

2) Or for some reason, some older named built on older NetBSD is 
generating DS hash wrong so when tries to verify a DNSKEY (against a DS) 
it fails. (See the older thread where two different postings showed the 
DS mismatch.)