En lisant les échanges, c'est exactement le type de solution qui me traversait l'esprit pour compenser le faible nombre de requêtes locales et donc la forte latence à la 1ère requête.
En revanche, il ne me semble pas avoir vu de mécanisme de purge du cache ; j'ai loupé quelque chose ? Ça ne génèrerait pas un cache démentiel qui aurait la mauvaise idée de conserver toutes les entrées requêtées depuis l'uptime ? Cordialement, Cédric Houzé. Cordialement, Cédric Houzé. 06 72 20 31 60 Le 19 nov. 2016 23:41, "Paul Rolland (ポール・ロラン)" <rol+fr...@witbe.net> a écrit : > Bonjour, > > On Sat, 19 Nov 2016 22:00:22 +0100 > Jérémie Bouillon <m...@dorem.info> wrote: > > > Le 19/11/2016 à 12:17, Pierre Colombier a écrit : > > > seul défaut : Il faut admettre que le temps de résolution est un peu > > > plus long sur les domaines qui ont des TTL court car il y a moins de > > > chances qu'un autre utilisateur l'ai déjà mis en cache. > > > > Question probablement stupide, mais personne n'a essayé de mettre une > > liste des disons 300 plus gros sites qui ont justement des TTL trop > > courts, avec un ping en cron de 1 ou 5 minutes depuis la machine > > resolver ? Ça ne doit pas prendre grand chose en ressources, et sur ces > > sites en tout cas résoudre le problème de délai, non ? > > Et pourquoi pas ca : > https://deepthought.isc.org/article/AA-01122/0/Early- > refresh-of-cache-records-cache-prefetch-in-BIND-9.10.html > > Paul > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
