Subject: [DNSOP] Mitigation of name collisions

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 18 Sep 2016 15:03:46 -0700

On 18 Sep 2016, at 14:10, John Levine wrote:

>>> 4.2.4. Name Collision in the DNS ...
>
>> This study is from before the new gTLD program.  The assumption in 
>> the
>> report need to be tested against what actually happened in the round 
>> of
>> new gTLDs before it can be included as part of the fact basis for 
>> this
>> work.  We also need information on the degree of success that the
>> various mitigation strategies had in overcoming possible problems to
>> have a full picture of the problem as it has been shown in practice.
>
> At a meeting a couple of weeks ago, I believe that someone said that
> the junk traffic at the roots for each of .corp, .home and .mail still
> greatly exceeds all of the traffic for the new gTLDs.  So I think it's
> safe to say none of the mitigation strategies have worked.

There is a difference between "mitigation" with "prevention". Few of use 
thought that publicity about upcoming collisions would have cause more 
than a few folks to fix the problem before it hit them.

> The wildcard 127.0.53.53 and such are clever, but none of the domains
> that have been delegated had significant collision issues to start
> with so it's hard to argue they've been effective.

It is impossible to measure the effectiveness without knowing how many 
collision queries are just noise (queries that will cause no noticeable 
damage if they started coming back with results). In the case of 
mitigation through wildcard-to-localhost, it is safe to assume that many 
organizations did in fact mitigate; we simply can't tell how many or 
when.

--Paul Hoffman

(Disclaimer: I'm now on ICANN staff, but well before I was, I wrote 
"Guide to Name Collision Identification and Mitigation for IT 
Professionals" for ICANN.)

---

From: "John R Levine" <[email-masked]>
Date: 18 Sep 2016 18:21:23 -0400

> damage if they started coming back with results).

Agreed.  I don't see how to find that out in ways that are not hard to 
back out if it turns out the damage is as bad as we fear.

> In the case of mitigation through wildcard-to-localhost, it is safe to 
> assume that many organizations did in fact mitigate; we simply can't 
> tell how many or when.

How come?  I'm not denying it's possible, but I've never seen any evidence 
that there were collisions to mitigate.  Before the 127.0.53.53 approach, 
some TLDs tried reserving the names that showed up in DITL snapshots, and 
those names looked to me totally random, likely generated by something 
that was trying to see whether some piece of namespace was wildcarded.

R's,
John

PS:

> (Disclaimer: I'm now on ICANN staff, but well before I was, I wrote "Guide to 
> Name Collision Identification and Mitigation for IT Professionals" for 
> ICANN.)

A fine document for people who already realize they need to deal with 
collisions, not so much for people who don't realize they exist or assume 
they're someone else's problem.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 18 Sep 2016 19:01:00 -0700

On 18 Sep 2016, at 15:21, John R Levine wrote:

>> It is impossible to measure the effectiveness without knowing how 
>> many collision queries are just noise (queries that will cause no 
>> noticeable damage if they started coming back with results).
>

I do see that, but that's a discussion for a different time and place. 
(Unless this WG re-adopts corp/home/mail, of course.)

>
>> In the case of mitigation through wildcard-to-localhost, it is safe 
>> to assume that many organizations did in fact mitigate; we simply 
>> can't tell how many or when.
>
> How come?

Because a few of them told me they did.

> I'm not denying it's possible, but I've never seen any evidence that 
> there were collisions to mitigate.

You of all people should know that "people do dumb things with the DNS". 
:-)

> Before the 127.0.53.53 approach, some TLDs tried reserving the names 
> that showed up in DITL snapshots, and those names looked to me totally 
> random, likely generated by something that was trying to see whether 
> some piece of namespace was wildcarded.

As we saw at the collisions workshop 
(https://www.ietf.org/id/draft-thomas-namecollisions-workshop-report-05.txt), 
DITL data is poorly suited for following collisions because you can't 
tell how much is coming from organizational resolvers that are in front 
of a poorly-chosen name and how many are from upstream ISPs.

> collisions, not so much for people who don't realize they exist or 
> assume they're someone else's problem.

Correct. It has been helpful, though, at least to organizations seeing 
127.0.53.53.

--Paul Hoffman

---

From: william manning <[email-masked]>
Date: Mon, 19 Sep 2016 21:29:02 -0700

this bit of thread jumped out.

>> assume that many organizations did in fact mitigate; we simply can't tell
>> how many or when.
>>
>
> How come?
>

back in the early days of potentially confusing assignments/delegations,  I
was asked to stand up authoritative servers for the RFC 1918 space.   The
first iteration was just a wildcard to TXT.    Clients (early microsoft
clients in particular) panic'ed and flooded the links looking for an
authoritative answer.  Second iteration (some 15 minutes later) did the
wildcard to link-local.   Some 90 minutes later, Mockapetris, Postel, and
the university legal walked into the office and and asked (politley) to
take the servers offline.   Which was done.   The RFC 1918 space
authoritative DNS service was tweeked after it moved to ICANN,  Joe Abley
took on that role.   The traces still exist. DNS-OARC was not interested,
neither was SDSC, nor ICANN (at the time)...

On Sun, Sep 18, 2016 at 7:01 PM, Paul Hoffman <[email-masked]> wrote:

>>> assume that many organizations did in fact mitigate; we simply can't tell
>>> how many or when.
>>>
>>
>> How come?
>>
>
> I'm not denying it's possible, but I've never seen any evidence that there
>> were collisions to mitigate.
>>
>
> Before the 127.0.53.53 approach, some TLDs tried reserving the names that
>> showed up in DITL snapshots, and those names looked to me totally random,
>> likely generated by something that was trying to see whether some piece of
>> namespace was wildcarded.
>>
>
> As we saw at the collisions workshop (https://www.ietf.org/id/draft
> -thomas-namecollisions-workshop-report-05.txt), DITL data is poorly
> suited for following collisions because you can't tell how much is coming
> from organizational resolvers that are in front of a poorly-chosen name and
> how many are from upstream ISPs.
>
> (Disclaimer: I'm now on ICANN staff, but well before I was, I wrote "Guide
>>> to Name Collision Identification and Mitigation for IT Professionals" for
>>> ICANN.)
>>>
>>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>