-----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 OukryH5g15wLAwJkC7M82fW4ua5PECwceeTkwAd+XETo/GZ4XPzZLBv9A8McWzF9 nnGDcxbx9rija3NTMv6A =8l0m -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
