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

[Brian Dickson <[e-mail]>]

Mark,

I don't think the use cases for most of the sandbox involving alt, and/or the homenet use case, requires support for validating stubs. If stubs aren't already validating, the incremental addition of a local alt, only requires distribution of the trust anchor to the resolvers. That is a solvable problem for most values of "local".

If use cases for non-local or validating stubs exits, IMHO that rises to the level of requiring something real, not an alt name.

If you think that is something that there is a demand for, I don't know if it might belong in a separate domain.

An insecure delegation from the root may be seen as an invitation for exploitation by squatters.

Sent from my iPhone

> On Feb 6, 2017, at 8:05 PM, Mark Andrews <[e-mail]> wrote:
> 
> 
> 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]