[dnsdir] draft-ietf-deleg-06 early Dnsdir review

Vladimír Čunát via Datatracker <noreply@ietf.org> Mon, 12 January 2026 13:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsdir@ietf.org
Delivered-To: dnsdir@mail2.ietf.org
Received: from [10.244.6.11] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id C1DFBA6649B0; Mon, 12 Jan 2026 05:06:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vladimír Čunát via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.55.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176822318067.656169.786669720822567977@dt-datatracker-5656579b89-r5kdq>
Date: Mon, 12 Jan 2026 05:06:20 -0800
Message-ID-Hash: GZ3IMWKDG6523DNLLPUUBIJ5IGKGWXNI
X-Message-ID-Hash: GZ3IMWKDG6523DNLLPUUBIJ5IGKGWXNI
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dd@ietf.org, draft-ietf-deleg.all@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Vladimír Čunát <vladimir.cunat@nic.cz>
Subject: [dnsdir] draft-ietf-deleg-06 early Dnsdir review
List-Id: DNS Directorate <dnsdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsdir/ehcpsmqKOvUIjdPfpBeuJVf1nII>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsdir>
List-Help: <mailto:dnsdir-request@ietf.org?subject=help>
List-Owner: <mailto:dnsdir-owner@ietf.org>
List-Post: <mailto:dnsdir@ietf.org>
List-Subscribe: <mailto:dnsdir-join@ietf.org>
List-Unsubscribe: <mailto:dnsdir-leave@ietf.org>

Document: draft-ietf-deleg
Title: Extensible Delegation for DNS
Reviewer: Vladimír Čunát
Review result: Almost Ready

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