DNS dan cara kerjanya mungkin disertai dengan lebih banyak kesalahpahaman, legenda, takhayul, dan mitologi sebagai aspek TI.
Bahkan kita yang tahu bahwa kita pada dasarnya berbohong (atau paling tidak menyederhanakan secara drastis) ketika kita berbicara tentang "penyebaran" perubahan masih cenderung menggunakan istilah untuk menggambarkan sesuatu yang - secara bersamaan - sangat sederhana dan langsung ... namun sulit untuk dijelaskan ... dan tidak ada hubungannya dengan propagasi semata , tetapi semuanya berkaitan dengan caching dan caching negatif, yang keduanya merupakan komponen penting dari cara kerja sistem (dan, bisa dibilang, bagaimana ia menghindari kehancuran langsung di bawah beratnya sendiri) - pada dasarnya bagian dalam-luar, kebalikan dari "propagasi" yang sebenarnya, tarikan - bukan dorongan.
Untuk semua kekhawatiran dan kekesalan tentang TTL pendek, mereka cenderung bekerja lebih sering daripada tidak, sampai-sampai ada kepentingan Anda untuk mencobanya saja. Pada $ {day_job}, ketika situs kami bermigrasi dari platform "lama" ke platform "baru", sering kali berarti mereka bermigrasi sedemikian rupa sehingga tidak ada apa pun dalam infrastruktur yang dibagikan. Langkah pertama saya dalam migrasi semacam ini adalah menjatuhkan TTL ke 60s cukup jauh sebelum pemotongan sehingga TTL lama memiliki beberapa kelipatan sendiri untuk habis, memberi saya jaminan yang masuk akal bahwa RR transisi ini dengan TTL pendek akan "menyebar . " Ketika saya siap untuk memotong, saya mengkonfigurasi ulang penyeimbang lama¹ untuk memangkas lalu lintas ke sistem baru - di Internet - sehingga penyeimbang tidak lagi menyeimbangkan banyak sistem internal, tetapi sebaliknya, adalah "
Lalu saya memotong DNS, dan menonton balancer baru dan lama.
Saya selalu terkejut melihat betapa cepat transisi ini terjadi. Penahan tampaknya hampir selalu menjadi spider pencarian dan situs "pemeriksaan kesehatan" pihak ketiga yang secara tidak dapat dipercaya menempel pada catatan lama.
Tapi ada satu skenario yang dapat diprediksi: ketika jendela browser pengguna tetap terbuka, mereka cenderung menempel ke alamat yang sudah ditemukan, dan sering kali berlanjut sampai semua jendela browser mereka ditutup.
Tetapi dalam narasi di atas, Anda menemukan solusi untuk masalah ini: "load balancer" - secara khusus dan lebih tepatnya, proxy terbalik - dapat menjadi sistem yang ditunjuk oleh catatan DNS Anda.
Proxy terbalik kemudian meneruskan permintaan ke alamat IP target yang benar, yang diselesaikan menggunakan nama host "dummy" kedua dengan TTL pendek, yang menunjuk ke server back-end nyata. Karena proxy selalu menghormati DNS TTL pada itu entri DNS dummy, Anda yakin dengan peralihan yang cepat dan lengkap.
Sisi buruknya adalah Anda mungkin merutekan lalu lintas melalui infrastruktur tambahan yang tidak perlu, atau membayar lebih untuk transportasi melintasi beberapa batas jaringan, secara berlebihan.
Ada layanan yang menyediakan kemampuan semacam ini pada skala global, dan yang paling saya kenal adalah CloudFront. (Kemungkinan besar, Cloudflare akan melayani tujuan yang persis sama, karena sedikit pengujian yang saya lakukan menunjukkan bahwa ia juga berperilaku benar, dan saya yakin ada yang lain.)
Meskipun dipasarkan terutama sebagai CDN, CloudFront pada intinya adalah jaringan global proksi terbalik dengan kemampuan untuk secara opsional menyimpan respons. Jika www.example.compoin ke CloudFront dan CloudFront dikonfigurasikan untuk meneruskan permintaan ini backend.example.com, dan catatan DNS untuk backend.example.commenggunakan TTL pendek, maka CloudFront akan melakukan hal yang benar, karena itu menghormati TTL pendek itu. Ketika catatan back-end berubah, semua lalu lintas akan bermigrasi pada saat TTL berjalan.
TTL pada catatan sisi depan yang menunjuk ke CloudFront, dan apakah browser dan penyelesai caching yang menghormatinya tidak penting, karena perubahan pada tujuan back-end tidak memerlukan perubahan pada www.example.comcatatan ... jadi anggapan bahwa "Internet" telah, berkaitan dengan target yang benar untuk www.example.comkonsisten, terlepas dari di mana sistem back-end terjadi.
Ini, bagi saya, menyelesaikan masalah sepenuhnya dengan menghilangkan browser dari setiap kebutuhan untuk "mengikuti" perubahan ke IP server asal.
tl; dr: merutekan permintaan ke sistem yang berfungsi sebagai proxy untuk server web asli, sehingga hanya konfigurasi proxy yang perlu mengakomodasi perubahan IP server asal - bukan DNS yang menghadap browser.
Perhatikan bahwa CloudFront juga meminimalkan latensi oleh beberapa sihir DNS yang diterapkannya di sisi depan, yang menghasilkan www.example.compenyelesaian ke lokasi tepi CloudFront paling optimal berdasarkan lokasi browser yang meminta www.example.com, sehingga ada peluang lalu lintas minimal mengambil rute yang tidak perlu. dari peramban ke tepi ke asal ... tetapi bagian ini transparan dan otomatis dan di luar cakupan pertanyaan.
Dan, tentu saja, caching konten mungkin juga bernilai dengan mengurangi beban pada server asal atau transportasi - Saya telah mengkonfigurasi situs web di CloudFront di mana server asal berada di sirkuit ADSL, dan ADSL secara inheren dibatasi untuk bandwidth upstream. Server asal tempat CloudFront terhubung untuk mengambil konten tidak harus menjadi server di dalam ekosistem AWS.
¹ Saya berbicara tentang penyeimbang sebagai entitas tunggal padahal sebenarnya memiliki banyak node. Ketika penyeimbang adalah ELB, mesin di belakang penyeimbang bertindak sebagai server aplikasi dummy dan melakukan hairpinning aktual ke penyeimbang platform baru, karena ELB tidak dapat melakukan ini sendiri.
² Satu-satunya pengetahuan penyeimbang baru tentang yang lama adalah bahwa ia perlu mempercayai X-Forwarded-For penyeimbang yang lama dan bahwa ia tidak boleh melakukan tingkat berbasis IP yang membatasi alamat sumber penyeimbang yang lama.
³ Ketika proksi adalah satu atau lebih server yang Anda kontrol, Anda memiliki opsi untuk melompati menggunakan DNS di sisi belakang, dan hanya menggunakan alamat IP dalam konfigurasi proxy, tetapi skenario yang dihosting / didistribusikan yang dibahas selanjutnya memerlukan lapisan DNS kedua. .