On Mon, 18 Aug 2008, Andrew Sullivan wrote:
avoid susceptibility to DoS." Or something like that. After all,
resource-exhaustion attacks are also possible against DNSSEC-oblivious
systems. DNSSEC does open a new line of such attack, and one needs to
provision for it. No?
A factor of 100 is
On Mon, Aug 18, 2008 at 01:56:09PM -0400, Dean Anderson wrote:
> DNSSEC caches that verify are subject to a crypto-overload attack by
> large numbers of queries.
Surely another way to express the same thing is, "DNSSEC-enabled
servers and caching recursors require many more resources in order to
On Mon, 18 Aug 2008, Paul Hoffman wrote:
> At 1:27 PM +0100 8/18/08, Jim Reid wrote:
> >The fact is DNSSEC is the *only* game in town for preventing cache poisoning.
>
> Note the subject of this particular thread. A more carefully-worded
> sentence would be "The fact is DNSSEC is the *only* game
On Mon, 18 Aug 2008, Jim Reid wrote:
> On 18 Aug 2008, at 05:11, Dean Anderson wrote:
>
> > Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
> > for DOS, but of course remain susceptible to poisoning even if the
> > stub resolver and the authority server both implement DNSSEC.
At 1:27 PM +0100 8/18/08, Jim Reid wrote:
The fact is DNSSEC is the *only* game in town for preventing cache poisoning.
Note the subject of this particular thread. A more carefully-worded
sentence would be "The fact is DNSSEC is the *only* game in town for
completely preventing cache poisonin
On 18 Aug 2008, at 05:11, Dean Anderson wrote:
Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
for
DOS, but of course remain susceptible to poisoning even if the stub
resolver and the authority server both implement DNSSEC.
Kindly explain how is this any different from w
Mark Andrews wrote:
>>In theory, yes, in practice, only those who supply large RRs
>>requiring TCP (or EDNS) will suffer.
> Well we are there now. Lots of answers require EDNS and/or
> TCP and the DNS resolution has not fallen over.
OK. So, those who supply large RRs requiring TCP
On Mon, 18 Aug 2008, Jim Reid wrote:
> And why would these caching servers be signing anything? It's the
> master server that signs the zone.
I never said otherwise.
Ok, I agree that totally DNSSEC-oblivious servers won't be a problem for
DOS, but of course remain susceptible to poisoning even
> Mark Andrews wrote:
>
> > RFC 4035 requires the upstream cache to be RFC 4035 aware.
>
> Thanks. As examplified by assumptions of RFC3225, that's a so
> unrealistic requirement that no further discussion on DNSSEC
> is necessary. PERIOD.
Given just about anyone can configure a val
Mark Andrews wrote:
> RFC 4035 requires the upstream cache to be RFC 4035 aware.
Thanks. As examplified by assumptions of RFC3225, that's a so
unrealistic requirement that no further discussion on DNSSEC
is necessary. PERIOD.
> And lack of TCP support will also break PODS responses a
On Sun, Aug 17, 2008 at 8:23 PM, Jim Reid <[EMAIL PROTECTED]> wrote:
> I suspect you're talking about the absurdly hypothetical scenario where
> someone gets a non DNSSEC-aware resolving server to lookup some RRSIG, then
> the zone is resigned, then they ask that server for the QTYPE that the
> a
> Jim Reid wrote:
>
> > I suspect you're talking about the absurdly hypothetical scenario where
> > someone gets a non DNSSEC-aware resolving server to lookup some RRSIG,
>
> Suppose you are using DNSSEC-unaware caching forwarder shared by
> others including those who are using PODS, which i
Jim Reid wrote:
> I suspect you're talking about the absurdly hypothetical scenario where
> someone gets a non DNSSEC-aware resolving server to lookup some RRSIG,
Suppose you are using DNSSEC-unaware caching forwarder shared by
others including those who are using PODS, which is often the cas
13 matches
Mail list logo
