[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Olafur Gudmundsson <ogud@ogud.com>
Cc: Miek Gieben <miekg@nlnetlabs.nl>, Simon Josefsson <jas@extundo.com>, dnssec@cafax.se
From: Miek Gieben <miekg@nlnetlabs.nl>
Date: Wed, 4 Jul 2001 14:12:28 +0200
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20010703170058.02557ec0@localhost>; from ogud@ogud.com on Tue, Jul 03, 2001 at 05:11:07PM -0400
Sender: owner-dnssec@cafax.se
User-Agent: Mutt/1.2.5i
User-Agent: Mutt/Linux
Subject: Re: ttl problems in DNSSEC

[On 03 Jul, 2001, Olafur Gudmundsson wrote in " Re: ttl problems in DNSSEC "]
> At 10:41 AM 6/29/2001, Miek Gieben wrote:
> 
> > > [1]: perhaps the resolver is able to detect this situation by
> > > comparing the key tag field on S++2(A) with K++1, and then try get
> > > more recent data.
> >then you propose that if data is BAD an extra query for the key most be
> >done? I'm afraid this will yield too many extra queries...
> 
> Not a problem this will only happen once in a long while, thus when this
> happens extra query is fine.
so you are saying if there is bad data it is okay to requery for stuff
you need? (Another key for instance)

I think it is pretty easy for an attacker to fake bad data and thus
generate a huge amount of extra queries. Those queries must alwyas be
validated (as bad data isn't cached) thus generating an extra load on
the nameserver.

(is this the old DNSSEC doesn't protect you against DOS attacks? (but
makes them very easy to do))

> The real problem here is that K++1 was removed before data signed with it
> expired from caches, this MUST only be done in emergency.
> In most cases K++1 should remain in the keyset long enough for zone signed
> by K++2 to propagate to slaves and then time out in caches.
I agree, a statement along those lines will be put in the BCP,

grtz Miek
NLnet Labs

Home | Date list | Subject list