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

Mark Andrews <marka@isc.org> Mon, 11 December 2017 23:46 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 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’t mean that policy for the root zone content has to apply to other zones on that server.  Maintaining that distinction is important.  

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’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:
> 
> Hi Mark,
> 
> Quoting Mark Andrews on Tuesday December 12, 2017:
>> 
>> 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.
> 
> 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.
> 
> kim

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