Re: [DNSOP] Delegation acceptance checks

Dr Eberhard W Lisse <el@lisse.NA> Sat, 06 May 2023 18:04 UTC

Return-Path: <el@lisse.NA>
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 17A44C14CF13 for <dnsop@ietfa.amsl.com>; Sat, 6 May 2023 11:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no
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 jnsVjchgztzU for <dnsop@ietfa.amsl.com>; Sat, 6 May 2023 11:04:44 -0700 (PDT)
Received: from fra.omadhina.net (fra.omadhina.net [80.240.31.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FCBC14E513 for <dnsop@ietf.org>; Sat, 6 May 2023 11:04:43 -0700 (PDT)
Received: from [192.168.1.10] (aries.lisse.na [160.242.14.157]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by fra.omadhina.net (Postfix) with ESMTPSA id 884747D010; Sat, 6 May 2023 18:04:40 +0000 (UTC)
Message-ID: <3f015d2d-5446-6ec2-f461-012e3d4252fa@lisse.NA>
Date: Sat, 06 May 2023 20:04:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Reply-To: el@lisse.NA
Cc: el@lisse.NA
Content-Language: en-US
To: dnsop@ietf.org
References: <20230504.200747.619569100111463947.he@uninett.no> <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io> <CAHw9_iJ53q15k_VH5mK0NVArd=e0g6-ouc26=XrK0fzv+EmTyQ@mail.gmail.com> <20230505.190157.288114951645860629.he@uninett.no>
From: Dr Eberhard W Lisse <el@lisse.NA>
Organization: Dr Eberhard W Lisse
In-Reply-To: <20230505.190157.288114951645860629.he@uninett.no>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FTayRnsiEIY3dPul7KltpFADhIQ>
Subject: Re: [DNSOP] Delegation acceptance checks
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: Sat, 06 May 2023 18:04:49 -0000

Håvard,

ccNSO has no role to play here.

Each ccTLD makes its own rules, and not that it matters, being tiny,
.NA does require working name servers (at registration, and when we
check on it).

el

On 05/05/2023 19:01, Havard Eidnes wrote:
>>> I imagine that others also spend time on sorting out these entirely
>>> unnecessary issues.  If guidance were developed on delegation
>>> acceptance checks,
>>
>> Well, yes... but where?
> 
> ccNSO, perhaps?
> 
> My advice would be to only enforce checks where violations would
> negatively impact operations (e.g. disallow lame delegation setups),
> and not enforce pure "dotting the i's and crossing the t's"
> requirements where doing so contributes minimal to no improvement
> operationally.
> 
>> To me it feels like the IETF would be the right place to discuss and
>> develop the guidance (personally 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].
> ...
>> [0]: Some, including myself, would call this lame, but...
> 
> Yup.
> 
> I personally think that if a ccTLD insists on non-lame delegations at
> the time of registration or update, I would not object.
> 
>> [1]: As an example, I have a-random-test-domain.net pointing to
>> nameservers which have no idea about this domain - and I did that
>> intentionally...
> 
> There's of course always the option of doing your own dirty work in a
> child zone of your own properly delegated and operational domain.
> 
> Regards,
> 
> - Håvard

-- 
Dr. Eberhard W. Lisse   \         /       Obstetrician & Gynaecologist
el@lisse.NA             / *      |  Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht  \      /  If this email is signed with GPG/PGP
10007, Namibia           ;____/ Sect 20 of Act No. 4 of 2019 may apply