IETF Logo Mail Archive

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

Mark Delany <m9p@india.emu.st> Fri, 05 May 2023 17:40 UTC

Return-Path: <m9p@india.emu.st>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C05C152DA5 for <dnsop@ietfa.amsl.com>; Fri, 5 May 2023 10:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.996
X-Spam-Level:
X-Spam-Status: No, score=-6.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_f8QCtQENFw for <dnsop@ietfa.amsl.com>; Fri, 5 May 2023 10:39:59 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEFC152DB9 for <dnsop@ietf.org>; Fri, 5 May 2023 10:39:58 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id B7F7A3AD2E; Sat, 6 May 2023 03:39:54 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1683308394; bh=RkZCtt0E/t9f4lIXy1CbCCPam4A=; h=Comments:Received:From:Comments:Message-ID:Date:To:In-Reply-To: Subject:Content-Type:References:Mime-Version:Content-Disposition; b=XyvsBbi1E2+/pDcQH44vgJux3DwqxigDuwoUDdl27CVR8pYjkxtrafYvBhCCS9w27 QQa3KgBdVh9L57J3iSMnmRCtdnuhwlKF26aEbeZIg4j8tOVRZ/Oq3JzxyB7v5veYzc aBRztNiwtp1c1o52MGtDuey6qYbZAzd+7Rpy81oE=y81oE=
Comments: QMDA 0.3a
Received: (qmail 67956 invoked by uid 1001); 5 May 2023 17:39:54 -0000
From: Mark Delany <m9p@india.emu.st>
Comments: QMDASubmit submit() 0.2.0-final
Message-ID: <0.2.0-final-1683308394.672-0x6b1550@qmda.emu.st>
Date: Fri, 05 May 2023 17:39:54 +0000
To: dnsop@ietf.org
In-Reply-To: <CAHw9_iJ53q15k_VH5mK0NVArd=e0g6-ouc26=XrK0fzv+EmTyQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
References: <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st> <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com> <20230504.200747.619569100111463947.he@uninett.no> <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io> <CAHw9_iJ53q15k_VH5mK0NVArd=e0g6-ouc26=XrK0fzv+EmTyQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mPDk0u-kjqAbMk32mGUcodz466M>
Subject: Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2023 17:40:04 -0000

On 05May23, Warren Kumari apparently wrote:

> I think that a parent should check if the name servers that are
> being proposed actually answer for the domain[0], and strongly
> suggest (but do not prevent) that that be fixed[1].

"Strongly suggest" is definitely as far as I would go because you may
have a bit if a chicken and egg problem. Some processes may prefer to
configure the parent first while others may wish to configure the
delegated name servers first.

More specifically, I have a no-configuration reverse server which
deduces its NS details from the delegation (the goal being to minimize
duplication of configuration information). It's impossible for it to
be configured and serve correctly without first gaining information
from the delegating parent.


Mark.

v2.23.0 | Report a Bug | By Email