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
