IETF Logo Mail Archive

Re: [dns-privacy] how can we ADoT?

Tony Finch <dot@dotat.at> Wed, 11 November 2020 20:11 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5023A1026 for <dns-privacy@ietfa.amsl.com>; Wed, 11 Nov 2020 12:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D6QzbtohEes for <dns-privacy@ietfa.amsl.com>; Wed, 11 Nov 2020 12:11:24 -0800 (PST)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFEA3A0FFD for <dns-privacy@ietf.org>; Wed, 11 Nov 2020 12:11:24 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59430) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kcwSg-000Ox3-Lw (Exim 4.92.3) (return-path <dot@dotat.at>); Wed, 11 Nov 2020 20:11:22 +0000
Date: Wed, 11 Nov 2020 20:11:22 +0000
From: Tony Finch <dot@dotat.at>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <74e8ec197b5447e7b7aee12c91e04721@verisign.com>
Message-ID: <alpine.DEB.2.20.2011111956380.17166@grey.csi.cam.ac.uk>
References: <alpine.DEB.2.20.2011111856160.17264@grey.csi.cam.ac.uk> <74e8ec197b5447e7b7aee12c91e04721@verisign.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/0qpqec1Gn0n_ih5fjsfL1nEys00>
Subject: Re: [dns-privacy] how can we ADoT?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 20:11:26 -0000

Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
>
> It's not an EPP limitation. We can always define an EPP extension to add
> information to the parent zone. The issue is if the zone administrator
> can/will publish that information in the zone and if EPP clients are able and
> willing to provide it.

True! I am using "EPP" as a grossly unfair and simplified shorthand for
the whole registry/registrar ecosystem. TBH I think most of the
difficulties are in registrar user interfaces and APIs, rather than EPP. I
would be very grateful if someone could write a more informed and accurate
description of the registr* aspects of how feasible it might be to change
the domain delegation model.

If it's worth revising these notes I will change this part to be less
lazy. Thanks for reading and it and giving feedback!

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Rockall: Northwest 3 to 5 backing south 7 to severe gale 9, perhaps storm 10
later. Rough, becoming very rough or high. Rain. Moderate becoming poor.

v2.23.0 | Report a Bug | By Email