Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

[Wes Hardaker <[e-mail]>]

<none of my hats; disclaimer: co-author>

Recognizing that this thread has mostly wound down without agreement,
I'll at least add a data point.  I agree that different applications may
behave differently depending on their specific situation and needs.  I
do agree with Mike that automation is needed in the software, but what
to do is not up to the standard but rather the implementation.

I hope to make use of ZONEMD within localroot, which falls into the
scenario you outline:

Michael StJohns <[e-mail]> writes:

> Then let me try a "real world" example and give you a few different choices:
> 
> I'm running a private copy of the root zone for my organization. I
> (automated) check the SOA every so often, and arrange for a download
> of the zone when it changes.    I (automated) get a copy of the zone
> data, including an ZONEMD RR, everything validates DNSSEC wise, but
> the ZONEMD RR is invalid (hashes don't match). I do:
> 
> a) Discard the download, keep retrying until I get a valid ZONEMD RR,
> ignoring any changes in the DNSSEC validated data
> 
> b) Install what I've been able to validate DNSSEC wise, and delete
> anything not DNSSEC validated.  E.g. basically ignore the ZONEMD RR
> and install any validated changes.  Log the error. Schedule a download
> for next SOA change.
> 
> c) Yell for a human to make a decision.
> 
> d) (b) plus turn off ZONEMD RR processing in the future
> 
> e) anecdotal author's choice.

This situation would certainly be annoying, and it would tell me that
there is likely either a problem with the ZONEMD record (as you state)
or the glue records because of some tom-foolery (of any nature).

So, if my localroot/7706 resolver checks the data and finds all the
DNSSEC correct but not the ZONEMD, then I'll probably discard the
result, try again, and if that fails: yell/log, and wait for the next
SOA because that should be safe for the root zone.

I could imagine, however, a different implementation of 7706 doing an
entirely different thing: using the new root zone and it's data when
trying to contact sub-zones, but falling back to the old zone when none
of the "new" glue were working (aka, DoSed by changes).  I could also
see someone else make the opposite change.  I could see some
implementations deciding to stop service (it sure makes users notice
faster).

These are all engineering and deployment decisions, not protocol decisions.
BCPs come later.

-- 
Wes Hardaker
USC/ISI