On Friday, July 4, 2014, Warren Kumari <war...@kumari.net> wrote: > On Thu, Jul 3, 2014 at 6:04 PM, Tim Wicinski <tjw.i...@gmail.com > <javascript:;>> wrote: > > > > Mark > > > > Unbound has this feature, but its' a % of the TTL (oh they may of changed > > this). > > > > You may be also interested in this idea which was floated during IETF, > and > > not rejected, just a small sliver of useful customer base: > > > > http://tools.ietf.org/id/draft-wkumari-dnsop-hammer-00.txt > > ... and, almost exactly one year later, we are *finally* rev'ing that > document (I just edited it this afternoon, Suzanne is giving it the > once over as we speak, and we are planning on submitting in the next > hour (you know, just before the draft cutoff :-) - “I love deadlines. > I love the whooshing noise they make as they go by.” — Douglas Adams, > The Salmon of Doubt ) > > The new version mainly described the general concept, and that > OpenDNS, Unbound and BIND 10 do something like this. In a somewhat > contrived bit of writing, it also manages to keep the "Stop! Hammer > time!" references... > > ... and we managed to squeeze it in under the deadline. I did (of course) mean BIND 9.10 in the previous mail, and not BIND 10, which is a whole different kettle of fish. That'll teach me to write mail inna rush...
W > W > > > > > > > > > > On 7/3/14 5:06 PM, Mark Pettit wrote: > >> > >> Hi, folks. > >> > >> I have an issue with BIND cache timeouts, and I was hoping someone else > >> might have some idea how to fix this. > >> > >> Here's the situation: we have a large number of servers that do a huge > >> number of DNS lookups at the top of every minute. The TTL for the > >> records they're looking up is 3600. > >> > >> What we've noticed is that on a host with a recently-restarted copy of > >> BIND, we see huge spikes in DNS latency every 61 minutes. This makes > >> logical sense, given the behavior of the DNS lookups. > >> > >> What is more interesting is that on hosts that have been running BIND > >> for a very long time (on the order of months), the spikiness is not > >> visible. > >> > >> Our speculation is that over time, due to the interaction between the > >> 3600 TTL and the "once every minute" lookup behavior, cache misses > >> become randomly distributed throughout the hour, and don't cause the > >> spiky behavior that is observed initially. > >> > >> One of our ideas to resolve this is to randomize the TTLs in the zone > >> files, causing them to expire out of cache at different times, thus > >> forcing more-rapid distribution of cache misses across the hour. > >> > >> However, this would involve some massive edits to our zone files, and > >> isn't really ideal. > >> > >> What *would* be ideal would be if we could tell BIND to randomly expire > >> some small percentage of cached entries ahead of the actual TTL > >> expiration. This would serve the same purpose as assigning "random" TTLs > >> to the actual records in the zone files. > >> > >> Does BIND have a config option like this? Has anyone else ever > >> encountered this issue, and if so, how did you address it? > >> > >> Thanks for any advice, and I hope everyone has a fantastic Fourth of > >> July weekend. > >> > >> Mark Pettit > >> > >> > >> > >> _______________________________________________ > >> dns-operations mailing list > >> dns-operations@lists.dns-oarc.net <javascript:;> > >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations > >> dns-jobs mailing list > >> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > >> > > _______________________________________________ > > dns-operations mailing list > > dns-operations@lists.dns-oarc.net <javascript:;> > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > dns-jobs mailing list > > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
