Pourquoi Chromium ne cache-t-il pas DNS pendant plus d'une minute?

J'utilise Chromium et j'ai des problèmes avec le DNS qui n'est pas mis en cache pour le temps que j'attendrais. Prenez le domaine example.com. Selon les paramètres DNS, ce domaine doit être mis en cache pendant 26151 secondes supplémentaires:

$ dig example.com

;; ANSWER SECTION:
example.com.        26151   IN  A   93.184.216.34

Cependant, lorsque j'ouvre example.com dans Chromium et que j'ouvre chrome: // net-internals / # dns, l'IP est oubliée en une minute!

Pourquoi Chromium n'adhère-t-il pas au TTL du paramètre DNS du domaine? Comment puis-je le forcer à mettre en cache les données DNS jusqu'à leur expiration?

Chromium / Chrome ne met pas en cache les requêtes DNS plus d'une minute.

Chose intéressante, de bugs-chrome - Numéro 164026 - DNS TTL non honoré à partir du 21 avril 2011

Le seul cache DNS du système est en chrome et il n'honore pas TTL. Nous devons soit corriger le chrome et / ou ajouter un cache intermédiaire qui gère correctement TTL.

Réponse dans le ticket du 4 décembre 2012:

Le HostCache suppose actuellement TTL = 60s pour tous les résultats positifs. Avec le résolveur DNS asynchrone, nous prévoyons d'utiliser TTL = max (60s, server_reported_ttl), c'est-à-dire au moins 60s. La raison d'être est d'améliorer les performances du cache. (Lorsqu'un CDN NS fournit TTL = 10-20s, et qu'il faut 30s + pour récupérer toutes les sous-ressources, nous devons souvent ré-interroger le même nom d'hôte lors d'un chargement de page.)

Billet fermé le 10 octobre 2013 pour:

Chrome sur CrOS utilise un résolveur DNS asynchrone qui honore TTL = max (60s,> server_reported_ttl)

Je ferme ceci en tant que WontFix (obsolète / fonctionne comme prévu).

C'est un problème connu depuis des années; leur résolveur DNS interne ignore le TTL des enregistrements DNS et ne met en cache les demandes DNS que pendant 1 minute.

Les utilisateurs demandent depuis des années une fonctionnalité pour modifier ce comportement par défaut, et Google n'en a jamais créé.

Dans le passé, vous pouviez désactiver le résolveur DNS interne chrome://flags, qui de nos jours n'est plus fonctionnel.

Donc, pour résumer, c'est une fonctionnalité, par exemple, il le fait par conception.

(J'ai initialement écrit que cela ne pourrait jamais être changé, ce qui n'est évidemment pas vrai. Une personne vraiment déterminée peut soit recompiler Chromium, soit pirater des binaires Chrome.).

Donc, à titre d'adenda: il existe de nombreuses preuves documentées que les ingénieurs de Google n'ont pas l'intention de respecter le TTL par défaut dans les réponses DNS reçues dans Chrome / ium.

De la mise en cache négative des requêtes DNS (DNS NCACHE)

Comme pour la mise en cache des réponses positives, il est judicieux pour un résolveur de limiter la durée de mise en cache d'une réponse négative ...

Bien qu'il soit implicite qu'un résolveur puisse / devrait imposer une limite maximale à la mise en cache de la réponse DNS, la limite de 1 minute sur Google Chrome peut être trop basse.

PS J'ai en fait découvert la réponse à quelque chose qui me dérange depuis des années lors de la récupération des statistiques de Chrome pour répondre à cette question: Chrome: requêtes DNS avec des noms DNS aléatoires: malware?

PPS D'après le code ci-dessous, il est évident que les réponses négatives ne sont pas mises en cache (TTL = 0).

Depuis https://chromium.googlesource.com/chromium/src/net/dns/host_resolver_impl.cc

  99 // Default TTL for successful resolutions with ProcTask.
 100 const unsigned kCacheEntryTTLSeconds = 60;
 101 
 102 // Default TTL for unsuccessful resolutions with ProcTask.
 103 const unsigned kNegativeCacheEntryTTLSeconds = 0;
 104 
 105 // Minimum TTL for successful resolutions with DnsTask.
 106 const unsigned kMinimumTTLSeconds = kCacheEntryTTLSeconds;

1518   // Called by ProcTask when it completes.
1519   void OnProcTaskComplete(base::TimeTicks start_time,
1520                           int net_error,
1521                           const AddressList& addr_list) {
1522     DCHECK(is_proc_running());
1523 
1524     if (dns_task_error_ != OK) {
1525       base::TimeDelta duration = base::TimeTicks::Now() - start_time;
1526       if (net_error == OK) {
1527         UMA_HISTOGRAM_LONG_TIMES_100("AsyncDNS.FallbackSuccess", duration);
1528         if ((dns_task_error_ == ERR_NAME_NOT_RESOLVED) &&
1529             ResemblesNetBIOSName(key_.hostname)) {
1530           UmaAsyncDnsResolveStatus(RESOLVE_STATUS_SUSPECT_NETBIOS);
1531         } else {
1532           UmaAsyncDnsResolveStatus(RESOLVE_STATUS_PROC_SUCCESS);
1533         }
1534         base::UmaHistogramSparse("Net.DNS.DnsTask.Errors",
1535                                  std::abs(dns_task_error_));
1536         resolver_->OnDnsTaskResolve(dns_task_error_);
1537       } else {
1538         UMA_HISTOGRAM_LONG_TIMES_100("AsyncDNS.FallbackFail", duration);
1539         UmaAsyncDnsResolveStatus(RESOLVE_STATUS_FAIL);
1540       }
1541     }
1542 
1543     if (ContainsIcannNameCollisionIp(addr_list))
1544       net_error = ERR_ICANN_NAME_COLLISION;
1545 
1546     base::TimeDelta ttl =
                                              # always  0 seconds
1547         base::TimeDelta::FromSeconds(kNegativeCacheEntryTTLSeconds);
1548     if (net_error == OK)
                                              # always 60 seconds 
1549       ttl = base::TimeDelta::FromSeconds(kCacheEntryTTLSeconds);  
1550 
1551     // Source unknown because the system resolver could have gotten it from a
1552     // hosts file, its own cache, a DNS lookup or somewhere else.
1553     // Don't store the |ttl| in cache since it's not obtained from the server.
1554     CompleteRequests(
1555         MakeCacheEntry(net_error, addr_list, HostCache::Entry::SOURCE_UNKNOWN),
1556         ttl);
1557   }