In message <CAH1iCip=jko4-wimttkdns3v_8kzp0ptd13ksptzl6n7pph...@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 <ma...@isc.org> wrote:
> 
> >
> > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@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: ma...@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:ma...@isc.org"; target=3D"_blank">ma...@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>2e5ea0b8c...@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:ma...@isc.org";>ma...@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: ma...@isc.org

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

Reply via email to