Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

[Michael StJohns <[e-mail]>]

On 1/15/2020 8:39 PM, Paul Hoffman wrote:
> On Jan 15, 2020, at 5:28 PM, Michael StJohns <[e-mail]> wrote:
>> I think its a co-existence issue here.  I don't think you should have two different (calculation-wise) ZONEMD-like RRSets in the same zone for the reasons you've mentioned.
> That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD.

That doesn't really deal with the problem.  ZONEMD (this document) 
really needs to have similar language, otherwise changing from ZONEMD to 
whatever could cause issues for the receiver. What you want is for both  
(many) to be able to coexist and ignore each other  - IMHO.


>
>> I don't think that reserving RR types is the right way of doing things and I'm not sure how you'd write the IANA guidance to cover the later assignment of those type numbers.
> Fully agree.
>
>>   It's possible that we can tweak this a bit and get around the problem.
>>
>> So maybe:
>>
>> 1 byte - Scheme - 1 == SIMPLE
>>
>> Which has a body of
>>
>> 1 byte - digest - 1 == SHA384, a
>>
>> followed by N bytes of the appropriate digest length.
> Using a different RRtype would be significantly easier and safer due to applications having clearly separate code paths.

The two different code paths are (pseudocode):

switch (rr.rrtype) {

   case ZONEMD:
           switch (((zonerr)rr).scheme) {
               case SIMPLE:
                    processSimpleZoneMD (rr);
                    break;
               case INCREMENTAL:
                    processIncrementalZoneMD(rr);
                    break;
               default:
                     error();

            }

}


vs

switch (rr.rrtype) {
     case ZONEMD:
         processSimpleZoneMD(rr);
         break;
     case INCZONEMD:
         processIncrementalZoneMD(rr);
         break;

}


Not really sure where you think why one might be safer than another.

Later, Mike



>
> --Paul Hoffman