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 > <mailto: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 > <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:18 PM, Brian Dickson <brian.peter.dick...@gmail.com >> <mailto: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
