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 <ma...@isc.org> wrote: > > > In message > <cah1icipkwcosmqy3kjvsz42lmk37gld6gp2avtnwk0c83k-...@mail.gmail.com>, 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 <ma...@isc.org> 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"><<a href=3D"mailto:ma...@isc.org"; target=3D"_blank">marka@i= >> sc.org</a>></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 <<a href=3D"mailto:CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebht= >> sxom13...@mail.gmail.com">CAH1iCiqXohb_7LsQ2EMo8ZB-<wbr>t20mKq_nUDS8vebhtSX= >> oM13DTg@<wbr>mail.gmail.com</a>><br> >> <span class=3D"gmail-">, Brian Dickson writes:<br> >> ><br> >> </span>>=C2=A0 =C2=A0 - I am in favor of AS112 for ALT<br> >> >=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)<br> >> >=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s= >> igned<br> >> >=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u= >> sing an<br> >> >=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 "pic= >> s or it didn't happen" category, so here'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 "X".</div><div>2 - set up= >> a local "fake root server" which delegates to a "local alt = >> server". Call this fake root server "F"<br></div><div>3 - se= >> t up a local "alt server" which serves the local "alt" = >> domain (including any delegations, etc). Cal this "A".</div><div>= >> 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&q= >> uot;.</div><div>4 - set up a forwarder, which is configured to always forwa= >> rd to "X", except for the zone "alt", where it forwards= >> to "Y". Make sure the necessary trust anchors are configured. Ca= >> ll this "Z".</div><div><br></div><div>Z->Y if QNAME matches &q= >> uot;alt" or "*.alt" (and validates with local trust anchors)= >> </div><div>Z->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 "alt". For anything at or under "alt", 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'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 "foo.alt" somewhere OTHER than on the = >> validating recursive server (which knows how to find the local "alt&qu= >> ot; stuff.)=C2=A0</div><div><br></div><div>TIL you can'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 "alt".</div><div><br></d= >> iv><div>Brian</div></div></div></div> >> >> --001a113fece272cf3b0547e877d3-- > -- > 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
