Berapa lama yang dibutuhkan untuk menyebarkan data DNS?

Ini adalah Pertanyaan Canonical tentang Propagasi DNS

Berapa lama untuk menyebarkan berbagai jenis rekaman?
Apakah beberapa merambat lebih cepat dari yang lain?
Mengapa perlu waktu untuk menyebarluaskan data DNS dan bagaimana cara kerjanya?

domain-name-system

— Komunitas
sumber

Catatan: Secara historis ada perbedaan penting dan signifikan dalam waktu yang diperlukan untuk memperbarui berbagai jenis catatan (tergantung pada siapa yang menyimpannya dan semacamnya). Ini tidak lagi menjadi masalah hari ini.

— Chris S

Ketika ppl menggunakan kata "menyebarkan" untuk DNS itu jelas menunjukkan mereka tidak tahu apa itu DNS dan bagaimana cara kerjanya. Mari berharap dokumentasi akan "menyebar" dengan cukup cepat (semoga saja).

— poige

@tonygil Silakan lihat komentar Poige. Tidak ada propagasi dns. Selain itu, ISP tidak mengontrol server root. Jika server DNS ISP itu melakukan caching lebih lama dari TTL rekaman, maka mereka melanggar RFC. Anda tampaknya memiliki beberapa kesalahpahaman dengan cara kerja DNS; tetapi pelanggaran RFC biasanya akan merusak cara kerjanya. Ini tidak ada hubungannya dengan AS atau Eropa.

— Chris S

@tonygil: "cyberpolice" untuk "membuat" mereka memperbarui adalah semua sysadmin, admin jaringan, dll, memberikan tekanan sosial pada aktor jahat. Internet berfungsi karena kita semua sepakat bahwa itu seharusnya. Kepentingan terbaik pengguna, jaringan, dll kami adalah "kepentingan terbaik" Internet. re: "pengguna bukan technogurus" - Ini adalah situs untuk administrator sistem profesional dan bukan pengguna akhir. Terus terang, saya berharap sysadmin menjadi semacam "technoguru" (untuk menggunakan terminologi Anda). Sysadmin yang , menurut pekerjaan, seharusnya peduli bagaimana hal ini bekerja.

— Evan Anderson

@ EvanAnderson saya sepenuhnya setuju bahwa tekanan membuat perubahan. di sisi lain, kenyataannya adalah bahwa sysadmin malas atau tidak kompeten di luar sana dalam gerombolan. dan semakin jauh Anda bergerak dari AS dan Eropa, semakin sering mereka menjadi. harapan Anda baik-baik saja 4 US tetapi mereka tidak layak di sebagian besar dunia nyata, di mana sysadmin tidak siap adalah aturannya. jadi, sementara Anda mengharapkan semuanya baik-baik saja, Anda harus berurusan dengan dunia nyata, di mana mereka TIDAK. Lagi pula, buat poin saya, Anda membuat milik Anda. mari kita setuju untuk tidak setuju.

— tony gil

"Perambatan DNS" bukanlah fenomena nyata, per se. Sebaliknya, itu adalah efek nyata dari fungsi caching yang ditentukan dalam protokol DNS. Mengatakan bahwa perubahan "menyebar" antara server DNS adalah kepalsuan yang nyaman, yang bisa dibilang, lebih mudah dijelaskan kepada pengguna non-teknis daripada menjelaskan semua detail protokol DNS. Ini bukan cara protokol bekerja.

Server DNS rekursif membuat permintaan atas nama klien. Server DNS rekursif, biasanya dijalankan oleh ISP atau departemen TI, digunakan oleh komputer klien untuk menyelesaikan nama sumber daya Internet. Server DNS rekursif menyimpan hasil kueri yang mereka buat untuk meningkatkan efisiensi. Pertanyaan untuk informasi yang sudah di-cache dapat dijawab tanpa membuat pertanyaan tambahan. Durasi, dalam detik, hasil di-cache seharusnya didasarkan pada nilai yang dapat dikonfigurasi yang disebut Time To Live (TTL). Nilai ini ditentukan oleh server DNS yang berwenang untuk catatan yang diminta.

