Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

["Wessels, Duane" <[e-mail]>]

> On May 20, 2019, at 4:34 AM, Joe Abley <[e-mail]> wrote:
> 
> Hi Duane,
> 
> (Olli's message just bumped this thread up in my inbox, so it's an enormously late reply but not for me, if you see what I mean)
> 
> On 25 Mar 2019, at 17:15, Wessels, Duane <dwessels=[e-mail]> wrote:
> 
>> I'm not aware of anything that could be enabled by non-apex ZONEMD records. My preference would be to forbid non-apex ZONEMD records.
>> 
>> I guess my concern was just that it means implementors need to check for this and treat the RR type somewhat specially, as they do for SOA and maybe a couple other RR types.
> 
> I don't actually see any benefit to forbidding anything, and I don't know what "forbid" would mean in this instance.
> 
> I think there's a ready analogy of the former in PTR records. I can put a PTR record in a zone whose apex owner name doesn't end in "in-addr.arpa" or "ip6.arpa". It's not forbidden. It's occasionally useful, since I can put CNAMEs in the reverse tree in zones managed by other people and not have to bother them when I want to update the mapping. CNAMEs are not a good example in the case of ZONEMD, but perhaps there are other future operational tricks that might come to light that are not obvious today. In any case, putting a ZONEMD RRSet somewhere other than an apex doesn't do any harm.
> 
> As to the meaning of "forbid", if there's an implication that such a prohibition should be enforced somewhere (in zone parsers, in nameservers, in stub resolvers, somewhere) then I am against it. :camel_wagging_finger_and_shaking_head_sadly:
> 
> Maybe there's actually an operational use-case here, actually, in the case where you're removing a zone cut. Perhaps you want to preserve a low-TTL ZONEMD RRSet at the place where the zone cut was in the superset zone to accommodate zone distribution graphs that are slow (e.g. across badly-connected networks). This is a bit of a stretch and I haven't thought it through very well, but I think it's a bigger stretch to assert that there is definitively no use for this, especially if leaving the door open is free and bolting it shut is expensive.


Thanks for the feedback, Joe.  

To me SOA is a better example than PTR.  I know some software will complain or refuse to load a zone that has a non-apex SOA, but I also expect there is software out that there accepts/allows it.  DNS seems to have a small number of other apex-only records, but I doubt they are strictly forbidden.

Personally I think a strict, rather than liberal, approach would be better, but I'm not opposed to allowing non-apex records.

Here's what the current (not-yet-published) draft now says:

2.1.  ZONEMD Location

   This specification utilizes ZONEMD RRs located at the zone apex.
   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
   specification.

DW