And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain? Is it ok if we say yes and delegate the name? If not, what is the basis for us to say no?
Steve Crocker [I am having trouble sending from st...@shinkuro.com, but I am receiving mail without trouble. Please continue to send mail to me at st...@shinkuro.com] > On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > The DNAME has an effect similar to delegation, except that in the case of the > AS112++ RFC ( https://tools.ietf.org/html/rfc7535 > <https://tools.ietf.org/html/rfc7535> ) , the target is a well-known & > published empty zone (as112.arpa.) > > (Delegation and DNAME cannot coexist for the same owner name - that is one of > the edicts for DNAME, similar to CNAME.) > > Any local configuration of something.alt (as an authoritatively served zone) > would be matched before checking the cache or attempting recursive > resolution, per 103[345]. > > I don't have any desire or intention of local something.alt, I'm just > pointing out that the existence of a signed NXD result (via DNAME to an empty > zone) doesn't break such a set-up. > > > > The reason for DNAME instead of delegation, is that it avoids the operators > of AS112 instances from having to configure the new zone(s) whenever a new > "delegation" occurs. > > If, instead, a delegation were done, the specific zone (.alt) would need to > be configured and served somewhere. > > RFC7535 is designed to avoid the need for coordination in configuring such > zones. > > (RFC7535 also allows authorities for other places in the DNS tree to make use > of AS112, but that is a non-sequitur.) > > Brian > > On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.croc...@gmail.com > <mailto:steve.croc...@gmail.com>> wrote: > Are you also expecting ALT will never be delegated in the root? If it were > to be delegated in the root, what impact would that have on the uses you have > in mind? > > Steve Crocker > [I am having trouble sending from st...@shinkuro.com > <mailto:st...@shinkuro.com>, but I am receiving mail without trouble. Please > continue to send mail to me at st...@shinkuro.com <mailto:st...@shinkuro.com>] > > >> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dick...@gmail.com >> <mailto:brian.peter.dick...@gmail.com>> wrote: >> >> Stephane wrote: >> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >> Warren Kumari <warren at kumari.net <http://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 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >> https://www.ietf.org/mailman/listinfo/dnsop >> <https://www.ietf.org/mailman/listinfo/dnsop> > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
