Mari kita jabarkan sedikit.
Catatan NS di zona TLD (misalnya, example.com NS ...dalam com) adalah catatan delegasi .
Catatan A dan AAAA di zona TLD (misalnya, ns1.example.com A ...dalam com) adalah catatan lem .
Catatan NS di zona itu sendiri (yaitu, example.com NS ...di example.com) adalah catatan otoritas .
Catatan A dan AAAA di zona itu sendiri ( ns1.example.com A ...di example.com) adalah catatan alamat , jelas dan sederhana.
Ketika resolver (rekursif) dimulai tanpa ada cache data zona Anda dan hanya cache zona root (yang digunakan untuk mem-bootstrap proses resolusi nama), maka pertama-tama akan pergi ke ., kemudian com.. The comserver akan merespon dengan bagian respon otoritas yang pada dasarnya mengatakan "Saya tidak tahu, tapi lihat di sini untuk seseorang yang tidak tahu", sama dengan server untuk .do tentang com. Respons kueri ini tidak resmi dan tidak termasuk bagian jawaban yang terisi. Ini mungkin juga termasuk yang disebut tambahanbagian yang memberikan pemetaan alamat untuk nama host apa pun yang diketahui oleh server tertentu (baik dari catatan lem atau, dalam hal resolver rekursif, dari data yang sebelumnya di-cache). Penyelesai akan mengambil respons delegasi ini, menyelesaikan nama host dari catatan NS jika perlu, dan melanjutkan ke kueri server DNS yang otoritasnya telah didelegasikan. Proses ini dapat diulang beberapa kali jika Anda memiliki hierarki delegasi yang mendalam, tetapi akhirnya menghasilkan respons kueri dengan set flag "jawaban otoritatif" .
Penting untuk dicatat bahwa resolver (umumnya, mudah-mudahan) tidak akan mencoba menjabarkan nama host yang diputuskan untuk menanyakannya sepotong demi sepotong, tetapi hanya akan mengirimkannya secara keseluruhan ke server "terbaik" yang diketahuinya. Karena rata-rata server nama otoritatif di Internet tidak otoritatif untuk sebagian besar nama DNS yang valid, responsnya akan berupa respons delegasi non-otoritatif yang menunjuk ke beberapa server DNS lainnya.
Sekarang, server tidak harus disebutkan dalam delegasi atau catatan otoritas di mana saja untuk otoritatif untuk suatu zona. Pertimbangkan misalnya kasus server master pribadi; dalam hal ini terdapat server DNS yang otoritatif yang hanya diketahui oleh administrator server slave DNS untuk zona tersebut. Server DNS adalah otoritatif untuk suatu zona jika, melalui beberapa mekanisme, menurut pendapatnya memiliki pengetahuan yang lengkap dan akurat tentang zona tersebut. Server DNS yang biasanya otoritatif dapat, misalnya, menjadi non-otoritatif jika server master yang dikonfigurasi tidak dapat dijangkau dalam batas waktu yang ditentukan sebagai waktu kedaluwarsa dalam catatan SOA.
Hanya jawaban otoritatif yang harus dianggap sebagai respons kueri yang tepat; yang lainnya adalah delegasi, atau semacam kesalahan. Delegasi ke server non-otoritatif disebut delegasi "lumpuh", dan berarti resolver harus mundur satu langkah dan mencoba beberapa server DNS lain yang bernama. Jika tidak ada server nama yang dapat dijangkau yang berwibawa di delegasi, maka resolusi nama gagal (jika tidak, itu hanya akan lebih lambat dari biasanya).
Ini semua penting karena data non-otoritatif tidak boleh di-cache . Bagaimana mungkin, karena server non-otoritatif tidak memiliki gambaran lengkap? Jadi server otoritatif harus, atas kemauannya sendiri, dapat menjawab pertanyaan "siapa yang seharusnya berwibawa, dan untuk apa?". Itulah informasi yang disediakan oleh catatan NS dalam zona.
Ada sejumlah kasus tepi di mana ini benar-benar dapat membuat perbedaan serius, terutama berpusat di sekitar beberapa label nama host di dalam satu zona (mungkin cukup umum misalnya dengan zona DNS terbalik terutama untuk rentang IP dinamis besar) atau ketika daftar server nama berbeda antara zona induk dan zona yang dimaksud (yang kemungkinan besar adalah kesalahan, tetapi dapat dilakukan dengan sengaja juga).
Anda dapat melihat bagaimana ini bekerja dengan sedikit lebih detail menggunakan digdan +norec(jangan meminta rekursi) dan @fitur server specifier. Berikut ini adalah ilustrasi tentang cara kerja server DNS penyelesaian aktual. Permintaan untuk catatan A untuk unix.stackexchange.commemulai misalnya a.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Perhatikan baik- flagsbaik perhitungan jumlah dan per bagian. qradalah Query Response dan aamerupakan Authoritative Answer. Perhatikan bahwa Anda hanya didelegasikan ke comserver. Secara manual ikuti delegasi itu (dalam kehidupan nyata penyelesai rekursif akan menggunakan alamat IP dari bagian tambahan jika disediakan, atau memulai resolusi nama terpisah dari salah satu server nama yang bernama jika tidak ada IP yang disediakan dalam respons delegasi, tetapi kami akan lewati bagian itu dan kembali saja ke resolver normal sistem operasi untuk singkatnya contoh):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Sekarang Anda melihat bahwa stackexchange.comitu didelegasikan kepada (antara lain) ns1.serverfault.com, dan Anda masih belum mendapatkan jawaban yang resmi. Sekali lagi ikuti delegasi:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
Bingo! Kami mendapat jawaban, karena aaflag sudah diatur, dan kebetulan berisi alamat IP seperti yang kami harapkan. Sebagai tambahan, perlu dicatat bahwa setidaknya pada saat saya menulis posting ini, daftar server nama yang didelegasikan-ke dan terdaftar-otoritas berbeda, menunjukkan bahwa keduanya tidak perlu identik. Apa yang saya contohkan di atas pada dasarnya adalah pekerjaan yang dilakukan oleh setiap resolver, kecuali setiap resolver praktis juga akan menyimpan respons cache sepanjang jalan sehingga tidak harus menekan server root setiap kali.
Seperti yang dapat Anda lihat dari contoh di atas, catatan delegasi dan lem memiliki tujuan yang berbeda dari otoritas dan catatan alamat di zona itu sendiri.
Caching, menyelesaikan nama server juga umumnya akan melakukan beberapa pemeriksaan kewarasan pada data yang dikembalikan untuk melindungi terhadap keracunan cache. Misalnya, mungkin menolak untuk menembolokkan jawaban yang menamai server otoritatif untuk comdari sumber selain yang telah dinamai oleh zona induk sebagai didelegasikan ke untuk com. Rinciannya tergantung pada server tetapi tujuannya adalah untuk cache sebanyak mungkin sementara tidak membuka pintu gudang yang memungkinkan server nama acak di Internet untuk menimpa catatan delegasi untuk apa pun yang tidak secara resmi di bawah "yurisdiksinya".