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.
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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
