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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Brian Dickson writes:
> 
> TL;DR: it is possible to have a signed DNAME in the root for alt (to
> empty.as112.arpa), AND have a local signed alt. Things under this local alt
> can be signed or unsigned.

So now there is the problem of distributing trust anchors for the
locally signed .alt zone just to be able to generate a NXDOMAIN
response locally so that you don't leak names to the root servers.

Note: we have no automatic solution to this problem and there is
no possible solution.

A DNAME at the root is not the right solution to this.

Mark

> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <[e-mail]> wrote:
> 
> >
> > In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@
> > mail.gmail.com>
> > , Brian Dickson writes:
> > >
> > >    - I am in favor of AS112 for ALT
> > >    - For AS112, I prefer the AS112++ method (DNAME)
> > >    - I do not see why the DNAME would/should not be DNSSEC signed
> > >    - Any local use of ALT can be served locally and signed using an
> > >    alternative trust anchor
> >
> > You need a insecure delegation for ALT for the purposes we want to
> > use ALT for.
> >
> > Go setup a test rig where you have a signed root with ALT as you
> > described.  A validiting recursive server which also serves foo.alt.
> > A second validating recursive server which forwards all queries to
> > the first recursive server.  All servers are configured with a trust
> > anchor for the test root zone and are validating responses.  Try
> > to perform a lookup on foo.alt.
> >
> 
> I spent some time mocking up a variety of configurations.
> 
> My original assertion stands; the particulars on making it work are perhaps
> not interesting to everyone.
> However, it falls in the "pics or it didn't happen" category, so here's
> what I did to make it work.
> 
> 1 - set up a general resolver with the standard ICANN root trust anchor.
> Call it "X".
> 2 - set up a local "fake root server" which delegates to a "local alt
> server". Call this fake root server "F"
> 3 - set up a local "alt server" which serves the local "alt" domain
> (including any delegations, etc). Cal this "A".
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a
> "fake root server" instead of the real root. Call this "Y".
> 4 - set up a forwarder, which is configured to always forward to "X",
> except for the zone "alt", where it forwards to "Y". Make sure the
> necessary trust anchors are configured. Call this "Z".
> 
> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
> anchors)
> Z->X otherwise (and validates using the ICANN root trust anchor).
> 
> When I do this, I get real answers for everything but "alt". For anything
> at or under "alt", I get my own local copy.
> 
> Everything validates (or is from below an insecure delegation point).
> 
> 
> >
> > The second recursive server is the validating client that needs to
> > be able to get a answer other than BOGUS.  As we want to allow
> > foo.alt to be unsigned there can't be any other trust anchors,
> > including negative, configured.
> >
> 
> In the above scenario, you CAN have an unsigned foo.alt, and it will not
> get BOGUS.
> 
> If you want me to send you configs, just drop me a line.
> 
> >
> > Only solutions which allow content from the foo.alt zone to be
> > successfully resolved are acceptable.
> >
> > The following will not work with the above rig:
> > * No delegation for ALT.
> > * A secure delegation for ALT.
> > * A DNAME for ALT in the root zone.
> >
> > Mark
> 
> 
> The problem is with your set-up, not the ability to have a working
> local-alt set-up.
> 
> You need to put "foo.alt" somewhere OTHER than on the validating recursive
> server (which knows how to find the local "alt" stuff.)
> 
> TIL you can't mix authority and recursive on the same server, when you are
> the target of a forwarder.
> 
> If the two are separated, it works correctly, including using an alternate
> trust anchor for "alt".
> 
> Brian
> 
> --001a113fece272cf3b0547e877d3
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">TL;DR: it is possible to have a signed DNAME in the root f=
> or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi=
> s local alt can be signed or unsigned.<br><div class=3D"gmail_extra"><br><d=
> iv class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <span=
>  dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]" target=3D"_blank">marka@i=
> sc.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
> margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
> t:1ex"><br>
> In message &lt;<a href=3D"mailto:CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebht=
> [e-mail]">CAH1iCiqXohb_7LsQ2EMo8ZB-<wbr>t20mKq_nUDS8vebhtSX=
> oM13DTg@<wbr>mail.gmail.com</a>&gt;<br>
> <span class=3D"gmail-">, Brian Dickson writes:<br>
> &gt;<br>
> </span>&gt;=C2=A0 =C2=A0 - I am in favor of AS112 for ALT<br>
> &gt;=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)<br>
> &gt;=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s=
> igned<br>
> &gt;=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u=
> sing an<br>
> &gt;=C2=A0 =C2=A0 alternative trust anchor<span class=3D"gmail-"><br>
> <br>
> </span>You need a insecure delegation for ALT for the purposes we want to<b=
> r>
> use ALT for.<br>
> <br>
> Go setup a test rig where you have a signed root with ALT as you<br>
> described.=C2=A0 A validiting recursive server which also serves foo.alt.<b=
> r>
> A second validating recursive server which forwards all queries to<br>
> the first recursive server.=C2=A0 All servers are configured with a trust<b=
> r>
> anchor for the test root zone and are validating responses.=C2=A0 Try<br>
> to perform a lookup on foo.alt.<br></blockquote><div><br></div><div>I spent=
>  some time mocking up a variety of configurations.</div><div><br></div><div=
> >My original assertion stands; the particulars on making it work are perhap=
> s not interesting to everyone.</div><div>However, it falls in the &quot;pic=
> s or it didn&#39;t happen&quot; category, so here&#39;s what I did to make =
> it work.</div><div><br></div><div>1 - set up a general resolver with the st=
> andard ICANN root trust anchor. Call it &quot;X&quot;.</div><div>2 - set up=
>  a local &quot;fake root server&quot; which delegates to a &quot;local alt =
> server&quot;. Call this fake root server &quot;F&quot;<br></div><div>3 - se=
> t up a local &quot;alt server&quot; which serves the local &quot;alt&quot; =
> domain (including any delegations, etc). Cal this &quot;A&quot;.</div><div>=
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a=
>  &quot;fake root server&quot; instead of the real root. Call this &quot;Y&q=
> uot;.</div><div>4 - set up a forwarder, which is configured to always forwa=
> rd to &quot;X&quot;, except for the zone &quot;alt&quot;, where it forwards=
>  to &quot;Y&quot;. Make sure the necessary trust anchors are configured. Ca=
> ll this &quot;Z&quot;.</div><div><br></div><div>Z-&gt;Y if QNAME matches &q=
> uot;alt&quot; or &quot;*.alt&quot; (and validates with local trust anchors)=
> </div><div>Z-&gt;X otherwise (and validates using the ICANN root trust anch=
> or).</div><div><br></div><div>When I do this, I get real answers for everyt=
> hing but &quot;alt&quot;. For anything at or under &quot;alt&quot;, I get m=
> y own local copy.</div><div><br></div><div>Everything validates (or is from=
>  below an insecure delegation point).</div><div>=C2=A0</div><blockquote cla=
> ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
> rgb(204,204,204);padding-left:1ex">
> <br>
> The second recursive server is the validating client that needs to<br>
> be able to get a answer other than BOGUS.=C2=A0 As we want to allow<br>
> foo.alt to be unsigned there can&#39;t be any other trust anchors,<br>
> including negative, configured.<br></blockquote><div><br></div><div>In the =
> above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS=
> .</div><div><br></div><div>If you want me to send you configs, just drop me=
>  a line.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
> px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Only solutions which allow content from the foo.alt zone to be<br>
> successfully resolved are acceptable.<br>
> <br>
> The following will not work with the above rig:<br>
> * No delegation for ALT.<br>
> * A secure delegation for ALT.<br>
> * A DNAME for ALT in the root zone.<br>
> <span class=3D"gmail-HOEnZb"><font color=3D"#888888"><br>
> Mark</font></span></blockquote><div><br></div><div>The problem is with your=
>  set-up, not the ability to have a working local-alt set-up.</div><div><br>=
> </div><div>You need to put &quot;foo.alt&quot; somewhere OTHER than on the =
> validating recursive server (which knows how to find the local &quot;alt&qu=
> ot; stuff.)=C2=A0</div><div><br></div><div>TIL you can&#39;t mix authority =
> and recursive on the same server, when you are the target of a forwarder.</=
> div><div><br></div><div>If the two are separated, it works correctly, inclu=
> ding using an alternate trust anchor for &quot;alt&quot;.</div><div><br></d=
> iv><div>Brian</div></div></div></div>
> 
> --001a113fece272cf3b0547e877d3--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]