IETF Logo Mail Archive

Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa

Mark Andrews <marka@isc.org> Thu, 14 December 2017 01:53 UTC

Return-Path: <marka@isc.org>
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 6924012421A for <dnsop@ietfa.amsl.com>; Wed, 13 Dec 2017 17:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 QovNaUv-vKA6 for <dnsop@ietfa.amsl.com>; Wed, 13 Dec 2017 17:53:41 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 47CC61243FE for <dnsop@ietf.org>; Wed, 13 Dec 2017 17:53:41 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id ADE893AF9C1; Thu, 14 Dec 2017 01:53:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 76A3216007F; Thu, 14 Dec 2017 01:53:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6100B160048; Thu, 14 Dec 2017 01:53:33 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mzWgUW7tyVof; Thu, 14 Dec 2017 01:53:33 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 63D9D160041; Thu, 14 Dec 2017 01:53:32 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca>
Date: Thu, 14 Dec 2017 12:53:30 +1100
Cc: Ted Lemon <mellon@fugue.com>, Paul Vixie <paul@redbarn.org>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D49204C6-6DCA-4991-9DDF-0915AF913BBB@isc.org>
References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <EC253232-3713-426E-9300-20AE38C8BE4F@hopcount.ca> <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PmF2SRTItOmqprHqq380YTQ6h_8>
Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 14 Dec 2017 01:53:43 -0000

> On 14 Dec 2017, at 11:31 am, Joe Abley <jabley@hopcount.ca> wrote:
> 
> Hi Ted,
> 
>> On Dec 13, 2017, at 17:14, Ted Lemon <mellon@fugue.com> wrote:
>> 
>> Can you point to the actual ambiguity?   The reason we said "one or more black hole servers" was to leave it up to the operator of .arpa to decide which black hole servers and how many of them.   That was a deliberate choice, not an omission.
> 
> The ambiguity is (for example) that "point to" is not a well-defined phrase, given that we have two documented ways of doing this in the AS112 project, and neither is "black hole server" which from the examples seems it refers to servers made available from the AS112 project, but which examples surely are non-normative.
> 
> This no doubt sounds pedantic to many, but I think (a) that a certain precision is warranted in directions to the IANA and (b) given that the obvious interpretation is not possible to implement accurately (the problems with new delegations to the original AS112 servers having been well documented) ambiguity is in fact *required* in order for anything to happen here.

And if IANA didn’t understand the instructions they had a opportunity during the RFC creation process to request clarification.   It is a explicit step in the process to try to prevent issues like this.  IANA could have done the delegation at that point in time and had it in place before the RFC exited the RFC publication process and even asked “Is this correct?”.  IANA make similar queries for registry entries.

Creating a delegation is a operation that happens millions to times a day around the world as is setting up name servers to serve a zone.

As for “point to” read it as “delegated to” if you want to nit pick.   Also IANA was NOT instructed to delegate to the AS112 servers.  IANA was instructed to delegate to back hole servers and a example of which, the AS112 servers, was presented.

Mark

> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email