Mengapa DNS bekerja seperti itu?

Ini adalah Pertanyaan Canonical tentang DNS (Layanan Nama Domain).

Jika pemahaman saya tentang sistem DNS benar, registri .com memegang tabel yang memetakan domain (www.example.com) ke server DNS.

1. Apa keuntungannya? Mengapa tidak memetakan langsung ke alamat IP?

2. Jika satu-satunya catatan yang perlu diubah ketika saya mengkonfigurasi server DNS untuk menunjuk ke alamat IP yang berbeda, terletak di server DNS, mengapa prosesnya tidak instan?

3. Jika satu-satunya alasan penundaan adalah cache DNS, apakah mungkin untuk mem-bypassnya, jadi saya bisa melihat apa yang terjadi secara real time?

Sebenarnya, ini lebih rumit dari itu - daripada satu "registry pusat (yang) memegang tabel yang memetakan domain (www.mysite.com) ke server DNS", ada beberapa lapisan hierarki

Ada registri pusat (Server Akar) yang hanya berisi satu set kecil entri: NS (nameserver) catatan untuk semua domain tingkat atas - .com, .net, .org, .uk, .us, .au, dan sebagainya.

Server-server itu hanya berisi catatan NS untuk tingkat berikutnya turun Untuk memilih salah satu contoh, nameserver untuk .ukdomain hanya memiliki entri untuk .co.uk, .ac.ukdan zona tingkat kedua lainnya digunakan di Inggris.

Server-server itu hanya berisi catatan NS untuk tingkat berikutnya turun - untuk melanjutkan contoh, mereka memberi tahu Anda di mana untuk menemukan catatan NS google.co.uk. Di server-server itulah akhirnya Anda akan menemukan pemetaan antara nama host www.google.co.ukdan alamat IP.

Sebagai kerutan tambahan, setiap lapisan juga akan menyajikan catatan 'rekat'. Setiap catatan NS memetakan domain ke nama host - misalnya, catatan NS untuk .ukdaftar nsa.nic.uksebagai salah satu server. Untuk sampai ke level berikutnya, kita perlu mencari tahu data NS untuk nic.ukare, dan mereka ternyata menyertakan nsa.nic.ukjuga. Jadi sekarang kita perlu mengetahui IP nsa.nic.uk, tetapi untuk mengetahuinya kita perlu membuat query nsa.nic.uk, tapi kita tidak bisa membuat query sampai kita tahu IP untuk nsa.nic.uk...

Untuk mengatasi kesulitan ini, server untuk .ukmenambahkan catatan A nsa.nic.ukke ADDITIONAL SECTIONdalam respons (respons di bawah ini dipangkas untuk singkatnya):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Tanpa catatan lem tambahan ini, kami tidak akan pernah dapat menemukan server nama nic.uk.dan karenanya kami tidak akan pernah dapat mencari domain yang di-host di sana.

Untuk kembali ke pertanyaan Anda ...

a) Apa keuntungannya? Mengapa tidak memetakan langsung ke alamat IP?

Untuk satu hal, ini memungkinkan pengeditan untuk setiap zona individu untuk didistribusikan. Jika Anda ingin memperbarui entri www.mydomain.co.uk, Anda hanya perlu mengedit informasi mydomain.co.ukdi server nama Anda. Tidak perlu memberi tahu .co.ukserver pusat , atau .ukserver, atau server nama root. Jika hanya ada satu registry pusat yang memetakan semua level hingga ke hierarki yang harus diberitahukan tentang setiap perubahan satu entri DNS sepanjang rantai, itu akan benar-benar dibanjiri dengan lalu lintas.

Sebelum 1982, ini sebenarnya bagaimana resolusi nama terjadi. Satu registry pusat diberitahu tentang semua pembaruan, dan mereka mendistribusikan file yang disebut hosts.txtyang berisi nama host dan alamat IP setiap mesin di internet. Versi baru dari file ini diterbitkan setiap beberapa minggu, dan setiap mesin di internet harus mengunduh salinan baru. Jauh sebelum tahun 1982, ini mulai menjadi masalah, dan karena itu DNS diciptakan untuk menyediakan sistem yang lebih terdistribusi.

