Dlaczego Chromium nie buforuje DNS przez dłużej niż minutę?

Używam Chromium i mam problemy z brakiem buforowania DNS przez oczekiwany czas. Weź domenę example.com. Zgodnie z ustawieniami DNS ta domena powinna być buforowana przez kolejne 26151 sekund:

$ dig example.com

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

Jednak kiedy otwieram example.com w Chromium i otwieram chrome: // net-internals / # dns, wtedy IP zostaje zapomniane w ciągu minuty!

Dlaczego Chromium nie przestrzega TTL ustawienia DNS domeny? Jak zmusić go do buforowania danych DNS, dopóki nie wygasną?

Chromium / Chrome faktycznie nie buforuje żądań DNS dłużej niż minutę.

Co ciekawe, z błędów chromu - numer 164026 - TTL DNS nie jest honorowany od 21 kwietnia 2011 r

Jedyny bufor DNS w systemie znajduje się w chrome i nie honoruje TTL. Musimy naprawić chrome i / lub dodać pośrednią pamięć podręczną, która poprawnie obsługuje TTL.

Odpowiedź w bilecie z 4 grudnia 2012 r .:

HostCache zakłada obecnie TTL = 60 s dla wszystkich pozytywnych wyników. W przypadku asynchronicznego programu rozpoznawania nazw DNS planujemy użyć TTL = max (60s, server_reported_ttl), tj. Co najmniej 60s. Uzasadnieniem jest poprawa wydajności pamięci podręcznej. (Gdy CDN NS zapewnia TTL = 10-20 s, a pobranie wszystkich pod zasobów zajmuje 30 s +, często musimy ponownie zapytać o tę samą nazwę hosta podczas ładowania jednej strony).

Bilet zamknięty w dniu 10 października 2013 r., Ponieważ:

Chrome na CrOS korzysta z asynchronicznego programu rozpoznawania nazw DNS, który honoruje TTL = maks. (60s,> server_reported_ttl)

Zamykam to jako WontFix (przestarzałe / działa zgodnie z przeznaczeniem).

Jest to znany problem od lat; ich wewnętrzny resolver DNS ignoruje TTL rekordów DNS i buforuje żądania DNS tylko przez 1 minutę.

Użytkownicy żądają od lat funkcji zmiany tego domyślnego zachowania, a Google nigdy go nie utworzył.

W przeszłości można było wyłączyć wewnętrzny resolver DNS w chrome://flags, obecnie funkcjonalnie nie jest już ujawniony.

Podsumowując, jest to cecha, np. Robi to zgodnie z projektem.

(Początkowo napisałem, że nigdy nie można tego zmienić, co oczywiście nie jest prawdą. Naprawdę zdeterminowana osoba może albo zrekompilować Chromium, albo zhakować pliki binarne Chrome).

Tak więc, jako adenda: istnieje mnóstwo udokumentowanych dowodów, że inżynierowie Google nie zamierzają przestrzegać domyślnego TTL w otrzymanych odpowiedziach DNS w Chrome / ium.

Od negatywnego buforowania zapytań DNS (DNS NCACHE)

Podobnie jak w przypadku buforowania pozytywnych odpowiedzi, rozsądne jest, aby resolver ograniczył czas buforowania negatywnej odpowiedzi ...

Chociaż sugeruje się, że resolver może / powinien nałożyć maksymalny limit buforowanej odpowiedzi DNS, limit 1 minuty w Google Chrome może być zbyt niski.

PS Właściwie odkryłem odpowiedź na coś, co od lat mnie denerwuje podczas pobierania statystyk Chrome, aby odpowiedzieć na to pytanie: Chrome: żądania DNS z losowymi nazwami DNS: złośliwe oprogramowanie?

PPS Z poniższego kodu wynika, że ​​negatywne odpowiedzi nie są buforowane (TTL = 0).

From 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   }