Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark Andrews <marka@isc.org> Tue, 07 February 2017 23:44 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 94316129EA0 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 15:44:16 -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, RP_MATCHES_RCVD=-0.001, 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 2I4H3TVfMWMw for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 15:44:15 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 BF764129E90 for <dnsop@ietf.org>; Tue, 7 Feb 2017 15:44:14 -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.ams1.isc.org (Postfix) with ESMTPS id EAE681FCB02; Tue, 7 Feb 2017 23:44:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A80B4160077; Tue, 7 Feb 2017 23:44:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92418160076; Tue, 7 Feb 2017 23:44:09 +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 gMRLM9B_OGNz; Tue, 7 Feb 2017 23:44:09 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 00304160054; Tue, 7 Feb 2017 23:44:08 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 99248633D3CA; Wed, 8 Feb 2017 10:44:05 +1100 (EST)
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <D4C0D518-A3ED-4555-93DA-2EA12D82A662@fugue.com> <CAHw9_iK7Vt+ZNw8=E-b+w9gGhwB9fZNqHYp2pqKqT__RgcDttQ@mail.gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@mail.gmail.com>
In-reply-to: Your message of "Tue, 07 Feb 2017 14:18:41 -0800." <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@mail.gmail.com>
Date: Wed, 08 Feb 2017 10:44:05 +1100
Message-Id: <20170207234405.99248633D3CA@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sNdQAVKo-FmWKOdxBDemdyB_a40>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 07 Feb 2017 23:44:16 -0000

In message <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@mail.gmail.com>
, Brian Dickson writes:
> --f403045fbba86cf7240547f82103
> Content-Type: text/plain; charset=UTF-8
> 
> On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <marka@isc.org> wrote:
> 
> >
> > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon
> > writes:
> > > Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > > When I validate, I get a secure denial of existence.   This is the
> > > correct behavior.   Why do you think we would get a SERVFAIL?
> >
> > Because your testing is incomplete.
> >
> > Go add a empty zone (SOA and NS records only) for alt to your
> > recursive server.  This is what needs to be done to prevent
> > privacy leaks.
> >
> >
> Here are some possible alternatives (to having the empty zone be named
> "alt.").
> 
> First: make the locally served empty zone be "empty.as112.arpa".
> 
> Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and the
> locally served zone be the same name.

Which does not work.  If you are serving up a local

	ALT. SOA ...
	ALT. NS	...
	ALT. DNAME alt.empty.as112.arpa.

then it will not have RRSIG records so it will not validate unless there
is a INSECURE delegation for .ALT.

I really don't see the point in having the DNAME there other than you
seem to want a DNAME there.

The public version of the insecure .ALT zone could have a DNAME but
we are not talking about those contents at the moment.  We are
talking about what goes into the root zone to make this work.

> Or, third, have some other name for the zone (anything other than alt, or
> really anything that doesn't collide with a global name),

Nothing doesn't collide with a global name.  This is all about carving
a namespace out of the global namespace.

> and then use a
> local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that
> zone's name (e.g. "homenet" or "homenet.local" or whatever  you wish).

Homenet is still part of the global namespace.  Once there is a delegation
and a RFC which states that it is not part of the global namespace then
you have other issues or should we start squatting on the homenet space?
 
> Since all of the above occur at or below the transition to unsigned, they
> should validate. (I need to test these, but I don't see why they wouldn't
> work, and all of the above avoid leaking queries to the root or to AS112
> servers.)
> 
> Brian
> 
> 
> 
> > Configure another recursive server to forward its queries to this
> > server and enable validation.
> >
> > Now ask for foo.alt from this second server.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
> 
> --f403045fbba86cf7240547f82103
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
> te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <span dir=3D"ltr">&lt;<a h=
> ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org</a>&gt;</span>=
>  wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
> der-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=
> =3D"h5"><br>
> In message &lt;<a href=3D"mailto:18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue=
> .com">18F2EB0D-5BD0-4CC5-B02C-<wbr>2E5EA0B8CC23@fugue.com</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt; Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S=
> ERVFAIL.<br>
> &gt; When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This =
> is the<br>
> &gt; correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL=
> ?<br>
> <br>
> </div></div>Because your testing is incomplete.<br>
> <br>
> Go add a empty zone (SOA and NS records only) for alt to your<br>
> recursive server.=C2=A0 This is what needs to be done to prevent<br>
> privacy leaks.<br>
> <br></blockquote><div><br></div><div>Here are some possible alternatives (t=
> o having the empty zone be named &quot;alt.&quot;).</div><div><br></div><di=
> v>First: make the locally served empty zone be &quot;empty.as112.arpa&quot;=
> .</div><div><br></div><div>Or, second method: have the DNAME RDATA be &quot=
> ;alt.empty.as112.arpa&quot;, and the locally served zone be the same name.<=
> /div><div><br></div><div>Or, third, have some other name for the zone (anyt=
> hing other than alt, or really anything that doesn&#39;t collide with a glo=
> bal name), and then use a local DNAME from &quot;empty.as112.arpa&quot; (or=
>  &quot;alt.empty,as112.arpa&quot;) to that zone&#39;s name (e.g. &quot;home=
> net&quot; or &quot;homenet.local&quot; or whatever =C2=A0you wish).</div><d=
> iv><br></div><div>Since all of the above occur at or below the transition t=
> o unsigned, they should validate. (I need to test these, but I don&#39;t se=
> e why they wouldn&#39;t work, and all of the above avoid leaking queries to=
>  the root or to AS112 servers.)</div><div><br></div><div>Brian</div><div><b=
> r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
> 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Configure another recursive server to forward its queries to this<br>
> server and enable validation.<br>
> <br>
> Now ask for foo.alt from this second server.<br>
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> Mark<br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:marka@isc.org">marka@isc.org</a><br>
> </div></div></blockquote></div><br></div></div>
> 
> --f403045fbba86cf7240547f82103--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org