Re: [DNSOP] Delegation acceptance checks

Havard Eidnes <he@uninett.no> Fri, 05 May 2023 17:02 UTC

Return-Path: <he@uninett.no>
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 D9877C152D8E for <dnsop@ietfa.amsl.com>; Fri, 5 May 2023 10:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=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=uninett.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 c6vAGj6fLB8Y for <dnsop@ietfa.amsl.com>; Fri, 5 May 2023 10:02:02 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE286C152D8A for <dnsop@ietf.org>; Fri, 5 May 2023 10:02:00 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id AF25143ECED; Fri, 5 May 2023 19:01:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1683306117; bh=T+PlBDKyE7UqHaeeQ9Dj2Mcfts+RPA7UqUN7G3v/9TI=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=kfo036uL9vWp0wmslfTHdC+33LRnj2feLycfcGItePKxVJoHxYrQ6L0FVTyvXRxG+ 5BkB51SlZ1XcXYsJgPdcyDBYVymhGW6LXO6syiw+BogO8azNX3Uo3AasNprD/v8jZy Nm8U5xYlYXXd/X2XMhYUqSe7wwWQoDaVadQhHpYc=
Date: Fri, 05 May 2023 19:01:57 +0200
Message-Id: <20230505.190157.288114951645860629.he@uninett.no>
To: warren@kumari.net
Cc: peter@desec.io, m9p@india.emu.st, dnsop@ietf.org, nils@desec.io
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <CAHw9_iJ53q15k_VH5mK0NVArd=e0g6-ouc26=XrK0fzv+EmTyQ@mail.gmail.com>
References: <20230504.200747.619569100111463947.he@uninett.no> <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io> <CAHw9_iJ53q15k_VH5mK0NVArd=e0g6-ouc26=XrK0fzv+EmTyQ@mail.gmail.com>
X-Mailer: Mew version 6.9 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XmxaVx0WKPmzFOHdlOH4vCbLykE>
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: Fri, 05 May 2023 17:02:06 -0000

>> 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