Fenix by Takeda11
Banyak orang bingung memperbarui catatan DNS saat mereka mengubah alamat IP situs mereka. Mengapa rekaman ini diperbarui secara perlahan? Apakah Anda benar-benar perlu menunggu dua hari untuk memperbarui semuanya? Mengapa beberapa pengunjung melihat IP baru, sementara yang lain melihat IP lama?
Tim Solusi Cloud Mail.ru telahmenerjemahkan artikel oleh pengembang dan penulis artikel Julia Evans, di mana dia menjawab pertanyaan-pertanyaan ini dan secara populer berbicara tentang apa yang terjadi selama pembaruan DNS dari perspektif front-end.
Berikut penjelajahan singkat tentang apa yang terjadi di balik layar saat Anda memperbarui data DNS.
Cara Kerja DNS: Server DNS Rekursif dan Otoritatif
Pertama, kami perlu menjelaskan sedikit tentang sistem DNS. Ada dua jenis server DNS: otoritatif dan rekursif .
Otoritatif server DNS (juga dikenal sebagai server nama ) menjaga database alamat IP untuk setiap domain mereka bertanggung jawab untuk. Misalnya, saat ini server DNS resmi untuk github.com adalah
ns-421.awsdns-52.com. Anda dapat menanyakan alamat IP github.com dengan permintaan ini:
dig @ns-421.awsdns-52.com github.com
Server DNS rekursif sendiri tidak tahu apa-apa tentang siapa yang memiliki alamat IP mana. Mereka menghitung alamat IP untuk domain dengan menanyakannya dari server DNS otoritatif yang sesuai dan kemudian menyimpan alamat IP tersebut jika mereka diminta lagi. Jadi 8.8.8.8 adalah server DNS rekursif.
Saat orang mengunjungi situs web Anda, mereka mungkin melakukan pencarian DNS ke server DNS rekursif. Jadi bagaimana cara kerja server DNS rekursif? Mari kita lihat!
Bagaimana server DNS rekursif menanyakan alamat IP github.com
Mari kita lihat contoh apa yang dilakukan server DNS rekursif (misalnya 8.8.8.8) ketika Anda memintanya untuk alamat IP (data A) untuk github.com. Pertama, jika sudah memiliki hasil yang di-cache, itu akan mengeluarkannya. Tetapi bagaimana jika semua cache telah kedaluwarsa? Inilah yang terjadi.
Langkah 1 : Alamat IP untuk server DNS root di-hardcode dalam kode sumbernya. Anda dapat melihat ini di kode sumber tidak terikat . Misalkan dia memilih 198.41.0.4 terlebih dahulu. Berikut adalah sumber resmi untuk alamat IP berkode keras ini, juga dikenal sebagai "file petunjuk root".
Langkah 2 : Tanyakan server nama root tentang github.com.
Kami kira-kira dapat mereproduksi apa yang terjadi dengan perintah
dig... Ini memberi kita nameserver otoritatif baru untuk melakukan kueri: nameserver untuk .comdengan alamat IP 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Detail respons DNS sedikit lebih rumit - dalam hal ini ada bagian otoritas dengan beberapa catatan NS dan bagian tambahan dengan catatan A, jadi Anda tidak perlu melakukan pencarian tambahan untuk mendapatkan alamat IP dari server nama tersebut.
Dalam praktiknya, 99,99% dari waktu akan ada alamat server nama yang di-cache
.com, tetapi kami berpura-pura bahwa kami benar-benar memulai dari awal.
Langkah 3 : Tanyakan server nama
.comtentang github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
Kami memiliki alamat IP baru untuk mengirim permintaan! Ini adalah salah satu server nama untuk github.com.
Langkah 4 : Minta alamat github.com dari server nama github.com.
Kami hampir selesai!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Jadi kami memiliki rekor A untuk github.com. Server rekursif sekarang memiliki alamat IP github.com dan dapat mengembalikannya kepada Anda. Dan dia bisa melalui seluruh proses, dimulai hanya dengan beberapa alamat IP yang di-hardcode: alamat dari root name server.
Cara melihat semua langkah server DNS rekursif: dig + trace
Untuk melihat apa yang akan dilakukan server DNS rekursif untuk menyelesaikan domain, Anda dapat menjalankan:
$ dig @8.8.8.8 +trace github.com
Perintah ini menunjukkan semua catatan DNS yang diminta oleh server rekursif, dimulai dengan server DNS root, yang merupakan empat langkah yang baru saja kita lalui.
Perbarui data DNS
Sekarang setelah kita mengetahui dasar-dasar cara kerja DNS, mari perbarui beberapa catatan DNS dan lihat apa yang terjadi.
Saat memperbarui catatan DNS, ada dua opsi utama:
- simpan server nama yang sama;
- ubah server nama.
Mari kita bicara tentang TTL
Tapi kami melupakan sesuatu yang penting. Ini TTL. Seperti yang kami katakan sebelumnya, server DNS rekursif akan menyimpan catatan hingga kedaluwarsa. Ini memutuskan pada kedaluwarsa rekaman berdasarkan TTL-nya (waktu untuk hidup).
Dalam contoh ini, server nama GitHub mengembalikan TTL 60 untuk data DNS-nya, yang berarti 60 detik:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Ini adalah TTL yang cukup singkat. Secara teori, jika semua implementasi DNS mengikuti standar DNS , itu berarti jika GitHub memutuskan untuk mengubah alamat IP untuk github.com, semua orang akan menerima alamat IP baru dalam 60 detik. Mari kita lihat bagaimana ini terjadi dalam praktiknya.
Opsi 1: Perbarui data DNS di server nama yang sama
Pertama, saya memperbarui server nama saya (Cloudflare) untuk mendapatkan data DNS baru, data A, yang dipetakan
test.jvns.cake 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Ini bekerja segera! Tidak perlu menunggu sama sekali, karena sebelumnya tidak ada DNS record
test.jvns.cayang bisa di-cache. Luar biasa. Tapi sepertinya rekor baru di-cache selama sekitar lima menit (299 detik).
Lalu bagaimana jika kita mencoba mengubah alamat IP ini? Saya mengubahnya menjadi 5.6.7.8 dan kemudian menjalankan kueri DNS yang sama:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Sepertinya di server DNS ini data 1.2.3.4 masih disimpan dalam cache selama 144 detik. Menariknya, jika Anda melakukan kueri 8.8.8.8 beberapa kali, Anda akan mendapatkan hasil yang tidak konsisten - terkadang memberikan Anda IP baru dan terkadang yang lama. Mungkin 8.8.8.8 sebenarnya mendistribusikan beban ke banyak backend yang berbeda, masing-masing dengan cache mereka sendiri.
Setelah lima menit menunggu, semua 8.8.8.8 cache diperbarui dan selalu mengembalikan entri 5.6.7.8 yang baru. Luar biasa. Cukup cepat!
Anda tidak selalu bisa mengandalkan TTL
Seperti kebanyakan protokol Internet, tidak semuanya mengikuti spesifikasi DNS. Beberapa server DNS ISP akan menyimpan catatan lebih lama dari TTL yang ditentukan. Misalnya, dalam dua hari, bukan lima menit. Dan orang selalu dapat melakukan hardcode alamat IP lama di file mereka
/etc/hosts.
Dalam praktiknya, saat memperbarui catatan DNS dengan TTL lima menit, Anda dapat mengharapkan sebagian besar klien untuk dengan cepat berpindah ke alamat IP baru (misalnya, dalam 15 menit), dan kemudian akan ada banyak kelambanan yang perlahan akan diperbarui selama beberapa hari ke depan.
Opsi 2: Memperbarui server nama Anda
Jadi, kami telah melihat bahwa ketika Anda memperbarui alamat IP tanpa mengubah server nama Anda, banyak server DNS mendapatkan alamat IP baru dengan cukup cepat. Luar biasa. Tetapi apa yang terjadi jika Anda mengubah server nama Anda? Mari mencoba!
Saya tidak ingin memperbarui server nama untuk blog saya, jadi saya mengambil domain saya yang berbeda dan menggunakannya dalam contoh untuk log HTTP , examplecat.com.
Sebelumnya, server saya disetel ke
dns1.p01.nsone.net. Saya memutuskan untuk mengubahnya ke server Google dengan alamat ns-cloud-b1.googledomains.comdan sebagainya.
Saat saya melakukan perubahan, registrar domain saya menampilkan pesan dengan agak tidak menyenangkan: “Perubahan pada examplecat.com disimpan. Mereka akan mulai berlaku dalam 48 jam ke depan. " Kemudian saya membuat rekam A baru untuk domain tersebut agar mengarah ke 1.2.3.4.
Oke, mari kita lihat apakah ada yang berubah:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Tidak ada perubahan. Jika saya bertanya pada server DNS lain, ia tahu IP baru:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Tetapi 8.8.8.8 masih tidak tahu apa-apa. Alasan 1.1.1.1 melihat IP baru meskipun saya baru mengubahnya lima menit yang lalu mungkin karena belum pernah ada yang menanyakan 1.1.1.1 tentang examplecat.com ini sebelumnya - jadi tidak ada apa pun di cache-nya. Dulu.
Server nama memiliki lebih banyak TTL
Alasan registrar saya berkata, "Ini akan memakan waktu 48 jam," adalah karena TTL pada data NS (server nama yang harus diakses server rekursif) jauh lebih besar.
Server nama baru pasti mengembalikan alamat IP baru untuk examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Tapi ingat apa yang terjadi ketika kita menanyakan nameserver github.com sebelumnya:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172.800 detik adalah 48 jam! Karenanya, memperbarui server nama biasanya membutuhkan waktu lebih lama. Butuh waktu untuk kedaluwarsa cache dan menyebarkan alamat baru. Diperlukan waktu lebih lama daripada hanya memperbarui alamat IP Anda tanpa mengubah server nama Anda.
Bagaimana server nama Anda diperbarui
Saat saya memperbarui server nama untuk
examplecat.com, server nama .commendapatkan data NS baru dengan domain baru. Seperti ini:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Tapi bagaimana catatan NS baru ini sampai di sana? Nyatanya, saya memberi tahu pencatat domain saya seperti apa tampilan server nama baru saya dengan memutakhirkannya di situs web, dan kemudian pencatatan domain saya memberi tahu server nama
.comuntuk melakukan pembaruan.
Untuk
.compembaruan ini cukup cepat (dalam beberapa menit), tetapi saya pikir untuk beberapa zona TLD lainnya, server nama mungkin tidak menerapkan pembaruan dengan cepat.
Perpustakaan penyelesai DNS program Anda juga dapat menyimpan catatan DNS dalam cache
Alasan lain mengapa TTL mungkin tidak diamati dalam praktiknya adalah bahwa banyak program harus menyelesaikan nama DNS, dan beberapa program juga akan menyimpan catatan DNS dalam cache dalam memori tanpa batas waktu (hingga program di-restart).
Misalnya, ada artikel tentang menyiapkan JVM TTL untuk pencarian DNS . Saya sendiri belum menulis banyak kode JVM untuk pencarian DNS, tetapi sedikit pencarian di internet tentang JVM dan DNS memberi kesan bahwa Anda dapat mengkonfigurasi JVM untuk menyimpan cache setiap pencarian DNS untuk waktu yang tidak terbatas (lihat tiket ElasticSearch ini misalnya ) ...
Itu saja!
Semoga ini membantu Anda memahami apa yang terjadi ketika DNS Anda diperbarui.
Saya akan membuat reservasi bahwa seluruh riwayat distribusi DNS ditentukan tidak hanya oleh TTL. Beberapa server DNS rekursif mungkin tidak menghormati TTL, bahkan server besar seperti 8.8.8.8. Jadi, meskipun Anda hanya memperbarui rekam A dengan TTL kecil, ada kemungkinan bahwa dalam praktiknya Anda masih akan menerima permintaan untuk IP lama dalam satu atau dua hari.
Setelah memposting artikel ini, saya mengubah nameserver untuk examplecat.com kembali ke nilai lama.
Apa lagi yang harus dibaca: