Re: DNSSEC vs netbsd-8/sparc?

["John D. Baker" <jdbaker%consolidated.net@localhost>]

On Thu, 16 Apr 2020, reed%reedmedia.net@localhost wrote:

> 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)

The "named.conf" defaults supplied with NetBSD (-7 to -current) shows:

  options {
  #...
  dnssec-enable yes;
  dnssec-validation auto;
  #...
  bindkeys-file "bind.keys";
  #...
  };

and I have not changed these, other than uncommenting the dnssec-*
options in NetBSD-7 (or re-commenting them to make the sparc primary
nameserver resolve external domains).  Other than my local zone
configuration, the primary (master) name server and the backup (slave)
name server have identical "named.conf" files.

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

My "bind.keys" file is identical on both master and slave, between
netbsd-7, -8, and -9 other than the RCS Id.

The backup/slave works, the primary/master does not.

> 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/

This is identical to my "bind.keys" file(s) other than formatting
(TABs vs SPACEs) and the addition of the RCS Id.

> 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

My primary name server produces different output in the first line,
and identical output in the second line.  The first line is also different
from that shown at "https://data.iana.org/root-anchors/root-anchors.xml";
but the second line is identical.

I replaced my "bind.keys" file with that from

  "http://ftp.isc.org/isc/bind9/keys/9.11/bind.keys.v9_11";

and it produced identical results as with the default "bind.keys" supplied
with NetBSD's in-tree BIND.

. IN DS 20326 8 1 42CAD163F25D96B28A8413628A2EBEBC8341B1CD
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

My backup name server produces identical output to your example above:

. 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.)

Perhaps that is what is going on, given the above.  The primary is
netbsd-8/sparc, the backup is netbsd-9/amd64.

A netbsd-9/sparc host produces identical output to your example.  When
next I am able, I will boot the primary name server with netbsd-9 and
run the test again.

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645