It's really more of an OS tuning question, isn't it?
The usage pattern of a BIND instance is:
a) not much writing of master zone files or journal files unless Dynamic
Update is enabled and the frequency of updates is relatively high,
b) not much writing of slave/stub zone files or journal files,
* Marc Lampo:
> I agree for the consequence of those "cache misses".
> But doesnot that mean that RFC4035 needs amended to state :
> "remove atomic entry if *all* its RRSIGs get invalid"
> (because now it states : any = "at least one")
It's about the TTL on the RRSIG RRset, not the signature val
I agree for the consequence of those "cache misses".
But doesnot that mean that RFC4035 needs amended to state :
"remove atomic entry if *all* its RRSIGs get invalid"
(because now it states : any = "at least one")
And it implicitly confirms that these statements in the RF
I agree for the consequence of those "cache misses".
But doesnot that mean that RFC4035 needs amended to state :
"remove atomic entry if *all* its RRSIGs get invalid"
(because now it states : any = "at least one")
And it implicitly confirms that these statements in the RFC
do apply to expired RRS
* Marc Lampo:
> If anybody disagrees with this interpretation,
> and interprets it like expired RRSIG's *must* be deleted from a cache,
> would you be so kind to share the reference(s) any RFC's on which you base
> your interpretation.
You need to cache expired RRSIGs for some time, or else ever
Hello group,
and my best whishes for a healthy and challenging 2011 !
Allow me to return to the issue of caching expired RRSIG's.
In RFC4035, DNSSEC protocol, in section 4 : Resolving
4.5. Response Caching
A security-aware resolver SHOULD cache each response as a single
atomic entry co
6 matches
Mail list logo
