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 9F637128B91
 for <dnsop@ietfa.amsl.com>; Mon, 11 Dec 2017 15:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 fTuTso8zp2cA for <dnsop@ietfa.amsl.com>;
 Mon, 11 Dec 2017 15:46:34 -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 14C181242EA
 for <dnsop@ietf.org>; Mon, 11 Dec 2017 15:46:34 -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 4A8B13B1728;
 Mon, 11 Dec 2017 23:46:31 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1])
 by zmx1.isc.org (Postfix) with ESMTPS id 1255D16007C;
 Mon, 11 Dec 2017 23:46:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by zmx1.isc.org (Postfix) with ESMTP id F28B416007B;
 Mon, 11 Dec 2017 23:46:30 +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 MlTRgt7LHw01; Mon, 11 Dec 2017 23:46:30 +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 EA091160042;
 Mon, 11 Dec 2017 23:46:29 +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: <20171211231643.GA73777@KIDA-6861.local>
Date: Tue, 12 Dec 2017 10:46:27 +1100
Cc: Joe Abley <jabley@hopcount.ca>, Paul Vixie <paul@redbarn.org>,
 dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A496F606-ACC2-4DFD-A792-ADD570A9E137@isc.org>
References: <20171211090051.qjoruin7nkdjsnvd@nic.fr>
 <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr>
 <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca>
 <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org>
 <20171211231643.GA73777@KIDA-6861.local>
To: Kim Davies <kim.davies@iana.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AG-RR3ca2s6muQbQ1fwKdi0q394>
Subject: Re: [DNSOP] [Ext]  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: Mon, 11 Dec 2017 23:46:35 -0000

Firstly they are HOME.ARPA servers.  Just because they are the same =
physical servers it doesn=E2=80=99t mean that policy for the root zone =
content has to apply to other zones on that server.  Maintaining that =
distinction is important. =20

Secondly a otherwise empty zone on these servers will fulfil the =
requirements to provide a insecure delegation.  Just drop the DNAME from =
the zone contents below.  All the servers involved can serve SOA and NS =
records and return NXDOMAIN for names under HOME.ARPA.

If you need to delegate to a different set of servers create a seperate =
constellation of servers that you control directly or by contract.  =
Trying to re-use AS112 servers will never work reliably as you don=E2=80=99=
t have agreements with *all* the operators.  This also applies to the =
operators of EMPTY.AS112.ARPA.

As for DNAME, that is a requirement of DNSSEC which, in theory, all the =
root servers support fully.

Mark

> On 12 Dec 2017, at 10:16 am, Kim Davies <kim.davies@iana.org> wrote:
>=20
> Hi Mark,
>=20
> Quoting Mark Andrews on Tuesday December 12, 2017:
>>=20
>> HOME.ARPA. SOA	A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. =
2017121101 1800 900 604800 86400
>> HOME.ARPA.	NS	A.ROOT-SERVERS.NET.
> ..
>> HOME.ARPA.  DNAME EMPTY.AS112.ARPA.
>=20
> It is unclear to me how this avoids having root servers process DNAME
> records. Given the process of consultation, coordination and testing
> support for DNAME records in the root servers (or relocating the .arpa
> authorities) is likely to take longer than is desirable to have =
home.arpa
> insecurely delegated, the delegation to AS112 was considered as the =
best
> short-term approach even if it is not without its own difficulties.
>=20
> kim

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