Tidak ada satu jawaban untuk semua pertanyaan yang diajukan karena DNS adalah protokol terdistribusi. Perilaku DNS tergantung pada konfigurasi server DNS otoritatif untuk catatan yang diberikan, konfigurasi server DNS rekursif yang membuat permintaan atas nama komputer klien, dan fungsionalitas caching DNS yang terpasang pada sistem operasi komputer klien.

Ini praktik yang baik untuk menentukan nilai TTL yang cukup pendek untuk mengakomodasi perubahan harian dari catatan DNS, tetapi cukup lama untuk menciptakan "kemenangan" dalam caching (yaitu tidak terlalu pendek untuk men-cache cache terlalu cepat untuk memberikan peningkatan efisiensi). Menggunakan strategi yang seimbang dengan nilai-nilai TTL menghasilkan "kemenangan" untuk semua orang. Ini mengurangi penggunaan beban dan bandwidth untuk server DNS resmi untuk domain tertentu, server root, dan server TLD. Ini mengurangi pemanfaatan bandwidth upstream untuk operator server DNS rekursif. Ini menghasilkan respons permintaan yang lebih cepat untuk komputer klien.

Sebagai catatan DNS TTL diatur beban yang lebih rendah dan pemanfaatan bandwidth pada server DNS otoritatif akan meningkat karena server DNS rekursif tidak akan dapat men-cache hasil untuk jangka waktu yang lama. Sebagai TTL catatan, perubahan yang lebih tinggi ke catatan tidak akan tampak "berpengaruh" dengan cepat karena komputer klien akan terus menerima hasil cache yang disimpan di server DNS rekursif mereka. Mengatur TTL yang optimal bermuara pada tindakan penyeimbangan antara pemanfaatan dan kemampuan untuk mengubah catatan dengan cepat dan melihat perubahan itu tercermin pada klien.

Perlu dicatat bahwa beberapa ISP kasar dan mengabaikan nilai-nilai TTL yang ditentukan oleh server DNS otoritatif (menggantikan penggantian administratif mereka sendiri, yang merupakan pelanggaran RFC). Tidak ada yang bisa dilakukan mengenai hal ini, dari sudut pandang teknis. Jika operator server DNS yang melecehkan dapat ditemukan keluhan kepada administrator sistem mereka dapat mengakibatkan penerapan praktik terbaik mereka (bisa dibilang apa yang masuk akal untuk setiap insinyur jaringan yang akrab dengan DNS). Jenis penyalahgunaan khusus ini bukan masalah teknis.

Jika semua orang "bermain sesuai aturan" perubahan pada catatan DNS dapat "berlaku" dengan sangat cepat. Dalam hal mengubah alamat IP yang ditetapkan untuk catatan "A", misalnya, backoff eksponensial dari nilai TTL akan dilakukan, menjelang waktu perubahan akan dilakukan. TTL dapat dimulai pada 1 hari, misalnya, dan diturunkan menjadi 12 jam untuk periode 24 jam, kemudian 6 jam untuk periode 12 jam, 3 jam untuk periode 6 jam, dll, turun ke beberapa interval kecil yang sesuai. Setelah TTL dicadangkan, catatan dapat diubah dan TTL dikembalikan ke nilai yang diinginkan untuk operasi sehari-hari. (Tidak perlu menggunakan backoff eksponensial, namun strategi ini meminimalkan waktu catatan akan memiliki TTL rendah dan mengurangi beban pada server DNS yang berwenang.)

Setelah membuat catatan perubahan log DNS harus dipantau untuk upaya akses yang dibuat sebagai akibat dari catatan DNS lama. Dalam contoh mengubah catatan "A" untuk merujuk ke alamat IP baru, server harus tetap ada di alamat IP lama untuk menangani upaya akses yang dihasilkan dari komputer klien yang masih menggunakan catatan "A" yang lama. Setelah upaya akses berdasarkan catatan lama telah mencapai tingkat rendah yang dapat diterima, alamat IP lama dapat digunakan. Jika permintaan yang terkait dengan catatan lama tidak berkurang dengan cepat, ada kemungkinan bahwa (seperti dijelaskan di atas) server DNS rekursif mengabaikan TTL otoritatif. Mengetahui sumber alamat IP dari upaya akses, bagaimanapun, tidak memberikan informasi langsung ke server DNS rekursif yang bertanggung jawab untuk memasok catatan lama.

