Re: [DNSOP] ALT-TLD and (insecure) delgations.

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.crocker@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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
>
>
>
>
>
> On Feb 3, 2017, at 12:28 PM, Brian Dickson <brian.peter.dickson@gmail.com>
> wrote:
>
>
>
> On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.crocker@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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
>
>
>
>
>
> On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@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.crocker@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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dickson@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
>
>