Re: DNSSEC vs netbsd-8/sparc?

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

On Fri, 17 Apr 2020, Havard Eidnes wrote:

> Date: Fri, 17 Apr 2020 10:54:08 +0200 (CEST)
> To: jdbaker%consolidated.net@localhost
> 
> > When I tried turning on DNSSEC on the primary name server, it could no-
> > longer resolve outside my own local network.  I think BIND in netbsd-7
> > is considered too old to properly support current DNSSEC, so I commented
> > those options out and it was again able to resolve external domains.
> 
> I think (hope!) that's inaccurate; BIND has in general had working
> DNSSEC validation for a very long time.
> 
> However, NetBSD 7.0 had a /etc/namedb/bind.keys which only contained
> the root DNSSEC key which is now expired (was valid until 11 jan 2019
> according to https://data.iana.org/root-anchors/root-anchors.xml), so
> if you start BIND with only the old root key in that file, any
> attempts at doing DNSSEC validation will predictably fail.
> 
> An updated /etc/namedb/bind.keys from netbsd-7 contains also the new
> root key, it was updated on the netbsd-7 branch on 2018-03-10 by the
> looks of it.  If this update isn't applied to your configuration,
> you'll get the failure described above.

The BIND on all my systems are as up-to-date as they can be.  As I wrote
in a previous message, the "bind.keys" file on both the primary
(netbsd-{7,8,9,current}/sparc) and secondary (netbsd-{8,9}/amd64) are
identical aside from the RCS Ids.

They contain both the old key (19036) which the comment says will be
phased out beginning in 2017 and the new key (20326) which the comment
says would be published in the root zone in 2017.

I've also replaced the "bind.keys" file with:

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

(which is identical to the original "bind.keys" aside from TABs vs SPACEs
formatting and the RCS Id).

> There may of course be other problems causing this failure, but this
> particular issue is easiest to sort out first.

Verifying the keys shows a discrepancy between netbsd-{7,8}/sparc
and netbsd-9/{sparc/i386/amd64}.  The sequence:

  $ dig +multi -t DNSKEY . > /tmp/tmp-root-keys
  $ dnssec-dsfromkey -f /tmp/tmp-root-keys .

on netbsd-{7,8}/sparc produces:

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

While on netbsd-9/{sparc/i386/amd64} it produces:

. IN DS 20326 8 1 AE1EA5B974D4C858B740BD03E3CED7EBFCBD1724
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

(the same as an example shown by Jeremy Reed earlier in this thread).

It appears there is a problem with how netbsd-{7,8}/sparc is computing
one of the DS hashes, which doesn't match and breaks the trust chain.

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