Re: [DNSOP] Mitigation of name collisions

[Rubens Kuhl]

> 
>>  or if 
>> the name-servers serving the wildcard were required to collect and 
>> publish information and statistics. This would have allowed analysis 
>> of the effectiveness of the mitigations, etc. 
> 
> 
> This, however, is more interesting and should another round occur, I think 
> it'd make sense to do this in a staged fashion, first to ICANN name servers, 
> then to the registry's name servers.
> 
> Of course, IIRC, people were arguing that you shouldn't ask questions when 
> you aren't sure what you'll do with the answers... 

David,

Add to that starting doing controlled interruption as soon as next round reveal 
day, long before evaluation, contention set resolution and contract signing, 
and you will see lots of happy people in many sides of this problem. 


Rubens


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Rubens Kuhl]

> 
>>  or if 
>> the name-servers serving the wildcard were required to collect and 
>> publish information and statistics. This would have allowed analysis 
>> of the effectiveness of the mitigations, etc. 
> 
> 
> This, however, is more interesting and should another round occur, I think 
> it'd make sense to do this in a staged fashion, first to ICANN name servers, 
> then to the registry's name servers.
> 
> Of course, IIRC, people were arguing that you shouldn't ask questions when 
> you aren't sure what you'll do with the answers... 

David,

Add to that starting doing controlled interruption as soon as next round reveal 
day, long before evaluation, contention set resolution and contract signing, 
and you will see lots of happy people in many sides of this problem. 


Rubens


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[David Conrad]

Warren,

On October 3, 2016 at 12:33:12 PM, Warren Kumari (war...@kumari.net) wrote:
... and just for the record, much much more could have been determined 
(and users better warned / informed) if the address handed out was a 
server which displayed an error / links to more information[0],
I'm not particularly interested in beating the smudge on the ground that was 
the honey pot dead horse yet again. Here's an idea: if you can get Google 
lawyers to accept the full legal liability and privacy implications for running 
such a honey pot (regardless of how it is implemented and for what protocols), 
let me know and I'll argue that we should do an RFP to outsource the operation 
of such a honey pot in the next round. Until then, perhaps we can let the dead 
horse rest in peace?

 or if 
the name-servers serving the wildcard were required to collect and 
publish information and statistics. This would have allowed analysis 
of the effectiveness of the mitigations, etc. 

This, however, is more interesting and should another round occur, I think it'd 
make sense to do this in a staged fashion, first to ICANN name servers, then to 
the registry's name servers.

Of course, IIRC, people were arguing that you shouldn't ask questions when you 
aren't sure what you'll do with the answers... 

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Danny McPherson]

> 
> I realize that you, Warren, are virtuous and would not do anything bad with 
> all of the secrets people fling at your server, but given the reality of the 
> TLD ecosystem, how confident are you that nobody else running such a server 
> would?

Precisely why they ought to be notified of their vulnerability as soon as 
possible if the capability exists, no?  This was certainly the crux of the WPAD 
issue, for example.

-danny 


> 
> R's,
> John
> 
> ___
> 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

Re: [DNSOP] Mitigation of name collisions

[John R Levine]

Gee, I'd think you of all people would be aware that there's more to the
Internet than the web.


... Did you read the footnote?


Yup.  It sounds like a way to collect vast amounts of interesting 
information that companies had no idea they were leaking.  Not every 
connection comes from something with a user watching a screen.  I wonder 
how many ssh connections are live users rather than rsync cron joba.


I realize that you, Warren, are virtuous and would not do anything bad 
with all of the secrets people fling at your server, but given the reality 
of the TLD ecosystem, how confident are you that nobody else running 
such a server would?


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Warren Kumari]

On Monday, October 3, 2016, John R Levine  wrote:

> 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.

>>> ...
>>>
>>
> ... and just for the record, much much more could have been determined
>> (and users better warned / informed) if the address handed out was a
>> server which displayed an error / links to more information[0],
>>
>
> Gee, I'd think you of all people would be aware that there's more to the
> Internet than the web.


>
>
... Did you read the footnote?

W

