Identifikasi bawahan
Catatan NS tingkat puncak digunakan oleh server master untuk mengidentifikasi bawahannya. Ketika data pada server nama otoritatif berubah, itu akan mengiklankan ini melalui DNS NOTIFYpesan ( RFC 1996 ) ke semua rekan-rekannya di daftar itu. Server-server itu pada gilirannya akan memanggil kembali dengan permintaan untuk SOAcatatan (yang berisi nomor seri), dan membuat keputusan apakah akan menarik salinan terbaru dari zona itu.
- Mungkin untuk mengirim pesan-pesan ini ke server yang tidak tercantum dalam
NSbagian ini, tetapi ini memerlukan arahan konfigurasi khusus server (seperti arahan ISC BIND also-notify). Catatan NS puncak terdiri dari daftar dasar server untuk memberi tahu di bawah konfigurasi default.
- Patut dicatat bahwa server sekunder juga akan saling mengirim pesan PEMBERITAHUAN berdasarkan
NScatatan ini , biasanya menghasilkan penolakan yang dicatat. Ini dapat dinonaktifkan dengan menginstruksikan server untuk hanya mengirim pemberitahuan untuk zona tempat mereka menjadi tuan (BIND:) notify master;, atau untuk melewatkan NSpemberitahuan berdasarkan sepenuhnya demi pemberitahuan yang secara eksplisit ditentukan dalam konfigurasi. (BIND: notify explicit;)
Definisi otoritatif
Pertanyaan di atas berisi kekeliruan:
Mereka tidak digunakan oleh caching server DNS untuk menentukan server otoritatif untuk domain. Ini ditangani oleh lem server nama, yang ditentukan pada tingkat registrar. Registrar tidak pernah menggunakan informasi ini untuk menghasilkan catatan lem.
Ini adalah kesimpulan yang mudah untuk dicapai, tetapi tidak akurat. The NScatatan dan data rekam lem (seperti yang didefinisikan dalam akun registrar Anda) tidak berwibawa. Masuk akal bahwa mereka tidak dapat dianggap "lebih otoritatif" daripada data yang berada di server yang didelegasikan kepada otoritas. Ini ditekankan oleh fakta bahwa referal tidak memiliki aaset flag (Jawaban Resmi).
Menggambarkan:
$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53
b.iana-servers.net. 172800 IN A 199.43.133.53
b.iana-servers.net. 172800 IN AAAA 2001:500:8d::53
Perhatikan kurangnya aatanda untuk jawaban di atas. Referensi itu sendiri tidak otoritatif. Di sisi lain, data pada server yang dirujuk bersifat otoritatif.
$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
Yang mengatakan, hubungan ini bisa sangat membingungkan karena tidak mungkin untuk belajar tentang versi otoritatif dari NScatatan - catatan ini tanpa catatan non-otoritatif yang NSditentukan pada sisi induk dari rujukan. Apa yang terjadi jika mereka tidak setuju?
- Jawaban singkatnya adalah "perilaku tidak konsisten".
- Jawaban panjang adalah bahwa nameserver akan awalnya rintisan semuanya off dari referral (dan lem) pada cache kosong, tetapi mereka
NS, Adan AAAAcatatan mungkin akhirnya akan digantikan ketika mereka segar. Penyegaran terjadi ketika TTL pada catatan sementara itu kedaluwarsa, atau ketika seseorang secara eksplisit meminta jawaban untuk catatan tersebut.
Adan AAAAcatatan untuk data di luar zona (yaitu comserver nama yang mendefinisikan lem untuk data di luar comzona, seperti example.net) pasti akan disegarkan, karena merupakan konsep yang dipahami dengan baik bahwa server nama tidak boleh dianggap sebagai sumber otorisasi informasi tersebut . (RFC 2181)- Ketika nilai
NScatatan berbeda antara sisi induk dan anak dari rujukan (seperti server nama yang dimasukkan ke panel kontrol registrar berbeda dari NScatatan yang hidup di server yang sama), perilaku yang dialami akan tidak konsisten, hingga dan termasuk anak NScatatan diabaikan sepenuhnya. Ini karena perilaku tidak didefinisikan dengan baik oleh standar, dan implementasinya bervariasi antara implementasi server rekursif yang berbeda. Dengan kata lain, perilaku konsisten di internet hanya dapat diharapkan jika definisi server nama untuk domain konsisten antara sisi induk dan anak dari rujukan .
Panjang dan pendeknya adalah bahwa server DNS rekursif di seluruh internet akan bangkit kembali di antara tujuan jika catatan yang ditetapkan pada sisi induk rujukan tidak setuju dengan versi otoritatif dari catatan tersebut. Awalnya data yang ada dalam rujukan akan lebih disukai, hanya untuk digantikan oleh definisi otoritatif. Karena cache terus-menerus dibangun kembali dari awal di internet, tidak mungkin bagi internet untuk menyelesaikan satu versi kenyataan dengan konfigurasi ini. Jika catatan otoritatif melakukan sesuatu yang ilegal menurut standar, seperti menunjuk NScatatan pada alias yang didefinisikan oleh aCNAME, ini semakin sulit untuk dipecahkan; domain akan bergantian antara berfungsi dan rusak untuk perangkat lunak yang menolak pelanggaran. (yaitu ISC BIND / bernama)
RFC 2181 §5.4.1 menyediakan tabel peringkat untuk kepercayaan data ini, dan membuatnya eksplisit bahwa data cache yang terkait dengan referensi dan lem tidak dapat dikembalikan sebagai jawaban untuk permintaan eksplisit untuk catatan yang mereka rujuk.
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
<snip>
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.