On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson < brian.peter.dick...@gmail.com> wrote:
> 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 > > That's a lot of overhead just to get a local .alt domain. What I envision for the future is an insecure delegation of .alt, and an option in future cable modems to enable a local "homenet.alt" domain, which would just work, even if some stub resolvers in the house are validating. The cable modem is already a recursive resolver or forwarder, and dhcp server, so it seems a logical place for the local domain. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
