Bagaimana urutan pencarian DNS ditentukan?

Sebagai contoh: kami telah mendaftarkan nama domain domain.com dan menambahkan catatan server nama di server pendaftar:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Daripada kita mencari domain.com . Kami mendapatkan semua 3 alamat server nama.
1. Server mana yang akan diminta lebih lanjut dan mengapa?
2. Apakah urutan catatan NS dalam file zona penting?
3. Apakah ditentukan dalam RFC ?

Sayangnya, jawabannya di sini adalah "itu tergantung". Faktor-faktor yang tergantung padanya akan bervariasi dengan domain dan bagaimana server yang dimiliki diatur serta bagaimana DNS lokal Anda diatur.

Pertama, misalnya, berkenaan dengan catatan NS yang dikembalikan: sangat diizinkan untuk mengacak urutan pengembalian catatan tersebut, sehingga urutannya dapat berbeda setiap kali Anda memintanya. Di sisi lain, itu tidak dilakukan oleh semua implementasi DNS, jadi Anda mungkin mendapatkan daftar yang dipesan secara statis. Intinya adalah Anda tidak bisa yakin.

Selanjutnya, beberapa implementasi DNS akan menanyakan setiap NS secara paralel, dan menggunakan yang mana balasan pertama. Yang lain akan memukul masing-masing, menentukan tercepat dari sejumlah permintaan dan menggunakannya. Atau bisa juga hanya round-robin.

Ada beberapa RFC untuk DNS, dua yang lebih bermanfaat yang saya temukan adalah:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Saya menyadari ini adalah sesuatu yang bukan jawaban, tanpa sesuatu yang pasti untuk Anda ambil, tetapi mengingat hal di atas, satu-satunya cara yang benar Anda harus menentukan perilaku untuk domain yang diberikan adalah untuk menguji.

Implementasi paling umum yang saya lihat di tingkat klien, seperti ISP di seluruh dunia, adalah sebagai berikut:

1. Seseorang (seperti pelanggan broadband) meminta server DNS ISP untuk menyelesaikan catatan A untuk foo.example.com.
2. ISP memeriksa cache sendiri, dan jika catatan itu di-cache dan masih dianggap "segar," itu segera dikembalikan melalui cache. ( Ini adalah cara semua cache DNS bekerja, sehingga mereka tidak perlu membebani server DNS situs yang bersangkutan. )
3. Jika mereka tidak memiliki catatan yang di-cache, atau jika cache dianggap "basi / ketinggalan zaman," ISP tahu bahwa itu perlu menyelesaikan catatan terbaru lagi.
4. Sekarang ISP perlu tahu server nama apa yang harus ditanyakan tentang catatan terbaru.
5. ISP mulai dengan memeriksa daftar cache dari server nama otoritatif untuk domain (ini adalah ns1.example.com, ns2.example.com dan seterusnya bersama dengan IP mereka). Jika catatan itu masih dianggap baru, ia akan melompati ke langkah 8.
6. Jika catatan nameserver yang di-cache dianggap kadaluwarsa, atau jika tidak memiliki catatan yang di-cache untuk domain itu, ISP menanyakan server-nameserver TLD (seperti registri .com jika itu adalah domain .com) untuk mendapatkan pasangan nama server nama / IP paling terkini untuk example.com. ( Anda dapat mencobanya sendiri melalui "dig @ b.gtld-servers.net example.com" untuk melihat apa yang diketahui oleh nameserver root untuk TLD Anda tentang domain Anda - jika domain Anda milik TLDs com / net / etc yang biasa. TLD harus meminta server root masing-masing. )
7. Root nameserver untuk TLD selalu mengembalikan nameserver dengan urutan yang ditentukan oleh Anda; tidak ada pengacakan yang berlangsung. Mereka juga mengembalikan IP untuk setiap server nama; ini dikenal sebagai "LEM" dan inilah yang memungkinkan internet untuk memecahkan masalah "ayam dan telur" tentang cara menyelesaikan nama host server nama ke IP sebelum mengetahui apa pun tentang suatu domain. Selain itu, sebagian besar dari mereka (seperti register com / net / etc yang merupakan yang terbesar) menggunakan waktu cache 2 hari sehingga mereka tidak terus-menerus dipalu dengan "apa daftar server nama untuk domain X?" permintaan. Ini adalah sumber dari pengetahuan umum bahwa Anda HARUS menunggu 2 hari sampai Anda dapat dengan aman mengatakan bahwa server nama baru Anda dikenal di seluruh dunia, setelah Anda
8. Ketika ISP mengetahui server nama example.com dan IP mereka, seperti ns1.example.com, ns2.example.com, ns3.example.com, ISP sekarang memilih server acak dari daftar itu dan mengirimkan kueri. ( Ini bagus untuk mereka, mereka tidak perlu memalu semua server DNS dari situs yang bersangkutan, dan mereka membantu lebih lanjut dengan load balancing dengan tidak selalu menanyakan nameserver yang terdaftar pertama. )
9. Jika ISP tidak mendapatkan respons dari server nama tersebut dalam periode waktu habis yang ditentukan, ISP akan meminta yang lain dalam daftar.
10. Ketika memiliki respons, ISP sekarang menyimpannya dalam cache lokalnya sendiri. Adapun berapa lama itu akan tetap di-cache; setiap catatan yang dikembalikan oleh server DNS mana pun juga memiliki waktu "kedaluwarsa lunak" (dalam detik) yang terkait dengannya, yaitu berapa lama klien kueri (seperti server DNS ISP) diizinkan untuk menyimpan cache catatan itu sebelum dipertimbangkan " masih dapat digunakan tetapi mungkin kedaluwarsa, permintaan baru sekarang harus dilakukan JIKA MUNGKIN hanya untuk memastikan itu tidak berubah. " Ada juga waktu "kedaluwarsa" yang ditentukan dalam catatan "SOA" (Mulai Otoritas) dari masing-masing server nama individu (Anda dapat melihat milik Anda melalui "dig @ ns1.example.com example.com -t soa"), yang menentukan "batas keras" global untuk semua catatan yang dikembalikan oleh server itu, setelah itu setiap cache HARUS HAPUS catatan yang di-cache BAHKAN JIKA server nama turun dan tidak mungkin untuk mencari catatan lagi. Biasanya soft expiry berkisar antara 30 menit hingga 5 jam dan hard expiry biasanya antara 1-3 minggu.
11. Setelah pekerjaan yang melelahkan itu, ISP akhirnya memiliki catatan DNS terbaru dan dapat mengembalikannya kepada pelanggan broadband yang meminta, yang tidak tahu apa-apa tentang pekerjaan besar yang telah terjadi di belakang layar!