Untuk hal lain, ini akan menjadi Single Point of Failure - jika registri pusat tunggal turun, seluruh internet akan offline. Memiliki sistem terdistribusi berarti bahwa kegagalan hanya memengaruhi bagian kecil dari internet, bukan keseluruhannya.

(Untuk memberikan redundansi tambahan, sebenarnya ada 13 kelompok server terpisah yang melayani zona root. Setiap perubahan pada catatan domain tingkat atas harus didorong ke 13; bayangkan harus mengoordinasikan pembaruan ke-13 dari mereka untuk setiap perubahan tunggal ke nama host mana saja di dunia ...)

b) Jika satu-satunya catatan yang perlu diubah ketika saya mengkonfigurasi server DNS untuk menunjuk ke alamat IP yang berbeda terletak di server DNS, mengapa prosesnya tidak instan?

Karena DNS menggunakan banyak caching untuk mempercepat dan mengurangi beban di NSes. Tanpa caching, setiap kali Anda mengunjungi google.co.ukkomputer Anda harus pergi ke jaringan untuk mencari server .uk, lalu .co.uk, lalu .google.co.uk, lalu www.google.co.uk. Jawaban-jawaban itu sebenarnya tidak banyak berubah, jadi mencari mereka setiap waktu adalah buang-buang waktu dan lalu lintas jaringan. Sebaliknya, ketika NS mengembalikan catatan ke komputer Anda, itu akan mencakup nilai TTL, yang memberitahu komputer Anda untuk men-cache hasil selama beberapa detik.

Misalnya, catatan NS untuk .ukmemiliki TTL 172800 detik - 2 hari. Google bahkan lebih konservatif - catatan NS untuk google.co.ukmemiliki TTL 4 hari. Layanan yang mengandalkan kemampuan untuk memperbarui dengan cepat dapat memilih TTL yang jauh lebih rendah - misalnya, telegraph.co.ukmemiliki TTL hanya 600 detik pada catatan NS mereka.

Jika Anda ingin pembaruan zona Anda hampir instan, Anda dapat memilih untuk menurunkan TTL Anda sejauh yang Anda inginkan. Semakin rendah pengaturan Anda, semakin banyak lalu lintas yang akan dilihat server Anda, karena klien lebih sering menyegarkan catatan mereka. Setiap kali klien harus menghubungi server Anda untuk melakukan kueri, ini akan menyebabkan beberapa kelambatan karena lebih lambat daripada mencari jawaban pada cache lokal mereka, jadi Anda juga ingin mempertimbangkan pertukaran antara pembaruan cepat dan layanan cepat.

c) Jika satu-satunya alasan penundaan adalah cache DNS, apakah mungkin untuk mem-bypassnya, jadi saya bisa melihat apa yang terjadi secara real time?

Ya, ini mudah jika Anda menguji secara manual dengan digatau alat serupa - cukup beri tahu server mana yang harus dihubungi.

Berikut ini contoh respons yang di-cache:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

Bagian flag di sini tidak mengandung aaflag, jadi kita dapat melihat bahwa hasil ini berasal dari cache daripada langsung dari sumber yang otoritatif. Faktanya, kita dapat melihat dari 97.107.133.4mana asalnya , yang merupakan salah satu dari DNS resolver lokal Linode. Fakta bahwa jawabannya disajikan dari cache yang sangat dekat dengan saya berarti butuh 0msec bagi saya untuk mendapatkan jawaban; tetapi seperti yang akan kita lihat sebentar lagi, harga yang saya bayar untuk kecepatan itu adalah bahwa jawabannya hampir 5 menit kedaluwarsa.

Untuk memintas resolver Linode dan langsung ke sumbernya, cukup pilih salah satu NSes itu dan minta dig untuk menghubungi secara langsung:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

