Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

From: Brian Dickson <[email-masked]>
Date: Fri, 5 Jan 2018 14:03:12 -0800

[Attribution of the following quotes to Joe and Petr omitted...]

> > However, I think the more general idea that queries for internal names
> > should be leaked towards unknown AS112 operators is problematic. As an
> > end-user I would prefer my leaked queries to be jealously hoarded by one
> > of twelve root server operators than an inbound number of anonymous and
> > potentially ephemeral AS112 operators.
> >
> > The potential for complete data collection at the root servers goes down
> > as resolvers implement aggressive NSEC caching. In the case of a
> Unfortunatelly aggressive use of NSEC will not help because the name
> will exist (either with NS or DNAME).

Isn't .internal already a relatively non-trivial thing for users/admins to
implement? Potential leakage only occurs if someone actively does
".internal" usage.

Thusly:

Perhaps guidance on how to minimize leakage (to zero) would be appropriate?

Things that come to mind:
- Use a benign SLD, such as internal, so the suffix of any name would be
".internal.internal"
- plus
- QNAME minimization and/or aggressive NSEC, to prune anything below
.internal.internal ever resulting in anything other than synthesized
NXDOMAIN (and thus not leaking)?
- and/or locally running an AS112 instance
- and/or locally installing the namespace of AS112 or its name server names

If the only thing any AS112 operator ever saw was "internal.internal"
queries, the issue is mostly moot/mute.

Brian