Hello. I think the draft should also mention glue *addresses*, as that's another closely related piece that often comes from the parent side (and is also unavoidable to use in some situations). Even if that means not really recommending anything about them, though I'd personally expect these to be handled similarly to NS records.
I'm not really sure if the whole draft is a good thing, but maybe that's due to not experiencing the difficulties to update records in a way that wouldn't need or even benefit from this draft (me being resolver developer and indirectly operator). Maybe it would generally be helpful to expand the motivation section around the topic of why this is so difficult that it's worth a standards-track RFC. I'm also a bit puzzled... if the RFC won't make any *hard* requirements, zone operators still won't be able to rely on the specified behavior (n/ever perhaps), so can this still help them noticeably? (I may have missed this discussion, so point me there.) --Vladimir | Knot Resolver dev. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