Anda dapat melihat bahwa kali ini, hasilnya disajikan langsung dari sumber - perhatikan aabenderanya, yang menunjukkan bahwa hasil tersebut berasal dari sumber yang berwenang. Dalam contoh saya sebelumnya, hasilnya berasal dari cache lokal saya, sehingga tidak memiliki aaflag. Saya dapat melihat bahwa sumber otoritatif untuk domain ini menetapkan TTL 600 detik. Hasil yang saya dapatkan sebelumnya dari cache lokal memiliki TTL hanya 319 detik, yang memberitahu saya bahwa mereka telah duduk di cache selama (600-319) detik - hampir 5 menit - sebelum saya melihatnya.

Meskipun TTL di sini hanya 600 detik, beberapa ISP akan berusaha untuk mengurangi lalu lintas mereka lebih jauh dengan memaksa resolver DNS mereka untuk men-cache hasil lebih lama - dalam beberapa kasus, selama 24 jam atau lebih. Itu adalah cara tradisional (dengan cara kita-tidak-tahu-jika-ini-benar-benar-perlu-tapi-mari-aman) untuk mengasumsikan bahwa setiap perubahan DNS yang Anda buat tidak akan terlihat di mana-mana di internet selama 24-48 jam.

a) Jumlah IP -> pemetaan nama host di dunia BENAR-BENAR besar. Sistem ini mendistribusikan tanggung jawab meng-hosting semua subdomain dan data MX dan setiap data DNS lainnya kepada pemilik nama domain. Ini hampir merupakan titik dari nama domain. .comdipegang oleh satu registri di mana karena .ukdapat dipegang oleh yang lain. Demikian juga example.comdan otherexample.comdapat di-host secara terpisah sehingga sumber daya dapat didistribusikan.

b) Ini di-cache, yang mengurangi jumlah klik pada host DNS Anda menjadi sebagian kecil dari yang seharusnya. Secara default, catatan tinggal 2 hari di cache sebelum dibuang. Ini dapat diubah dengan mengubah TTL (waktu untuk hidup) dari catatan.

c) Anda dapat secara efektif menghentikan catatan yang di-cache dengan menetapkan TTL yang sangat singkat. Ini TIDAK disarankan kecuali Anda menggunakannya untuk DNS dinamis. Caching menjatuhkan banyak hit pada server DNS. Untuk memilih nomor yang dapat ditebak, kita berbicara tentang menjatuhkan 95% dari permintaan.

Jika Anda menggunakan sistem * nix, unduh salinan djbdns Dan Bernstein dari http://cr.yp.to/djbdns.html dan jalankan program dnstrace untuk melihat bagaimana sistem kueri rekursif bekerja. Sangat informatif.

a) Jumlah kemungkinan nama domain terlalu besar untuk ditangani oleh satu server. Dan tidak hanya .com; ada .net, .org, .se, .info, dan sejumlah lainnya. Selain itu, Anda dapat mendelegasikan tanggung jawab untuk subdomain (yang memang efektif com). DNS yang kurang tersentralisasi membuat semuanya lebih mudah untuk dikelola.

b) Mesin sepanjang jalan dari pengguna ke Anda memiliki cache DNS untuk meminimalkan jumlah permintaan yang dibutuhkan. Ini mencegah, misalnya, mengirim spam ke jaringan dengan permintaan alamat "serverfault.com" setiap kali Anda mendapatkan halaman dari SF. Server-server itu bahkan dapat menembolok hasil "domain tidak ada", itulah sebabnya mengapa diperlukan beberapa saat agar domain baru muncul.

c) Meskipun Anda dapat menonaktifkan cache, sering kali ada server DNS lain antara mesin Anda dan server DNS domain.com Anda. Server DNS ISP Anda, misalnya, akan mencoba melakukan cache sebanyak mungkin. Satu-satunya catatan yang diperbarui secara relatif cepat di internet adalah catatan dengan TTL pendek (yang pada dasarnya mengatakan "Saya hanya berlaku selama beberapa detik; setelah itu, tanyakan lagi pada saya untuk info terkini"). Alasan TTL sangat tinggi, adalah agar server yang bertanggung jawab atas domain dapat menurunkan sebagian pekerjaan ke server lain. Jika Anda memiliki semua jaring yang menghubungi satu atau dua server DNS rinky-dink Anda untuk setiap klik ke situs web Anda, mereka akan sangat tidak dapat digunakan ketika seseorang melihat situs Anda di /., Digg, dll.