IETF Logo Mail Archive

[DNSOP] Re: [dd] Root DS/DELEG query

Mark Andrews <marka@isc.org> Wed, 23 July 2025 04:16 UTC

Return-Path: <marka@isc.org>
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 AF76D48F8E6F; Tue, 22 Jul 2025 21:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="oGm+j6FB"; dkim=pass (1024-bit key) header.d=isc.org header.b="Pt7GBEbn"
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 VPWi933pTEqv; Tue, 22 Jul 2025 21:16:43 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E0D8D48F8E6A; Tue, 22 Jul 2025 21:16:43 -0700 (PDT)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 637FD4D1325; Wed, 23 Jul 2025 04:16:42 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 637FD4D1325
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1753244202; cv=none; b=JZP0tpcPeoJoNv7Yu/Y8Kn1Ny1M12J58h6YSLfEnHvN3tMks/Q9PInoHzL2qbs7+nqv1Qmb1UzvCzi10dYplTl3RNTg9PvVNwus8ZuqfY4JKgPASoyxE+sdCbCykkRRJzgNX567MHybhGWHGZWsEtyq3vyrGDNW1UuAFsnjCf0E=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1753244202; c=relaxed/relaxed; bh=M7S90HQjoWrDhNarIEGeJNQFn3o14kcuHY5A2AUCKFU=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=aVnMSwtrzBqqBb3vll79QIifZb1dlcQ4NcXqEMKtREokkBlsqgfUKGslgyqWIF9s8VqHgXGVrpUYE3836swbwg1Zi6Yl162b/GX/GRHLSmVMZquynm6GC7Wuy39x6KnJ8+yi84hBOt//lV59k0GRgpAniOXqf6Gha4SJbl63Z0A=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 637FD4D1325
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1753244202; bh=/8oMRj42+y8Q4eAMyIGibP+UselXThfzN1Bsfy21AIM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=oGm+j6FBnPJkR61J9MGKWrhbtw732629+C1aPlW64Jkz9zoVS2sJzaaO0duQZ+bPc 9EriOYtShmiRItL+GkUhtMD6JT5nyPJNFWth5GdofIFjw2xyw8hkmBV9VoCNP1Ez7T eUHBC7AMDhm2wUEdkGCXlJyNunzCbrigvceHeqCo=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 5E2912E601C0; Wed, 23 Jul 2025 04:16:42 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 4EE412E601C2; Wed, 23 Jul 2025 04:16:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 4EE412E601C2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1753244202; bh=M7S90HQjoWrDhNarIEGeJNQFn3o14kcuHY5A2AUCKFU=; h=Mime-Version:From:Date:Message-Id:To; b=Pt7GBEbnHSNI1si97xh80qztpJ6L9cP22H6RY5CF8O0AJD7xezjxlbrXc0/C1eBlo QiCdvlLbLi0kInLNj+MAedqGWcLvL/4uGxE7K78Au8PvePRc4LLDXJPvuFJr4+sydp n5lVuVBFyTBW9VrgDCTnKN0WAo+idpUcKyCzWIhA=
Received: from smtpclient.apple (79.red-2-139-223.staticip.rima-tde.net [2.139.223.79]) by zimbra10.isc.org (Postfix) with ESMTPSA id 480552E601C0; Wed, 23 Jul 2025 04:16:41 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.11\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <22e92a4f-85d3-4cbe-a64e-96426c6200f2@isc.org>
Date: Wed, 23 Jul 2025 06:16:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <35C802FC-4F22-4312-BFB2-1E85B3B46D46@isc.org>
References: <caa2df39-2483-464f-9802-24d66555866f@isc.org> <765AAB57-5C95-437D-863D-19C7DA77BCEF@verisign.com> <22e92a4f-85d3-4cbe-a64e-96426c6200f2@isc.org>
To: Petr Špaček <pspacek@isc.org>
X-Mailer: Apple Mail (2.3731.700.6.1.11)
Message-ID-Hash: Y54NMEKVJL25BSV23BFWGC2WZ44QDTMD
X-Message-ID-Hash: Y54NMEKVJL25BSV23BFWGC2WZ44QDTMD
X-MailFrom: marka@isc.org
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: "Wessels, Duane" <dwessels@verisign.com>, "dnsop@ietf.org" <dnsop@ietf.org>, Roy Arends <roy@dnss.ec>, dd <dd@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [dd] Root DS/DELEG query
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a5MEakaRXYRLhO4vBFJTCMibhOs>
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>


> On 22 Jul 2025, at 18:58, Petr Špaček <pspacek@isc.org> wrote:
> 
> On 22. 07. 25 18:26, Wessels, Duane wrote:
>>> On Jul 22, 2025, at 6:11 PM, Petr Špaček <pspacek@isc.org> wrote:
>>> 
>>> Hi all.
>>> 
>>> I wonder how to interpret '. DS'/'. DELEG' queries and welcome opinions!
>>> ...
>>> With strict interpretation of 'DS lives at parent' I would argue '. DS' should result in SERVFAIL: No parent for . can be contacted.
>>> ...
>>> Needless to say implementations vary in their responses.
>> You’re asking for clarity on what a recursive resolver should return in this case, and not what an authoritative server should return for an $ORIGIN/DS query, right?
> 
> Yes please. I don't see ambiguity in definition for auths. Resolvers and validators are giving me trouble.

You return the response from the parent zone unless the QNAME is . in which case you return the zone apex result. If the server is unaware of the new rules for the QTYPE it will return whichever it has accepted as being valid.  DELEG and DS are types that are generally not queries for and if they are queried for they are done by software that knows how to request the response from the correct servers.  For DNSSEC the server at the end of the forwarding chain needed to be DNSSEC aware so it could retrieve the correct DS.  The same will be the case for DELEG.  The intermediate servers also need to be DELEG/DS aware if they are validating.  A recursive server doesn’t query for DELEG in normal operations.  It learns of DELEG as a side effect of a referral so forwarders are generally not an issue.


> -- 
> Petr Špaček
> 
> -- 
> dd mailing list -- dd@ietf.org
> To unsubscribe send an email to dd-leave@ietf.org

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.39.1 | Report a Bug | By Email | System Status