Re: [DNSOP] Delegation acceptance checks

Peter Thomassen <peter@desec.io> Mon, 08 May 2023 10:31 UTC

Return-Path: <peter@desec.io>
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 A12FCC1519A2; Mon, 8 May 2023 03:31:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 GioccjkYXctj; Mon, 8 May 2023 03:31:49 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5EDC1519A0; Mon, 8 May 2023 03:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cQmf0Cr1CBasYW220i6Kmp0ctsWsdyMkLg0mDJiJpQ4=; b=K9/IX8vyVkBLV52PfBLw2o4bh+ AE16hQQTuamHTUfGN0N0LRqnoC5vVXMXCdnTkelw26qB4nA4D4syAHYEu3shdHITD//I3VpFP7i/s JhYsBbavxuPei5nGQ9BfIU7Y/DFtYuH8Vv8wQl+pdRsR6QmyAGT/6lI64JU+ui6d+OtfRXJlUxqk6 27aBV20/GWcPPQwOMpNZhBqoaOy6UjUnv15CQ1ys+wUFsDSMbZWwb0QIHrwWzPoDna1/yFjkAmrSQ Dkp2pRsCDTul99MEk3djOIW9h8RkYJ1ycdXhUmRgHQX8jjWHNcfM8BNbAUIupcU/nO1OnUdA6RvSe xth7/dOg==;
Received: from ip5b41b091.dynamic.kabel-deutschland.de ([91.65.176.145] helo=[192.168.178.70]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1pvy9h-005ZM3-Tc; Mon, 08 May 2023 12:31:46 +0200
Message-ID: <85560f7e-9507-f821-c425-9f277c28bd68@desec.io>
Date: Mon, 08 May 2023 12:31:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Havard Eidnes <he=40uninett.no@dmarc.ietf.org>, jabley@strandkip.nl
Cc: m9p@india.emu.st, nils@desec.io, dnsop@ietf.org
References: <20230504.200747.619569100111463947.he@uninett.no> <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io> <infYuCGtin93oe5p2i5xJp8pcRb7w42d543MM2sVkYVjvFHtzAXROt49cDyiguu_SZz7xg4xk802loka9IA_0U--Uu3cJIQOigisNvOOw7A=@strandkip.nl> <20230507.011052.1632879695052938676.he@uninett.no>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <20230507.011052.1632879695052938676.he@uninett.no>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nDYoDqIQyKiTPVWoA-XU_S3bUaQ>
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: Mon, 08 May 2023 10:31:55 -0000

Hi Håvard,

On 5/7/23 01:10, Havard Eidnes wrote:
> I guess it depends on what service the registry is actually
> offering.
> 
> One way to look at it is that it's offering a service to extend the
> public DNS name space to registrants.  In that scenario it makes
> perfect sense to do a one-time check on initial registration or
> update, with the intention of preventing the domain owner from
> shooting himself in the foot.

How do you know it's a shot in the foot?

It's possible a registrant doesn't want to provide DNS service and just reserve the name. Or, as Joe said, it could be a name served only in some "internal" context. If not used publicly, that doesn't seem "unhealthy".

For *registration* checks, there was no DNS service so far, so nothing breaks if none is configured.

(The situation may be different if a delegation update breaks the delegation, which might warrant a warning.)

> On the technical side, I don't think anyone has suggested to
> introduce repeated checks with de-registration either of a single NS
> or an entire domain on auto-polit.  Does any public registry
> actually do that sort of thing?  I've never heard of it.  I call
> that a straw man.

If you have a .is domain and you don't follow the requirements in [1] (including conditions on NS reachability and consistency, child-size NS RRset content and TTL, SOA MNAME/RNAME/timers), the operator will receive the following message:

	The setup of zone <name>.is on its nameservers appears not to be
	according to ISNIC's requirements for .IS delegations.

	Please see requirements [1] for information on these conditions.

	Please make sure that the setup of domain <name>.is is according to
	the above conditions. The domain can be tested [2]

	ISNIC will put on hold domains not fulfilling the delegation
	requirements for extended periods. See article 21 in the .is
	delegation rules. See our rules [3]

	ISNIC will automatically park the domain if it is still non-compliant
	after being on hold due to technical non-compliance for 30 days.

[1]: https://www.isnic.is/en/domain/req
[2]: https://www.isnic.is/en/domain/test?domain=<name>.is
[3]: https://www.isnic.is/en/domain/rules#k6

Best,
Peter

-- 
https://desec.io/