DNAME was considered early in the IDN evaluations, so it's not exactly unknown in the Icann community
On Fri, Feb 3, 2017 at 15:33 Steve Crocker <steve.croc...@gmail.com> wrote: > We (ICANN) have no mechanism or process for inserting a DNAME record into > the root. We do have a process for considering the general issue, but, so > far as I know, no one has yet brought that idea into the ICANN/PTI arena. > > > > 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:28 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > > > On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.croc...@gmail.com> > wrote: > > 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? > > > The insertion of the DNAME record in the root, instantiates the ALT > domain. It says the ALT domain exists. > > However, the DNAME target of an empty zone, assures (with DNSSEC > signatures) that no names below ALT exist. > > So, a query to a root server for "alt." would get the DNAME (if the query > was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE. > > And a query to a root server for "anything.alt" would get the DNAME to > AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) > would get NXD. > > As to the question about applying for "alt": it means no one can apply for > .alt as a TLD, because it is taken. That is the basis for saying "no". > > Brian > > > > > > > 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 ) , 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> > 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, but I am receiving > mail without trouble. Please continue to send mail to me at > st...@shinkuro.com] > > > On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > 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 > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > > > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
