Pengantar: penyebab dan mitigasi latensi DNS
Saat halaman web menjadi lebih kompleks, mereferensikan resource dari banyak domain, pencarian DNS dapat menjadi bottleneck yang signifikan dalam pengalaman penjelajahan. Setiap kali klien perlu membuat kueri DNS resolver melalui jaringan, latensi yang diperkenalkan bisa menjadi signifikan, bergantung pada kedekatan dan jumlah server nama yang harus dikueri oleh resolver (lebih dari 2 jarang terjadi, tetapi hal ini bisa terjadi). Misalnya, screenshot berikut menunjukkan waktu yang dilaporkan oleh alat pengukuran performa web Page Speed. Setiap batang mewakili resource yang dirujuk dari halaman; segmen hitam menunjukkan pencarian DNS. Di halaman ini, 13 pencarian dilakukan dalam 11 detik pertama saat halaman dimuat. Meskipun beberapa pencarian dilakukan secara paralel, screenshot menunjukkan bahwa 5 waktu pencarian serial diperlukan, yang mencakup beberapa detik dari total waktu pemuatan halaman 11 detik.
Ada dua komponen untuk latensi DNS:
- Latensi antara klien (pengguna) dan server penyelesaian DNS. Dalam kebanyakan kasus, hal ini sebagian besar disebabkan oleh kendala waktu round-trip (RTT) yang biasa dalam sistem jaringan: jarak geografis antara mesin klien dan server; kemacetan jaringan; kehilangan paket dan penundaan pengiriman ulang yang lama (rata-rata satu detik); server yang kelebihan beban, serangan denial-of-service, dan seterusnya.
- Latensi antara server penyelesaian dan server nama lainnya.
Sumber latensi ini terutama disebabkan oleh faktor-faktor berikut:
- Cache tidak ditemukan. Jika respons tidak dapat disalurkan dari cache resolver, tetapi memerlukan kueri server nama lainnya secara rekursif, latensi jaringan yang ditambahkan dapat diperhitungkan, terutama jika server otoritatif berada di lokasi yang berjarak jauh.
- Kurang penyediaan. Jika DNS resolver kelebihan beban, DNS harus mengantrekan permintaan dan respons resolusi DNS, dan dapat mulai melepas dan mengirim ulang paket.
- Traffic berbahaya. Meskipun layanan DNS disediakan secara berlebihan, traffic DoS dapat menempatkan beban yang tidak semestinya pada server. Demikian pula, serangan bergaya Kaminsky dapat melibatkan Flood resolver dengan kueri yang dijamin untuk mengabaikan cache dan memerlukan permintaan keluar untuk mendapatkan resolusi.
Kami yakin bahwa faktor cache tidak ditemukan adalah penyebab latensi DNS yang paling dominan, dan kami akan membahasnya lebih lanjut di bawah.
Cache tidak ditemukan
Meskipun resolver memiliki resource lokal yang melimpah, penundaan mendasar yang terkait dengan berbicara dengan server nama jarak jauh sulit dihindari. Dengan kata lain, dengan asumsi resolver disediakan cukup baik sehingga hit cache tidak memakan waktu di sisi server, cache yang tidak ditemukan tetap sangat mahal dalam hal latensi. Untuk menangani kesalahan, resolver harus berbicara dengan setidaknya satu, tetapi sering kali dua atau lebih server nama eksternal. Saat mengoperasikan web crawler Googlebot, kami mengamati waktu resolusi rata-rata 130 milidetik untuk server nama yang merespons. Namun, 4-6% permintaan secara penuh hanya kehabisan waktu, karena paket UDP hilang dan server tidak dapat dijangkau. Jika kita memperhitungkan kegagalan seperti kehilangan paket, server nama mati, error konfigurasi DNS, dll., rata-rata waktu resolusi end-to-end sebenarnya adalah 300-400 milidetik. Namun, terdapat varian yang tinggi dan longtail.
Meskipun tingkat kehilangan cache dapat bervariasi di antara server DNS, cache yang tidak ditemukan pada dasarnya sulit dihindari karena alasan berikut:
- Pertumbuhan dan ukuran internet. Sederhananya, seiring dengan berkembangnya Internet, baik melalui penambahan pengguna baru maupun situs baru, sebagian besar konten merupakan kepentingan marginal. Meskipun beberapa situs (dan akibatnya nama DNS) sangat populer, sebagian besar hanya menarik bagi segelintir pengguna dan jarang diakses; sehingga sebagian besar permintaan mengakibatkan cache tidak ditemukan.
- Nilai time to live (TTL) yang rendah. Kecenderungan terhadap nilai TTL DNS yang lebih rendah berarti bahwa resolusi memerlukan lebih banyak pencarian.
- Isolasi cache. Server DNS biasanya di-deploy di belakang load balancer yang menetapkan kueri ke komputer yang berbeda secara acak. Hal ini menyebabkan setiap server mempertahankan cache terpisah, bukan dapat menggunakan kembali resolusi yang disimpan dalam cache dari kumpulan bersama.
Mitigasi
Di Google Public DNS, kami telah menerapkan beberapa pendekatan untuk mempercepat waktu pencarian DNS. Beberapa pendekatan ini cukup standar; yang lainnya bersifat eksperimental:
- Menyediakan server secara memadai untuk menangani beban dari traffic klien, termasuk traffic berbahaya.
- Mencegah serangan DoS dan amplifikasi. Meskipun hal ini sebagian besar merupakan masalah keamanan, dan memengaruhi resolver tertutup lebih sedikit daripada yang terbuka, mencegah serangan DoS juga memiliki manfaat untuk performa dengan menghilangkan beban traffic tambahan yang ditempatkan pada server DNS. Untuk mengetahui informasi tentang pendekatan yang kami gunakan untuk meminimalkan peluang serangan, baca halaman tentang manfaat keamanan.
- Load balancing untuk penyimpanan cache bersama guna meningkatkan rasio hit cache gabungan di seluruh cluster penayangan.
- Menyediakan cakupan global agar mudah dijangkau oleh semua pengguna.
Menyediakan cluster penyajian secara memadai
DNS resolver harus melakukan operasi yang lebih mahal daripada server nama otoritatif, karena banyak respons tidak dapat disalurkan dari memori; sebagai gantinya, respons tersebut memerlukan komunikasi dengan server nama lain sehingga memerlukan banyak input/output jaringan. Selain itu, open resolver sangat rentan terhadap upaya cache poisoning, yang meningkatkan tingkat kehilangan cache (serangan tersebut secara khusus mengirim permintaan untuk nama palsu yang tidak dapat diselesaikan dari cache), dan serangan DoS, yang menambah beban traffic. Jika resolver tidak disediakan secara memadai dan tidak dapat mengimbangi beban, hal ini dapat berdampak sangat negatif pada performa. Paket dihapus dan perlu ditransmisikan ulang, permintaan server nama harus diantrekan, dan seterusnya. Semua faktor ini menambah penundaan.
Oleh karena itu, penting bagi DNS resolver untuk disediakan untuk input/output bervolume tinggi. Hal ini termasuk penanganan kemungkinan serangan DDoS. Satu-satunya solusi yang efektif adalah menyediakan secara berlebihan di banyak komputer. Namun, pada saat yang sama, penting untuk tidak mengurangi rasio cache ditemukan saat menambahkan mesin. Hal ini memerlukan penerapan kebijakan load balancing yang efektif, yang akan kita bahas di bawah.
Load balancing untuk penyimpanan cache bersama
Menskalakan infrastruktur resolver dengan menambahkan mesin sebenarnya dapat merugikan dan mengurangi tingkat kecocokan cache jika load balancing tidak dilakukan dengan benar. Pada deployment biasa, beberapa mesin berada di belakang load balancer yang mendistribusikan traffic secara merata ke setiap mesin, menggunakan algoritma sederhana seperti round robin. Hasilnya, setiap mesin mempertahankan cache independennya sendiri, sehingga konten yang disimpan dalam cache diisolasi di seluruh mesin. Jika setiap kueri yang masuk didistribusikan ke mesin acak, tergantung pada sifat traffic, rasio kehilangan cache yang efektif dapat ditingkatkan secara proporsional. Misalnya, untuk nama dengan TTL panjang yang dikueri berulang kali, tingkat cache yang tidak ditemukan dapat ditingkatkan dengan jumlah mesin dalam cluster. (Untuk nama dengan TTL yang sangat singkat, yang sangat jarang dikueri, atau yang menghasilkan respons yang tidak dapat disimpan dalam cache (0 TTL dan error), tingkat kehilangan cache tidak terlalu terpengaruh oleh penambahan mesin.)
Guna meningkatkan rasio hit untuk nama yang dapat di-cache, penting untuk melakukan load balancing server agar cache tidak terfragmentasi. Dalam Google Public DNS, kita memiliki dua tingkat penyimpanan {i>caching<i}. Dalam satu kumpulan mesin, yang sangat dekat dengan pengguna, cache kecil per mesin berisi nama-nama yang paling populer. Jika tidak dapat dipenuhi dari cache ini, kueri akan dikirim ke kumpulan mesin lain yang mempartisi cache berdasarkan nama. Untuk cache tingkat kedua ini, semua kueri untuk nama yang sama dikirim ke mesin yang sama, tempat nama tersebut di-cache atau tidak.
Mendistribusikan cluster layanan untuk cakupan geografis yang luas
Untuk resolver tertutup, ini bukanlah masalah. Untuk resolver terbuka, semakin dekat lokasi server Anda dengan pengguna, semakin sedikit latensi yang akan mereka lihat di sisi klien. Selain itu, memiliki cakupan geografis yang memadai secara tidak langsung dapat meningkatkan latensi end-to-end, karena server nama biasanya menampilkan hasil yang dioptimalkan untuk lokasi DNS resolver. Artinya, jika penyedia konten menghosting situs yang dicerminkan di seluruh dunia, server nama penyedia tersebut akan menampilkan alamat IP yang paling dekat dengan resolver DNS.
Google Public DNS dihosting di pusat data di seluruh dunia, dan menggunakan perutean anycast untuk mengirim pengguna ke pusat data yang terdekat secara geografis.
Selain itu, Google Public DNS mendukung subnet klien (ECS) EDNS, yaitu ekstensi protokol DNS bagi resolver untuk meneruskan lokasi klien ke server nama, yang dapat menampilkan respons sensitif lokasi yang dioptimalkan untuk alamat IP klien sebenarnya, bukan alamat IP klien. Harap baca FAQ ini untuk mengetahui detailnya. Google Public DNS otomatis mendeteksi server nama yang mendukung Subnet Klien EDNS.