Secara pribadi, saya telah melihat perubahan "segera berlaku", dalam beberapa jam, dan dalam beberapa kasus dengan ISP yang rusak otak, setelah beberapa hari. Melakukan backoff dari TTL Anda dan memperhatikan bagaimana prosesnya bekerja akan meningkatkan perubahan Anda untuk sukses, tetapi Anda tidak pernah bisa memastikan apa yang dilakukan oleh beberapa orang idiot yang bermaksud baik dengan server DNS rekursif mereka.

— Evan Anderson
sumber

Ini bukan jawaban tentang "OpenDNS" - ini adalah jawaban tentang DNS. Penyedia DNS rekursif apa pun dapat mengimplementasikan antarmuka apa pun yang mereka inginkan untuk memungkinkan pembersihan cache, dll. Kita berbicara tentang DNS - bukan tentang API vendor. Sejauh suntingan Anda: Saya mendukung ungkapan "kerusakan otak" sebagai ungkapan yang telah lama digunakan dalam budaya peretas, dan saya menggunakannya dalam konteks itu (lihat File Jargon, "Peretas" Steven Levy, dll.) . Sejauh "bodoh" saya pikir cukup masuk akal bahwa, di luar kode hukum, ini adalah istilah sehari-hari untuk tindakan yang bersifat tidak kompeten. Saya juga mendukungnya.

— Evan Anderson

@tonygil - OpenDNS bukan DNS. Itu hanya layanan yang ditawarkan seseorang. Bagaimana jika FooDNS dibuka besok dan memiliki beberapa API pembersihan cache baru yang menarik? Haruskah jawaban saya mencakup itu juga? Di mana itu berhenti? Ini merosot menjadi kegilaan. re: hak sipil - Saya bukan pengusaha atau entitas pemerintah yang menyangkal hak sipil untuk anggota kelas yang dilindungi. Tentu - silakan dan lihat apakah Anda dapat menemukan seseorang yang ingin menuntut saya. Mereka dapat menghubungi saya melalui surat di PO Box 852, Troy, OH. (866) 569-9799, x801 meneruskan ke ponsel saya 24x7. (Itu pekerjaan detektif yang bagus di sana melihat profil saya, BTW.)

— Evan Anderson

Anda tahu, Anda mengatakan bahwa tekanan teman sebaya membawa perubahan. itulah yang saya lakukan. dibawa ke perhatian Anda bahwa saya tidak setuju dengan penggunaan "idiot" dan "otak-rusak" karena mereka ofensif dan menghina. fakta bahwa seseorang menggunakannya sebanyak-banyaknya (yaitu peretas) tidak memperbaikinya. kkk menggunakan kata-n sebanyak-banyaknya. tolong hormati kami yang peduli dengan gangguan mental. Saya mengerti bahwa Anda memasukkan istilah metaforis dalam gaya penuh warna Anda, tapi percayalah: mereka ofensif dan tidak perlu.

— tony gil

Tentang menghormati TTL: TTL adalah nilai maksimum untuk menyimpan sesuatu dalam cache, penyelesai caching bebas untuk membuang data sebelumnya. Jadi mereka bisa menurunkannya jika mereka mau. Namun memang benar bahwa mereka tidak boleh meningkatkannya, itu adalah pelanggaran protokol. Tetapi bagi orang-orang yang menempatkan 1 detik di TTL beberapa cache membela diri dengan tidak menghormatinya dan malah menjepit pada 5 menit saja.

— Patrick Mevzek

Server DNS rekursif, biasanya dijalankan oleh ISP atau departemen TI, saat ini mereka adalah armada besar (cloud siaran) dari nameserver rekursif terbuka seperti 1.1.1.1atau 8.8.8.8atau 9.9.9.9atau 80.80.80.80. Penting untuk dipahami bahwa mereka disiarkan: balasan mungkin berubah berdasarkan pada IP sumber karena akan berpotensi secara fisik berbeda secara instan DAN cache yang mereka miliki bersifat global untuk semua contoh, atau tidak.

— Patrick Mevzek