Thank you for your answer, Roy.
Here follows my comments.
On 29/10/2012 12:54, Roy Arends wrote: I did not say that. I asked
DNSSEC does not defend against the Kaminsky hack?.
I thought it was some sort of rhetoric question. My apologies.
AFAIK, DNSSEC does not possess any revocation mechanism
On 29/10/2012 13:33, Paul Wouters wrote:
The kaminsky attack has nothing to do with revocation. DNSSEC solves the
kaminsky attack which relies on unsigned spoofable data.
I may be the only one worried about replayed signed data, after it is
removed from authoritative servers.
Let's take an
Florian Maury (pub-dnsop) writes:
Let's take an extreme example to illustrate:
[...]
Mallory wants to read Alice's emails. He manages to rent Bob AMX. He,
then, replays the old MX record set whose signature are not expired (the
signature is still valid for 2 months) to Charlie, whose
On Sun, 28 Oct 2012, bert hubert wrote:
It appears that source port randomization works.
Probably the only vulnerable servers are those behind NAT that derandomizes
the source port. But important servers are unlikely to suffer from network
address translation.
Which is everyone with a
Bert,
On Oct 27, 2012, at 10:55 PM, bert hubert bert.hub...@netherlabs.nl wrote:
Thus continuing the trend that all purported cache poisonings observed have
been registry hacks.
Looks that way, although it looks like this wasn't really a registry hack but
rather what happens when a domain
On Sun, Oct 28, 2012 at 02:22:04AM -0400, Paul Wouters wrote:
On Sun, 28 Oct 2012, bert hubert wrote:
It appears that source port randomization works.
Probably the only vulnerable servers are those behind NAT that derandomizes
the source port. But important servers are unlikely to suffer
On Sat, Oct 27, 2012 at 11:43:40PM -0700, David Conrad wrote:
It appears that source port randomization works.
Was there ever any doubt? The question wasn't (isn't?) whether source
Yes, people used the Kaminsky hack as a way to push DNSSEC.
So perhaps doubt was *instilled*.
making the
On Sun, Oct 28, 2012 at 02:22:04AM -0400,
Paul Wouters p...@cypherpunks.ca wrote
a message of 20 lines which said:
You missed the announcement of the 450 million downloads by iOS6 of
the IANA root key?
Poisoning the cache of an one-user iPhone is fun but less useful than
poisoning the
On 2012-10-28 5:55 AM, bert hubert wrote:
... the trend that all purported cache poisonings observed have
been registry hacks.
It appears that source port randomization works.
it doesn't, though.
Probably the only vulnerable servers are those behind NAT that derandomizes
the source port.
* Tim Huffman:
Any ideas what I can do to help my customer? This is the first time
we've ever had something like this...
Have you checked if other domains you host are affected in a similar
way?
___
dns-operations mailing list
David Conrad wrote:
Yep, assuming it is cache poisoning. I'm trying to think of
alternative explanations, but given reports (e.g., from Frank) that
the issue is affecting other resolvers, it's hard to see other
answers. A bit odd, given ben.edu isn't very high up on the Alexa (et
al) list...
Robert,
On Oct 27, 2012, at 1:37 PM, Robert Edmonds edmo...@isc.org wrote:
i don't think it's cache poisoning. note that there are two out-of-zone
nameservers for ben.edu:
...
and that bobbroadband.com was updated recently,
Good catch! Makes sense. I checked the history on ben.edu but
: Friday, October 26, 2012 11:14 PM
To: Tim Huffman
Cc: dns-operations@lists.dns-oarc.net
Subject: Re: [dns-operations] ATT DNS Cache Poisoning?
On 2012-10-27 at 03:36 +, Tim Huffman wrote:
We are the primary DNS servers for the ben.edu domain. We seem to be
having an issue with an ATT server
On 2012-10-27 at 04:23 +, Tim Huffman wrote:
Any ideas what I can do to help my customer? This is the first time
we've ever had something like this...
Continue trying to reach ATT and the other operators of DNS servers in
that link?
You can look at deploying DNSSEC for their domain, so
14 matches
Mail list logo
