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=40verisign....@dmarc.ietf.org> 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. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
