Mengapa DNS bekerja seperti itu?

40

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.

Apa keuntungannya? Mengapa tidak memetakan langsung ke alamat IP?
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?
Jika satu-satunya alasan penundaan adalah cache DNS, apakah mungkin untuk mem-bypassnya, jadi saya bisa melihat apa yang terjadi secara real time?

domain-name-system

— sabof
sumber

18

Untuk semua orang yang mencoba melakukan migrasi / tutup pertanyaan ini: Biarkan di sini. Ia memiliki rumah di sini, tempat ia dapat dicintai dan dirawat dengan lembut. Dan kita dapat mengarahkan semua pertanyaan "Bagaimana Cara Kerja DNS" di sini sebagai jawaban kanonik, karena yang ini dijawab dengan sangat baik.

— Mark Henderson

You can not able full understand DNS unless you are name Paul Mockapetris, Paul Vixie or Cricket Liu. twitter.com/DEVOPS_BORAT/status/249006925767909376

— Anthony Hatzopoulos

87

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.

— James Polley
sumber

3

+1 Itulah salah satu penjelasan yang luar biasa. Pasti akan mem-bookmark ini!

— Trollhorn

3

Jawaban sebenarnya untuk apakah respons DNS berasal dari cache atau tidak ada di bagian "tanda" pada jawaban. Tidak ada alasan teknis mengapa seseorang tidak dapat menetapkan TTL, katakanlah, 319 detik. Sebaliknya, cari aa(jawaban otoritatif) flagdalam respons. Jika aaada, jawabannya datang langsung dari server nama otoritatif. (Jika tidak ada, jawabannya mungkin masih segar; beberapa server nama rekursif menghapus aabendera sebelum meneruskan respons ke resolver klien.)

— a CVn

3

Anda harus mencatat bahwa beberapa ISP akan menyimpan catatan DNS lebih lama dari TTL mengatakan bahwa mereka harus, sehingga bahkan dengan TTL yang sangat singkat Anda tidak dapat menjamin bahwa semua di situs pengunjung akan mendapatkan IP yang benar untuk satu atau dua hari setelah Anda pindah. sebuah tempat.

— Dan Neely

2

@JamesPolley ada kesalahan (kecil) dalam penjelasan Anda dengan penggunaan .ukserver. Saat ini domain tingkat kedua yang dikelola Nominet berada di server yang sama dengan uk., jadi permintaan untuk example.co.ukke ukserver akan segera menerima delegasi tanpa harus terlebih dahulu melalui delegasi ke co.ukserver.

— Alnitak

1

Perhatikan bahwa +traceopsi dig akan meminta server nama yang Anda konfigurasikan untuk server nameserver root, sehingga ia dapat mulai mencari. Jika server nama lokal Anda dnsmasq(seperti pada Ubuntu), itu tidak mendukung ini, jadi Anda akan mendapatkan kesalahan. Gunakan dig +trace @8.8.8.8 www.example.com. 8.8.8.8 adalah layanan DNS publik Google. Gunakan 1.1.1.1 untuk yang setara dengan Cloudflare.

— Roger Lipscombe

9

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.

— Philip Couling
sumber

Mengenai 'C', berhati-hatilah. Setel agar TTL cukup rendah dan server DNS Anda mungkin dipalu. Bukan masalah besar jika orang lain selain Anda yang menangani DNS.

— Publiccert

Jadi jika bukan karena subdomain, tidak akan ada banyak keuntungan

— sabof

4

Perhapse, tetapi ingat bahkan yourdomain.comadalah subdomain dari .com. Jika itu hanya satu "file host" besar (seperti sebelum DNS dan elf masih berjalan di tengah bumi) maka ya. Anda hanya memiliki satu file besar dan semua orang akan men-cache itu.

— Philip Couling

3

DNS namespace adalah datar, tanpa delegasi, untuk waktu yang lama; dan itu dilaksanakan sebagai satu daftar, yang diselenggarakan di satu tempat. Itu menjadi tidak bisa dijalankan dan digantikan oleh DNS pada tahun 1982 ...

— James Polley

1

@ mfinni, Ya, itu "sistem nama domain", bukan "sistem nama terdistribusi" atau semacamnya. Tentu saja itu dirancang agar dapat didistribusikan, tetapi tidak ada yang mengatakan bahwa Anda benar - benar harus menjalankannya dengan cara itu. Untuk beberapa jaringan kantor kecil tanpa konektivitas global, memiliki semua yang ada di zona root (atau TLD tunggal seperti local) mungkin masuk akal dalam jumlah terbatas.

— CVn

3

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.

— mikebabcock
sumber

Apakah ini akan memungkinkan saya untuk melihat efek perubahan konfigurasi secara instan?

— sabof

dnstrace (biasanya melalui dnstracesort) memberikan banyak detail tentang konfigurasi DNS untuk setiap domain dan permintaan yang Anda buat. Jika server telah membuat perubahan, mereka akan menunjukkan perubahan dan bagaimana itu telah diperbanyak. Mereka sangat baik untuk melacak kesalahan propagasi juga.

— mikebabcock

3

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.

— cao
sumber

(C) Anda salah. Ini adalah kesalahpahaman luas tentang DNS. Tidak ada rantai server - mesin lokal ke router ke ISP ke ... - masing-masing menghubungi baris berikutnya. Permintaan beralih dari klien DNS (pustaka), melalui satu server DNS proksi penyelesaian tunggal , ke nol atau lebih server DNS konten. Kecuali keberadaan penerusan server DNS proksi, hanya itu .

— JdeBP

2

@JdeBP: Ini adalah "kesalahpahaman luas" karena sejauh yang saya lihat di dunia nyata, itu sebagian besar benar . Jika Anda mendapatkan alamat Anda melalui DHCP, seperti halnya semua orang melakukannya, maka Anda hampir pasti diberi alamat server DNS yang seharusnya Anda gunakan. Yang, di jaringan rumah, hampir selalu merupakan router - yang pada dasarnya meneruskan ke DNS ISP Anda. Dan dalam jaringan bisnis kecil, biasanya pengontrol domain - yang, sekali lagi, biasanya meneruskan ke DNS ISP. Pada umumnya pada saat itulah iteratif mengambil alih.

— cao

Anda perlu melihat lebih banyak dari dunia nyata jika Anda berpikir "sebagian besar benar" cocok sekali. Saya sebenarnya menyebut proksi penerusan sebagai satu-satunya item tambahan. Namun, Anda melebih-lebihkan penggunaannya dalam jaringan bisnis; dan memang melebih-lebihkan berapa banyak mengubah pengontrol domain mereka dari default, yang (setelah satu telah menghapus zona root) server DNS penyelesaian menggunakan petunjuk root. Kesalahan dasar Anda dalam (c) tetap tidak diperbaiki. Menonaktifkan cache tidak secara ajaib mengungkapkan cache "di belakang" itu. DNS tidak berfungsi seperti itu. Jika Anda tidak salah paham, maka Anda salah mengartikannya.

— JdeBP

Faktanya adalah, jika Anda menonaktifkan cache pada mesin lokal Anda, Anda masih melihat hasil yang di-cache oleh server DNS jaringan lokal Anda. Dan jika Anda menonaktifkannya, Anda masih perlu khawatir tentang cache ISP Anda. Apakah Anda menerima itu sebagai kasus umum atau tidak, itu adalah kasus yang saya lihat hampir setiap waktu - yang membuatnya cukup umum untuk layak disebut.

— cHao

@ cHao sebagian besar server DNS CPE hanya "meneruskan" dan jangan cache.

— Alnitak