[DNSOP] Re: [dd] Re: [Ext] Re: Root DS/DELEG query
Philip Homburg <pch-dd@u-1.phicoh.com> Wed, 23 July 2025 10:52 UTC
Return-Path: <pch-b6CAFA0C7@u-1.phicoh.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4A6FA49402E0; Wed, 23 Jul 2025 03:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS6wVCaEjkAE; Wed, 23 Jul 2025 03:52:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 447F6493E5CD; Wed, 23 Jul 2025 03:46:16 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1ueWys-0000NiC; Wed, 23 Jul 2025 12:45:50 +0200
Message-Id: <m1ueWys-0000NiC@stereo.hq.phicoh.net>
To: dd@ietf.org
From: Philip Homburg <pch-dd@u-1.phicoh.com>
Sender: pch-b6CAFA0C7@u-1.phicoh.com
References: <caa2df39-2483-464f-9802-24d66555866f@isc.org> <1A6AE7F2-5B86-4495-B604-B33FBD6A4037@isc.org> <841DB038-EA32-45A7-9731-BE46192A203E@icann.org>
In-reply-to: Your message of "Wed, 23 Jul 2025 07:37:25 +0000 ." <841DB038-EA32-45A7-9731-BE46192A203E@icann.org>
Date: Wed, 23 Jul 2025 12:45:50 +0200
Message-ID-Hash: ZID6TM2RWSBPUXKZ7QDVBBJSXIHBN75K
X-Message-ID-Hash: ZID6TM2RWSBPUXKZ7QDVBBJSXIHBN75K
X-MailFrom: pch-b6CAFA0C7@u-1.phicoh.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [dd] Re: [Ext] Re: Root DS/DELEG query
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eS0aGHOyf6q1SWbN2KgoeBezhp4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
> > ./DS is NOERROR NODATA. This is RFC described behaviour > > Which part of which RFC? I, too, am not finding this, but you seem > sure it is in the RFCs. In my experience, if a DS query arrives at an authoritative and the name is in a zone served but not part of a delegation or below a delegation then DS will be treated like any other type. I'm not aware of any part of an RFC that requires the server to do anything different in this case. The funny thing is that because DS is a parent-side type, at a delegation it is also a completely normal in-zone lookup that can result in either an answer or a NODATA response.
- [DNSOP] Root DS/DELEG query Petr Špaček
- [DNSOP] Re: [dd] Root DS/DELEG query Mark Andrews
- [DNSOP] Re: [dd] Root DS/DELEG query Wessels, Duane
- [DNSOP] Re: [dd] Root DS/DELEG query Philip Homburg
- [DNSOP] Re: [dd] Root DS/DELEG query Petr Špaček
- [DNSOP] Re: [dd] Root DS/DELEG query Mark Andrews
- [DNSOP] Re: [Ext] [dd] Re: Root DS/DELEG query Paul Hoffman
- [DNSOP] Re: [dd] Re: [Ext] Re: Root DS/DELEG query Philip Homburg
- [DNSOP] Re: [dd] Re: [Ext] Re: Root DS/DELEG query Petr Špaček
- [DNSOP] Re: [dd] [Ext] Re: Root DS/DELEG query Mark Andrews