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

["John Levine" <[e-mail]>]

In article <[e-mail]> you write:
>1) A recommendation for the maximum size of the zone (and for that 
>matter the maximum churn rate). This is hinted at in the abstract, but 
>missing from the body of the document.

I don't get it.  The draft makes it clear that ZONEMD in this
implementation is intended for statically signed zones.  If Verisign
wants to put a ZONEMD in the daily download of the three hundred
million record .com zone file, I think that would be dandy.  If your
zone of whatever size is updated too often to deal with recomputing
ZONEMD, then don't.

Also, advice about what's too big or too slow doesn't age well.  I
expect most of use remember a time when the idea of a million record
zone file seemed absurd.


>2) For each of the use cases, an explanation of how this RRSet actually 
>mitigates or solves the identified problem.

I don't get this either.  ZONEMD lets you verify that you got the
entire zone correctly.  If anything, I'd take most of this section out
since the list of places where people get zone files isn't likely to
age well either.

>>     This specification utilizes ZONEMD RRs located at the zone apex.
>>     Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
>>     specification.
>Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".

Does ignore mean they aren't included in the computation of an apex ZONEMD?  Ugh.

ZONEMD RRs MUST NOT appear anywhere other than the apex of a zone.

>>     A zone MAY contain multiple ZONEMD RRs to support algorithm agility
>>     [RFC7696] and rollovers.  Each ZONEMD RR MUST specify a unique Digest
>>     Type and Parameter tuple.
>"A client that receives multiple ZONEMD RRs with the same DT and 
>Parameter MUST try to verify each in turn and MUST accept the zone if 
>any verify".

I think that's an error.  If they have the same DT and parameter, either they
have the same serial and they're duplicates, or one of them is obsolete.

>>   It is RECOMMENDED that a zone include only
>>     one ZONEMD RR, unless the zone publisher is in the process of
>>     transitioning to a new Digest Type.
>
>Lower case "recommended" here please.

I'd take it out altogether.  What problem does multiple signatures cause?

Agree with most of the other editorial advice.

>13) Missing a section 4.2 which says what you do when a zone doesn't 
>verify.  Otherwise, what's the point?

That seems extremely dependent on the context.  What I would do on a
secondary name server AXFR'ing a zone for which it's authoritative vs.
one of the thousand daily CZDS zip file downloads is rather different.

With respect to updated zones, perhaps it should say that if zone
updates are distributed with IXFR, each update should either have an
updated ZONEMD with the new checksum for the full zone or delete the
now obsolete old ZONEMD.  That seems obvious, but you never know.

R's,
John