Date: 8 Jan 2020 15:13:07 -0500
Message-ID: <alpine.BSF.2.21.99999.352.2001081505180.78172@gal.iecc.com>
From: "John R Levine" <johnl@taugh.com>
To: "Michael StJohns" <msj@nthpermutation.com>
Cc: dnsop@ietf.org
In-Reply-To: <923cb7d7-be70-37e9-ca8b-248e95db9aa1@nthpermutation.com>
References: <20200107023630.628251208AAF@ary.qy>
 <ce52989c-f6cc-f4e5-0c49-d528d366e350@nthpermutation.com>
 <alpine.OSX.2.21.99999.374.2001081359350.85317@ary.qy>
 <923cb7d7-be70-37e9-ca8b-248e95db9aa1@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: multipart/mixed;
 BOUNDARY="3168237118-1677514723-1578514109=:78172"
Content-ID: <alpine.BSF.2.21.99999.352.2001081508330.78172@gal.iecc.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2YZ9S0gcVCey_80oQ1ljabAiVzY>
Subject: Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
Precedence: list

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3168237118-1677514723-1578514109=:78172
Content-Type: text/plain; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.BSF.2.21.99999.352.2001081508331.78172@gal.iecc.com>

On Wed, 8 Jan 2020, Michael StJohns wrote:
> I'm running a private copy of the root zone for my organization. I=20
> (automated) check the SOA every so often, and arrange for a download of t=
he=20
> zone when it changes.=A0=A0=A0 I (automated) get a copy of the zone data,=
 including=20
> an ZONEMD RR, everything validates DNSSEC wise, but the ZONEMD RR is inva=
lid=20
> (hashes don't match). I do:
> [ various things ]

I know this isn't the answer you want, but it still depends.  One size=20
fits all error recovery is rarely possible.  I also realize you're trying=
=20
to tease out a single answer to the question of whether a ZONEMD failure=20
is more likely to be a bogus zone or a broken signer, and it still=20
depends.

In the rather peculiar case of the root zone, ZONEMD for the first time=20
covers the otherwise completely unauthenticated A/AAAA records for the=20
root servers since root-servers.net remains unsigned, so it can detect=20
tampering that we couldn't detect before.  Since we happen to know that=20
significant changes to the root are fairly rare, I'd keep using the old=20
version of the root and flag the failure for someone to look at.

In other applications, the risks and consequences are different, so I'd=20
probably do something different.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
--3168237118-1677514723-1578514109=:78172--