>
>  A wildcard with a live IP in those domains would be a terrible idea for
> the same reason that *.com was.
>
> or if the name-servers serving the wildcard were required to collect and
>> publish information and statistics. This would have allowed analysis of the
>> effectiveness of the mitigations, etc.
>>
>
> That, on the other hand, would be a good idea.  Since all of the new TLDs
> use the same dozen back ends, I wonder if any of the back ends could be
> persuaded to release anonymized data.
>
> R's,
> John
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[John R Levine]

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.

...



... and just for the record, much much more could have been determined
(and users better warned / informed) if the address handed out was a
server which displayed an error / links to more information[0],


Gee, I'd think you of all people would be aware that there's more to the 
Internet than the web.  A wildcard with a live IP in those domains would 
be a terrible idea for the same reason that *.com was.


or if the name-servers serving the wildcard were required to collect and 
publish information and statistics. This would have allowed analysis of 
the effectiveness of the mitigations, etc.


That, on the other hand, would be a good idea.  Since all of the new TLDs 
use the same dozen back ends, I wonder if any of the back ends could be 
persuaded to release anonymized data.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Danny McPherson]

> On Oct 3, 2016, at 6:31 PM, Warren Kumari  wrote:
> 
> ... and just for the record, much much more could have been determined
> (and users better warned / informed) if the address handed out was a
> server which displayed an error / links to more information[0], or if
> the name-servers serving the wildcard were required to collect and
> publish information and statistics. This would have allowed analysis
> of the effectiveness of the mitigations, etc.
> 
> Yup, I'm beating a dead-horse here, but people keep rediscovering the topic.
> 
> W
> [0]: This could have a webserver which localized the page (based on IP
> / Accept-Language), a mailserver with a useful error, SSH / telnet
> banners, etc. I figured out ~20 protocols which allowed some sort of
> useful banner return. The logs could have been anonymized, or only
> statistics saved…

No surprise .. Warren and I still agree here!

Further, I still believe that enterprise network operators need safe haven name 
space (e.g., intuitively, perhaps, .corp, .home, and .mail, rather than the 
currently but [not assuredly] reserved .gnso, .icann, .iab, .rir, .ietf, and 
the like) if they don’t want to be tethered to the global DNS, for whatever 
reason.

Heck, then we could even allow internal names certificates again (in those name 
spaces, where appropriate) and not force leakage of internal system names via 
the likes of Certificate Transparency - since we just went through all that 
trouble to develop qname minimization et al.


-danny


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Warren Kumari]

On Sun, Sep 18, 2016 at 6:03 PM, Paul Hoffman  wrote:
> 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.

... and just for the record, much much more could have been determined
(and users better warned / informed) if the address handed out was a
server which displayed an error / links to more information[0], or if
the name-servers serving the wildcard were required to collect and
publish information and statistics. This would have allowed analysis
of the effectiveness of the mitigations, etc.

Yup, I'm beating a dead-horse here, but people keep rediscovering the topic.

W
[0]: This could have a webserver which localized the page (based on IP
/ Accept-Language), a mailserver with a useful error, SSH / telnet
banners, etc. I figured out ~20 protocols which allowed some sort of
useful banner return. The logs could have been anonymized, or only
statistics saved...

>
> --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.)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Keith Mitchell]

> william manning  Tue, 20 September 2016
> 04:29 UTC wrote:

> 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)...

>From an OARC point of view, we did some back-checking of our
institutional memory such as it is, and were unable to track down these
traces being offered, or by whom/at what point they were declined. Which
is not to say this didn't happen.

Anyway, on the basis that the volume of this historic trace data is
unlikely to be large by modern storage infrastructure standards, if the
offer for OARC to take on these traces and preserve and make them
available under our usual terms is still open, and there is community
interest for doing so, we'd be happy to.

Please Bill follow-up with me offline if you'd like to explore this.

Keith

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[william manning]

this bit of thread jumped out.

> 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?
>

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  wrote:

> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mitigation of name collisions

[Paul Hoffman]

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

Re: [DNSOP] Mitigation of name collisions

[John R Levine]

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.


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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop