> On May 20, 2019, at 4:34 AM, Joe Abley <jab...@hopcount.ca> 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=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.
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
