Early Review of draft-ietf-deleg-06
review-ietf-deleg-06-dnsdir-early-cunat-2026-01-12-00

This is review assigned by dnsdir.

I've read through the -06 carefully (without appendix) and I really like it.
For context, I don't provide a completely fresh pair of eyes, as I was present
in that initial hackathon group, and the current draft is actually pretty close
to that weekend's output in the important aspects.

As a more high-level note, before finishing this RFC I would feel safer if we
could review at least some initial stab at e.g. how delegating DNSSEC keys
might work, so that we could be more confident that the design of *this* RFC
won't unnecessarily complicate that future draft (or possibly some other
desirable future properties which we might anticipate already).

> DELEGI cannot coexist at the same owner name with DELEG or NS RR types.

Is this intended to apply to the child side?  I don't expect it would be
typical to have a DELEGI in a zone apex, but so far I fail to see motivation to
ban a zone apex with both NS and DELEGI on it.  I'd appreciate the draft to
either explain why or amend the formulation somehow to allow that case.

> When using server-name, the addresses for all the names in the set must be
fetched using normal DNS resolution.

This formulation can be read in an overly restrictive way, I think.  I expect
the intention is that server-name really *can* point to names which are inside
some DELEG zones.  Of course, just as with NS, one needs to be careful about
creating too long dependency chains (or even cycles).

--Vladimir | knot-resolver.cz