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).
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.
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.
(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.
Correct. It has been helpful, though, at least to organizations seeing
127.0.53.53.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