Proses ini diulangi untuk SETIAP catatan pencarian. Namun, hanya kueri pertama yang melakukan seluruh pekerjaan; IP nameserver akan di-cache setelah itu dan pertanyaan selanjutnya ke server DNS caching ISP akan dengan cepat dapat melompat ke langkah 8.

Sekarang, seperti untuk pengacakan langkah 8, ini bekerja pada tingkat rekor. Katakanlah pelanggan broadband ISP itu bertanya tentang catatan berikut:

• A foo.example.com
• A example.com
• Www.example.com
• MX example.com (pelanggan ISP tidak seharusnya meminta catatan ini, tetapi ini hanya contoh)

Setiap catatan akan ditangani sebagai "entitas" sendiri yang terpisah, yang ditembolokkan secara terpisah dan dicari. Jadi, katakanlah pelanggan dan ISP tidak pernah menemukan domain sebelumnya dan keduanya sama sekali tidak memiliki catatan cache. Pencarian mungkin sebagai berikut:

• Sebuah foo.example.com melalui ns1.example.com, lalu disimpan dalam cache ISP
• A example.com via ns3.example.com, lalu disimpan dalam cache ISP
• Www.example.com melalui ns2.example.com, lalu disimpan dalam cache ISP
• MX example.com via ns3.example.com, lalu disimpan dalam cache ISP

Setiap kali catatan dalam tembolok lunak kedaluwarsa, prosesnya diulangi, jadi Anda bahkan tidak tahu bahwa permintaan berikutnya untuk catatan itu akan menggunakan server yang sama lagi.

Oleh karena itu, ini adalah tujuan terbesar Anda untuk memastikan bahwa semua server DNS Anda sepenuhnya sinkron satu sama lain, dengan sempurna mencerminkan setiap catatan DNS di setiap server. Anda tidak pernah tahu server mana yang akan dipukul klien DNS dan Anda tidak dapat mengandalkan pesanan apa pun. Tidak ada hal seperti itu.

Selanjutnya, seperti yang disebutkan oleh Adam C, server DNS level server (example.com) sendiri dapat mengembalikan catatan NS dan mengacak urutannya. Sangat umum bagi server DNS biasa untuk mengacak catatan NS mereka dengan sedikit kemungkinan bahwa implementasi DNS yang buruk selalu memilih namserver yang dikembalikan pertama. Namun, nameserver ROOT TLD (disebutkan sebelumnya) tidak akan pernah secara acak daftar, dan daftar mereka adalah apa yang benar-benar penting ketika datang untuk menyelesaikan domain. Itu sebabnya sebagian besar implementasi memilih server acak dari daftar server nama, untuk menghindari selalu memukul server yang sama dan membebani berlebihan.

Baiklah, itulah primer Anda dalam cara DNS bekerja dan apa yang harus Anda ingat.

• Singkatnya: Perlakukan semua server DNS Anda seolah-olah mereka hanya satu server, jadikan itu tujuan tertinggi Anda seumur hidup untuk memastikan bahwa mereka semua sama mampu menjawab pertanyaan apa pun yang mungkin dilemparkan ke mereka.

Penafian: Tujuan yang lebih tinggi dalam hidup daripada mengelola DNS mungkin tersedia tetapi dijual secara terpisah, gunakan imajinasi Anda. ;-)