-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 07/03/2013 11:56 PM, Warren Kumari wrote:
My question earlier still stands: does Unbound do what HAMMER
says (waits for a request before refreshing the cache) or
does it just refresh the cache automatically? The Unbound doc
is unclear (at least to me).
Yes, it waits for a request before refreshing the cache. The request
is the excuse to bother the authority server, since it could pretend
the entry had fallen out of the cache. And also the request indicates
a continued interest (the item is still popular). It was also simpler
to implement :-)
So, prefetch also prefetches fairly impopular names, that have about
10 queries per TTL. And one query hits the 10% last of the TTL. For
a TTL of 3600, getting about 10 queries in 3600 seconds would
statistically make you hit one query in the last 10% (a little) often.
And that is one query per 360 seconds, which is fairly impopular, but
it is prefetched.
Those are pictures. Source code, or developer assurance, or it
didn't happen ( to badly bastardize a phrase that the kids these
days use ).
Yes I wrote the code and say so. (Not sure how that is better than
reading the source). Results, anecdotally, are very modest. It does
remove latency spikes for popular names.
It *appears* to me from looking at the source that Unbound triggers
upon an incoming query (basically what HAMMER suggests). I should
note that this is the first time I have looked at the Unbound
source, and so it is entirely possible that I'm missing something.
Yes, it trigger upon an incoming query.
There is also a PREFETCH_EXPIRY_ADD which I don't really
understand:
/** * seconds to add to prefetch leeway. This is a TTL that
expires old rrsets * earlier than they should in order to put the
new update into the cache. * This additional value is to make sure
that if not all TTLs are equal in * the message to be updated(and
replaced), that rrsets with up to this much * extra TTL are also
replaced. This means that the resulting new message * will have
(most likely) this TTL at least, avoiding very small 'split *
second' TTLs due to operators choosing relative primes for TTLs (or
so). * Also has to be at least one to break ties (and overwrite
cached entry). */ #define PREFETCH_EXPIRY_ADD 60
I must admit that I'm somewhat shaky on much of the above, it would
be great if someone who is more familiar with the architecture /
code could comment/
Prefetch happens before the TTL expires, x seconds before. You can
determine x in many different ways, a fixed value works for very
highly popular names (i.e. draft submitter's employer), but for less
popular ones (i.e. my employer :-) ), prefetch can also work but needs
a bigger value, that is why I chose a fraction instead of absolute
value. Unbound uses x + 60 to replace 'old' RRsets when the new reply
comes in. This x+60 is subtracted from the TTL in the cache for
RRsets to determine if they are 'old' (with respect to the reply for
this prefetch). Because if it used exactly x, then the cache could
contain a remaining cache TTL x+1 for another RRset that forms up the
reply from cache that we would use for further queries. So we could
only answer for 1 second extra because we refused to update some RRs
that make up the response (but we updated the RR that was about to
expire). The value 60 is one that I picked with a similar idea as
when you talked about tilting at the windmills of small TTLs, but it
does not actually prevent the zone operator from choosing small TTLs,
it stops the hammer system from generating such small TTLs in the
cache from the larger TTLs that the authority system sends. The
defensive code about NS records you refer to is to make sure that this
system can handle a zone operator change without 'sticking' to the old
operator; e.g. 'if x+60 remaining cache TTL of NS RRset' then we
must go up to the parent operator, even though the child NS has not
expired yet.
Aside, I agree that prefetching before the TTL expires is overly
aggressive. But lengthening the TTL is worse (for DNSSEC rollovers
TTLs MUST expire, or the signatures become bogus).
Best regards,
Wouter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR1TFiAAoJEJ9vHC1+BF+NcuUP/1u6cB9LVEwoEHmucXoPE8Tt
z5frpV0xbfn6BaR0dvilorOHFr3KUe7HLa9ZRYHSaTDGqsYGqwmQC8HPx55r3sPn
9znMMxvAuX46BaAiLA1+7BEjKe96ubRkGZT6Lgt7C0UYcZfICG2U+CHOUVlPUJhU
pBDRq+o0fwhrP4Wx9L8aGtQwy+cFoxMi1sgQNSwji3QXZjzw+5ioV43CGx8HnAFM
09triotHJtD/weHWbk5RksQ9Fh0ncWXXFwiIPbKFwAKs28UDqP+fCWBwG5CeooNM
ruxuHRuJ7TEpWmPpB0WZfiCS6eIkGxr1ZaH0YKzni1+EC9qkpw7ziaUo19svZEEU
QxSWKOfBXOgWbJQvFj9BBKmKojv7ShVfzpe20czmsPdXuZsVwqWfOPeVtuV7lqJQ
6SP38LZvBE9qs4rZiXvvROYZyU3yqtyhp9i5K2aMncR64gsAtWCScR1diJWPLpWP
P55mHEmGaeu4xUsrvu49JMihDdxgSZYmZM4HdcUlShlzKYYOTuqKRh8C5Kzk7Ybq
FK5OOSyc4r8+kSRAmPtzj4pNf1cR/Te1/MR5o8yc8ZAVIjJvATGbKJEk5qq4jxrK
