Re: [dd] Back to the charter
Wes Hardaker <wjhns1@hardakers.net> Thu, 04 April 2024 21:35 UTC
Return-Path: <wjhns1@hardakers.net>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0DC180B69 for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 OKtF29txnlOE for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:35:17 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 38F59C1519A4 for <dd@ietf.org>; Thu, 4 Apr 2024 14:35:17 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (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 mail.hardakers.net (Postfix) with ESMTPSA id AAEA320F89; Thu, 4 Apr 2024 14:35:16 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net AAEA320F89
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1712266516; bh=i5lS5NuHLL3TiNP2sVJPKCoCJndBlab05+xwsV7JZVI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pigsNrxZOq5xDadkFnAjpDpN6J+g4qPXzdDLwRO5EVUEVLr1tpgqAcvmaSk6Dn09u vU3KJ3Jlzk/3G4KJLJhQiowHtnXVpFpKIzU5r8GQnsXZrb5spbN3Fo2r6Ex1dOPsSr 1UqvUAxPqHkbToWzq1JqhXVK+4rj3L/XhW++COxE=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Havard Eidnes <he=40uninett.no@dmarc.ietf.org>
Cc: Paul.Hoffman@icann.org, dd@ietf.org
In-Reply-To: <20240322.112220.1429291612198331518.he@uninett.no> (Havard Eidnes's message of "Fri, 22 Mar 2024 11:22:20 +0100 (CET)")
References: <49CC837E-4D8E-45CF-A0B5-7A28A82B1939@icann.org> <20240322.112220.1429291612198331518.he@uninett.no>
Date: Thu, 04 Apr 2024 14:35:16 -0700
Message-ID: <yblcyr495gr.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/IjeT9SoW47coeWRxfyKjnnbYxGA>
Subject: Re: [dd] Back to the charter
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 21:35:22 -0000
Havard Eidnes <he=40uninett.no@dmarc.ietf.org> writes: > * I get the impression this group is trying to solve more than one > problem (at least two?), but that those problems are not explicitly > stated and justified in the above paragraph. I think the two main > ones are: > > - There is a desire to introduce other DNS transport protocols than > DNS-over-port-53 for the communication between recursive > resolvers and publishing name servers. An important part of the > justification for this desire is to further protect the transport > of DNS queries against eavesdropping, since these queries have up > to now has been sent in the clear. This is however basically > impossible to do without introducing "additional signalling" > about the capabilities of a publishing name server at a > delegation point. > > - There is a desire to better support outsourcing most if not all > aspects of DNS publishing operations to a third party, a "domain > operator", as distinct from the "domain holder" and the > "delegating zone operator", and to either reduce or eliminate the > need for out-of-band exchange of information between the "domain > operator" and the "delegating zone operator" which today possibly > involves the "domain holder". The goal is that the "domain > holder" does not need to be involved in the various technical > changes for the delegation of the domain, such as the addition or > removal of publishing name servers, IP address changes for > publishing name servers and updates triggered by periodic DNSKEY > rollovers. > > Perhaps the slightly different problems to be solved and their > justification should be stated more explicitly? I agree these are the two cases that there is immediate interest to work on first. Do you think your two cases above are missing? The existing bullets already cover these two cases. - A specification for how to use the new delegation information to perform aliasing of delegation information. This is expected to be published as a standards-track RFC. - A specification for facilitating the use of additional transports for DNS. This is expected to be published as a standards-track RFC. -- Wes Hardaker USC/ISI
- [dd] Back to the charter Paul Hoffman
- Re: [dd] Back to the charter George Michaelson
- [dd] likely charter issues Geoff Huston
- [dd] Charter issue: resource records Paul Hoffman
- [dd] Charter issue: synchronization between paren… Paul Hoffman
- [dd] Charter issue: authority models Paul Hoffman
- [dd] Charter issue: Introduction of new signaling Paul Hoffman
- Re: [dd] Back to the charter Wes Hardaker
- Re: [dd] Back to the charter George Michaelson
- Re: [dd] Charter issue: Introduction of new signa… Geoff Huston
- Re: [dd] Back to the charter Havard Eidnes
- Re: [dd] Charter issue: synchronization between p… Wes Hardaker
- Re: [dd] Back to the charter Wes Hardaker