[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

[James Galvin]

On Thu, Jan 9, 2014 at 12:14 PM, Joe Abley <jabley at hopcount.ca> wrote:

> Hi Jeff,
>
> On 2014-01-09, at 11:18, Jeff Schmidt <jschmidt at jasadvisors.com> wrote:
>


>  Are you talking about changing the mechanism by which new TLDs are
> provisioned, such that a new TLD will initially be implemented with A and
> MX records in the root zone, to be followed by a more conventional NS set
> later?
>
> Or are you rather talking about introducing a new requirement for new gTLD
> registry operators whereby delegations from the TLD zone are handled that
> way?
>

Why not both?  I interpreted the article as suggesting a concept, which the
community can consider the best way to implement.

Frankly, we know that name collisions are going to happen.  The only
judgement to be made is to evaluate the consequences of the collisions.
This proposal strikes me as a good practical solution to the problem of
scoping trial delegations both to provide notification and thus data about
consequences to be considered.

Given the number of new gTLDs that have already been delegated, it seems as
> though implementation of the former has a dependency on some form of time
> travel. I can't speak to the feasibility of changing delegation policy for
> new gTLD registry operators, but I suspect any change in their operational
> requirements here is at best impractical, and at worst likely to result in
> a partial mesh of lawsuits.
>

This is probably not the right forum for this discussion but I do wonder
why you think this is so?  Name collision issues have been changing the
processes and requirements of launching TLDs since the issue rose in
prominence.  Why couldn't any proposed changes take effect at some future
date and folks who are already in a process be permitted to finish with the
former rules (assuming of course this is what the community decides)?


> Specifying the use of a wildcard in a TLD zone (as you suggest as a
> possible mechanism) is bringing back all kinds of bad memories. A nod
> towards mail (with the MX reference) is better than the assumption that the
> only thing anybody ever looks up in the DNS is an address, but it's far
> from exhaustive.

What about SRV lookups by Active Directory clients, for example, or TXT
> lookups by systems receiving mail? What about all the internal uses of DNS
> we don't know about?


The SSAC report mentions these issues too.  These questions, in my mind,
are one of the fundamental problems with trial delegations in general.  It
is simply not possible to account for everything.  Ultimately, you can only
do what you can do and you just have to deal with whatever happens that you
didn't plan for when it happens.

You talk about A records; what about IPv6?
>

I'm less concerned about IPv6.  My sample size could be too small but it
seems to me that sites that have deployed IPv6 are better off technically
than IPv4 only.  If this problem exists at a site with IPv6 my perception
is that they will be better equipped to deal with it.

I'd be very interested in other opinions or evidence on this point.


> More generally, it's not clear to me that your proposed approach (wherever
> and however it is implemented) is going to offer much relief for people who
> might be afflicted by a collision between an internal-use name and a name
> in the global DNS namespace. Which particular damage scenarios do you think
> would be mitigated (or easier to diagnose) if this kind of idea was in
> place?
>

In my opinion, this is not about relief or mitigation.  Just like trial
delegations, this is about getting information to the folks that need it
the most, i.e., notification.  This is another fundamental problem with
trial delegations (and continued testing for collisions): you can't prove a
negative so you never know when you're done.

Don't get me wrong.  I'm not opposed to trial delegations or continued
testing.  What I'm opposed to is the lack of a deterministic process.  Name
collisions will happen and are therefore a risk.  We need to focus on
managing that risk and a key component of risk management is notification.

This proposal is an improvement on the trial delegations that have been
proposed so far by ICANN and SSAC.  The discussion here on the technical
issues to further improve this idea are even better, and I expect the JAS
folks will be considering them.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/7f9509f4/attachment.htm>