In message <cah1iciqxohb_7lsq2emo8zb-t20mkq_nuds8vebhtsxom13...@mail.gmail.com> , Brian Dickson writes: > > Stephane wrote: > > > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > > Warren Kumari <warren at kumari.net> wrote > > a message of 103 lines which said: > > > > > or 2: request that the IANA insert an insecure delegation in the > > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > > something similar. > > > > Here, people may be interested by draft-bortzmeyer-dname-root (expired > > but could be revived). The main objection was the privacy issue > > (sending user queries to the "random" operators of AS112.) > > > > > My opinion on these issues are as follows, roughly: > > - 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 > - I don't think there is any issue with having both the NXD from the > root, and the local assertion of existence, both present (in cache and > in > authoritative data respectively) > - Maybe there are issues with specific implementations? > - If anyone knows of such problems, it would be helpful to identify > them along with the implementation and version > - For AS112 privacy, perhaps someone should write up a recommendation to > set up local AS112 instances, to provide privacy, as an informational RFC? > - Even simply through resolver configurations, without a full AS112 > "announce routes"? > - Do any resolver packages offer such a simple AS112 set-up? > - Maybe the efforts for privacy should start there (implement first, > then document)? > - Do any stub resolver packages include host-local AS112 > features/configurations? > > Overall, I'm obviously in favor of use of ALT, and for signing whatever is > done for ALT, and for use of DNAME for ALT. > > Brian "DNAME" Dickson
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. 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. 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 -- 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
