Mengapa Chromium tidak melakukan cache DNS selama lebih dari satu menit?

Saya menggunakan Chromium dan memiliki masalah dengan DNS yang tidak di-cache untuk waktu yang saya harapkan. Ambil domain example.com. Menurut pengaturan DNS, domain ini harus di-cache selama 26151 detik:

$ dig example.com

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

Namun, ketika saya membuka example.com di Chromium dan saya membuka chrome: // net-internal / # dns maka IP akan dilupakan dalam satu menit!

Mengapa Chromium tidak mematuhi TTL pengaturan DNS domain? Bagaimana saya bisa memaksanya untuk menyimpan data DNS sampai mereka kedaluwarsa?

Chromium / Chrome memang tidak men-cache permintaan DNS lebih dari satu menit.

Cukup menarik, dari bug-chromium - Edisi 164026 - DNS TTL tidak dihormati mulai 21 April 2011

Satu-satunya cache DNS di sistem dalam chrome dan tidak menghormati TTL. Kita perlu memperbaiki chrome dan / atau menambahkan cache perantara yang menangani TTL dengan benar.

Jawab di tiket 4 Desember 2012:

HostCache saat ini mengasumsikan TTL = 60 untuk semua hasil positif. Dengan resolver DNS asinkron, kami berencana untuk menggunakan TTL = maks (60-an, server_reported_ttl), yaitu setidaknya 60-an. Alasannya adalah untuk meningkatkan kinerja cache. (Ketika CDN NS memberikan TTL = 10-20s, dan butuh 30s + untuk mengambil semua sub-sumber, kami sering harus meminta kembali nama host yang sama selama satu halaman memuat.)

Tiket ditutup pada 10 Oktober 2013 karena:

Chrome on CrOS menggunakan resolver DNS asinkron yang menghormati TTL = maks (60-an,> server_reported_ttl)

Saya menutup ini sebagai WontFix (usang / berfungsi sebagaimana dimaksud).

Ini telah menjadi masalah yang diketahui selama bertahun-tahun; resolver DNS internal mereka mengabaikan TTL dari catatan DNS, dan hanya cache permintaan DNS selama 1 menit.

Pengguna telah meminta selama bertahun-tahun, fitur untuk mengubah perilaku default itu, dan Google tidak pernah membuatnya.

Di masa lalu, Anda dapat menonaktifkan resolver DNS internal chrome://flags, saat ini yang secara fungsional tidak terekspos lagi.

Jadi, menyimpulkannya, itu adalah fitur, misalnya ia melakukannya dengan desain.

(Awalnya saya menulis itu tidak pernah bisa diubah, yang jelas tidak benar. Orang yang benar-benar teguh dapat mengkompilasi ulang Chromium atau meretas binari Chrome.).

Jadi, sebagai adenda: ada banyak bukti yang terdokumentasi. Insinyur Google tidak bermaksud untuk menghormati TTL default dalam jawaban DNS yang diterima di Chrome / ium.

Dari Caching Negatif atas Pertanyaan DNS (DNS NCACHE)

Seperti halnya dengan caching respons positif, masuk akal bagi seorang resolver untuk membatasi berapa lama akan menyimpan respons negatif ...

Meskipun tersirat, resolver dapat / harus memberlakukan batas maksimum pada caching jawaban DNS, batas 1 menit di Google Chrome mungkin terlalu rendah.

PS Saya benar-benar menemukan jawaban untuk sesuatu yang telah mengganggu saya selama bertahun-tahun sambil mengambil statistik Chrome untuk menjawab pertanyaan ini: Chrome: Permintaan DNS dengan nama DNS acak: malware?

PPS Dari kode di bawah, tampak jawaban negatif tidak di-cache (TTL = 0).

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