>
>> 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
>
>> 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
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
>
> 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 thei
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 somethin
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 recor
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 / info
> 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
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
> 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
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
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 tha
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 d
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
14 matches
Mail list logo