Apa peran catatan NS di puncak domain DNS?

21 
$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

Peran catatan NS di bawah puncak domain dipahami dengan baik; mereka ada untuk mendelegasikan wewenang untuk subdomain ke server nama lain. Contoh-contoh di atas akan mencakup catatan NS untuk sub1dan sub2. Ini memungkinkan server nama untuk membagikan rujukan untuk bagian-bagian dari domain yang tidak dianggap otoritatif untuknya.

Tujuan catatan NS di puncak domain, ns1dan ns2dalam hal ini, tampaknya kurang dipahami oleh internet secara luas. Pemahaman saya (yang mungkin tidak holistik) adalah sebagai berikut:

  1. 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.
  2. Mereka tidak digunakan untuk mendelegasikan otoritas untuk seluruh domain ke server nama lain. Mencoba melakukannya dengan perangkat lunak seperti ISC BIND tidak akan menghasilkan perilaku rujukan "yang diharapkan" sama sekali, karena server nama akan terus menganggap dirinya otoritatif untuk zona tersebut.
  3. Mereka tidak digunakan oleh server nama untuk menentukan apakah harus mengembalikan tanggapan otoritatif ( AAset bendera) atau tidak; perilaku itu ditentukan oleh apakah perangkat lunak disuruh menjadi master atau budak untuk zona tersebut. Sebagian besar perangkat lunak nameserver akan dengan senang hati melayani catatan NS puncak yang tidak setuju dengan informasi yang terkandung oleh catatan lem hulu, yang pada gilirannya akan menyebabkan situs web validasi DNS yang terkenal untuk menghasilkan peringatan untuk domain.

Dengan ini masalahnya, apa yang tersisa dengan kita? Mengapa kita mendefinisikan informasi ini jika sepertinya tidak dikonsumsi oleh caching server DNS di internet secara luas?

domain-name-system ns-record glue-record Andrew B
sumber

Jawaban:

21

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.
Andrew B
sumber
Jawaban yang ditulis dengan baik! Saya tidak setuju dengan jawaban Anda "panjang dan pendek". Penggunaan utama DNS di internet adalah tentang mendapatkan IP host, dengan demikian permintaan "A". Penyelesai DNS akan selalu menerima dan mengganti rujukan untuk mendapatkan Respons "A" yang Berwenang. Dan dia akan "selalu" hanya menyimpan catatan referensi. Satu-satunya waktu catatan akan diganti adalah ketika permintaan eksplisit masuk untuk "example.com IN NS". Kemudian resolver akan menanyakan server di lokasi rujukan. Dan respons AR itu akan menggantikan respons rujukan yang di-cache (hanya untuk TTL dari catatan itu).
Wasted_Coder
Saya mungkin salah menurut jawaban oleh @BillThor. Saya mendasarkan alasan saya pada kenyataan bahwa jika server DNS me-refresh entri NS-cache untuk example.com dari respons NS otoritatif (sekarang kedaluwarsa). Ini akan memutus rantai DNS. Karena sekarang macet di loop di mana sementara server NS (lama) terus membalas, itu tidak akan memperhitungkan perubahan pada server DNS puncak di atas (pendaftar). Seperti dalam kasus Anda memindahkan server DNS tetapi tidak memperbarui atau menjadikan server DNS lama offline. Atau apakah "masalah" ini benar-benar terjadi hari ini?
Wasted_Coder
@ Terbuang Saya juga tidak setuju dengan komentar pertama Anda karena banyak asumsi yang dibuat. Karena perilaku tidak secara eksplisit dituangkan oleh standar, itu sebenarnya implementasi spesifik. Presentasi ini berusia 6 tahun (mulai dari slide # 11), tetapi tetap jelas; preferensi server nama orang tua dan anak akan bervariasi. Selain itu, Anda hanya dapat mengandalkan persyaratan RFC 2181.
Andrew B
Saya pikir titik perhatian saya adalah sekitar jika entri cache NS pemecah mencapai TTL = 0 katakan misalnya example.com. Dan perlu mencari entri host baru juga belum di-cache, katakan untuk new.example.com. Sekarang perlu server NS untuk example.com dan karena salinan yang di-cache-nya sudah kadaluwarsa, akan lebih buruk untuk tetap mencoba menekan server NS yang "kadaluwarsa" hanya untuk melihat apakah masih merespons. Ini harus HARUS memeriksa dengan leluhur berikutnya, dengan demikian. Com NS untuk arah. Ini berarti bahwa catatan NS leluhur akan menang sebagian besar waktu (sampai permintaan NS diproses).
Wasted_Coder
@Wasted Mulai dari slide # 11 dan perhatikan tiga pola: child centric non-sticky ( PPPCCCPPPCCC...), child centric sticky ( PPPCCCCCC...), dan parent sticky ( PPPPPP...). Anak-sentris non-lengket sejauh ini yang paling umum, dan lengket sentris anak sebenarnya lebih umum daripada lengket orang tua. Klien memang akan bolak-balik antara dua versi realitas jika data NS pada anak dan orang tua tidak dalam perjanjian kecuali perangkat lunak penyelesai adalah lengket orang tua, yang merupakan hasil yang paling tidak mungkin.
Andrew B
3

NS mencatat zona yang didelegasikan memberikan kelengkapan definisi domain. Server NS sendiri akan bergantung pada file zona. Mereka tidak diharapkan untuk mencoba menemukan diri mereka sendiri dengan melakukan kueri rekursif dari server root. Catatan NS dalam file zona menyediakan sejumlah fungsi lainnya ..

Server cache dapat menyegarkan daftar server nama dengan menanyakan server nama dari cache-nya. Selama server caching mengetahui alamat server nama, server caching akan menggunakannya daripada mencari rekam NS yang tepat secara rekursif.

Saat memindahkan server nama, penting untuk memperbarui server nama lama serta server nama baru. Ini akan mencegah pemadaman atau inkonsistensi yang akan terjadi ketika kedua definisi zona tidak sinkron. Catatan yang diperbarui pada akhirnya akan di-refresh oleh server mana pun yang telah menyimpan catatan NS. Ini akan menggantikan daftar server nama yang di-cache.

Catatan NS juga membantu mengonfirmasi kebenaran konfigurasi DNS. Perangkat lunak validasi akan sering memverifikasi bahwa definisi server nama zona pendelegasian cocok dengan yang disediakan oleh zona tersebut. Pemeriksaan ini dapat dilakukan pada semua server nama. Ketidakcocokan dapat mengindikasikan kesalahan konfigurasi.

Memiliki catatan NS memungkinkan untuk zona (lokal) terputus. Ini mungkin sub-domain dari domain terdaftar, atau domain yang sama sekali baru (tidak disarankan karena perubahan TLD). Host yang menggunakan server nama sebagai server nama mereka akan dapat menemukan zona yang tidak dapat dijangkau dengan berulang dari server root. Server nama lain dapat dikonfigurasi untuk melihat ke server nama untuk zona lokal.

Dalam hal DNS split (internal / eksternal), mungkin diinginkan untuk memiliki server DNS yang berbeda. Dalam hal ini daftar NS (dan kemungkinan data lainnya) akan berbeda, dan catatan NS dalam file zona akan mencantumkan daftar server nama yang sesuai.

BillThor
sumber