บัตรประจำตัวผู้ใต้บังคับบัญชา
เซิร์ฟเวอร์หลักจะใช้ระเบียน NS ระดับ Apex เพื่อระบุผู้ใต้บังคับบัญชา เมื่อข้อมูลเกี่ยวกับเนมเซิร์ฟเวอร์ที่เชื่อถือได้มีการเปลี่ยนแปลงข้อมูลดังกล่าวจะทำการโฆษณาผ่านDNS NOTIFYข้อความ ( RFC 1996 ) ให้กับเพื่อนร่วมงานทั้งหมดในรายการนั้น เซิร์ฟเวอร์เหล่านั้นจะโทรกลับพร้อมคำขอสำหรับSOAบันทึก (ซึ่งมีหมายเลขซีเรียล) และตัดสินใจว่าจะดึงสำเนาล่าสุดของโซนนั้นลงหรือไม่
- เป็นไปได้ที่จะส่งข้อความเหล่านี้ไปยังเซิร์ฟเวอร์ที่ไม่ได้ระบุไว้ใน
NSส่วน แต่ต้องมีคำสั่งกำหนดค่าเซิร์ฟเวอร์เฉพาะ (เช่นalso-notifyคำสั่งของ ISC BIND ) ระเบียน apex NS ประกอบด้วยรายการพื้นฐานของเซิร์ฟเวอร์เพื่อแจ้งเตือนภายใต้การกำหนดค่าเริ่มต้น
- เป็นที่น่าสังเกตว่าเซิร์ฟเวอร์รองจะส่งข้อความแจ้งเตือนให้แก่กันและกันโดยพิจารณาจาก
NSบันทึกเหล่านี้ซึ่งมักส่งผลให้เกิดการลงชื่อเข้าใช้ สิ่งนี้สามารถปิดใช้งานได้โดยสั่งให้เซิร์ฟเวอร์ส่งการแจ้งเตือนเฉพาะสำหรับโซนที่เป็นหลักสำหรับ (BIND:) notify master;หรือข้ามการNSแจ้งเตือนโดยสิ้นเชิงเพื่อแจ้งเตือนที่กำหนดไว้อย่างชัดเจนในการกำหนดค่า (ผูกnotify explicit;)
คำนิยามที่มีสิทธิ์
คำถามข้างต้นมีการเข้าใจผิด:
พวกเขาจะไม่ใช้แคชเซิร์ฟเวอร์ DNS เพื่อตรวจสอบเซิร์ฟเวอร์ที่มีสิทธิ์สำหรับโดเมน สิ่งนี้ได้รับการจัดการโดยกาว nameserver ซึ่งกำหนดไว้ที่ระดับนายทะเบียน นายทะเบียนไม่เคยใช้ข้อมูลนี้เพื่อสร้างบันทึกกาว
นี่เป็นข้อสรุปง่ายๆที่จะมาถึง แต่ไม่ถูกต้อง NSบันทึกและกาวบันทึกข้อมูล (เช่นที่กำหนดไว้ในบัญชีของนายทะเบียนของคุณ) ไม่ได้มีอำนาจ มีเหตุผลที่พวกเขาไม่สามารถพิจารณาว่า "มีสิทธิ์มากกว่า" มากกว่าข้อมูลที่อยู่บนเซิร์ฟเวอร์ที่มีการมอบอำนาจให้ สิ่งนี้ถูกเน้นโดยความจริงที่ว่าการอ้างอิงไม่มีการaaตั้งค่าสถานะ (คำตอบที่มีสิทธิ์)
เพื่อแสดง:
$ 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
โปรดสังเกตว่าการขาดaaในแฟล็กสำหรับการตอบกลับด้านบน ผู้อ้างอิงเองไม่มีอำนาจ ในทางกลับกันข้อมูลบนเซิร์ฟเวอร์ที่ถูกอ้างถึงนั้นมีสิทธิ์
$ 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.
ที่กล่าวว่าความสัมพันธ์นี้อาจสร้างความสับสนอย่างมากเนื่องจากไม่สามารถเรียนรู้เกี่ยวกับรุ่นที่มีสิทธิ์ของNSบันทึกเหล่านี้โดยไม่ต้องมีระเบียนที่ไม่มีสิทธิ์ที่NSกำหนดไว้ในด้านผู้ปกครองของการอ้างอิง จะเกิดอะไรขึ้นถ้าพวกเขาไม่เห็นด้วย?
- คำตอบสั้น ๆ คือ "พฤติกรรมที่ไม่สอดคล้อง"
- คำตอบยาวคือว่าเซิร์ฟเวอร์จะทุกอย่างต้นขั้วแรกออกจากการอ้างอิง (และกาว) บนแคชว่างเปล่า แต่ผู้ที่
NS, AและAAAAบันทึกในที่สุดอาจถูกแทนที่เมื่อพวกเขาได้รับการฟื้นฟู การรีเฟรชเกิดขึ้นเมื่อ TTLs ในบันทึกชั่วคราวเหล่านั้นหมดอายุหรือเมื่อมีคนร้องขอคำตอบสำหรับบันทึกเหล่านั้นอย่างชัดเจน
AและAAAAเรคคอร์ดสำหรับข้อมูลนอกเขต (เช่นเนมcomเซิร์ฟเวอร์ที่กำหนดกาวสำหรับข้อมูลนอกcomโซนเช่นexample.net) จะต้องถูกรีเฟรชอย่างแน่นอนเนื่องจากเป็นแนวคิดที่เข้าใจดีว่าเนมเซิร์ฟเวอร์ไม่ควรถูกพิจารณาว่าเป็นแหล่งข้อมูลที่เชื่อถือได้ของข้อมูลดังกล่าว . (RFC 2181)- เมื่อค่าของ
NSเรคคอร์ดแตกต่างกันระหว่างฝั่งพาเรนต์และชายด์ของการอ้างอิง (เช่นเนมเซิร์ฟเวอร์ที่ป้อนเข้าไปในแผงควบคุมของนายทะเบียนแตกต่างจากNSเร็กคอร์ดที่อาศัยอยู่บนเซิร์ฟเวอร์เดียวกันเหล่านั้น) พฤติกรรมที่มีประสบการณ์จะไม่สอดคล้องกันNSบันทึกถูกเพิกเฉยอย่างสมบูรณ์ นี่เป็นเพราะพฤติกรรมไม่ได้กำหนดไว้อย่างดีตามมาตรฐานและการใช้งานแตกต่างกันไประหว่างการใช้งานเซิร์ฟเวอร์แบบเรียกซ้ำ ในคำอื่น ๆพฤติกรรมที่สอดคล้องกันผ่านทางอินเทอร์เน็ตที่สามารถคาดหวังเฉพาะในกรณีที่คำจำกัดความ nameserver สำหรับโดเมนมีความสอดคล้องกันระหว่างผู้ปกครองและเด็กด้านของการอ้างอิง
ความยาวและสั้นของมันคือเซิร์ฟเวอร์ DNS แบบเรียกซ้ำทั่วทั้งอินเทอร์เน็ตจะเด้งกลับไปมาระหว่างจุดหมายหากบันทึกที่กำหนดไว้ในด้านต้นกำเนิดของผู้อ้างอิงไม่เห็นด้วยกับเวอร์ชันที่เชื่อถือได้ของบันทึกเหล่านั้น ในขั้นต้นข้อมูลที่มีอยู่ในการอ้างอิงจะเป็นที่ต้องการเท่านั้นที่จะถูกแทนที่ด้วยคำจำกัดความที่มีสิทธิ์ เนื่องจากแคชนั้นถูกสร้างขึ้นใหม่อย่างต่อเนื่องตั้งแต่เริ่มต้นผ่านอินเทอร์เน็ตจึงเป็นไปไม่ได้ที่อินเทอร์เน็ตจะสามารถใช้งานได้จริงในรุ่นเดียวกับการกำหนดค่านี้ หากบันทึกที่เชื่อถือได้กำลังทำบางสิ่งผิดกฎหมายตามมาตรฐานเช่นชี้NSบันทึกที่นามแฝงที่กำหนดโดยCNAMEสิ่งนี้ยากยิ่งขึ้นในการแก้ไขปัญหา โดเมนจะเป็นทางเลือกระหว่างการทำงานและการใช้งานไม่ได้สำหรับซอฟต์แวร์ที่ปฏิเสธการละเมิด (เช่นชื่อ ISC BIND / ชื่อ)
RFC 2181 §5.4.1ให้ตารางการจัดอันดับสำหรับความน่าเชื่อถือของข้อมูลนี้และทำให้เป็นที่ชัดเจนว่าข้อมูลแคชที่เกี่ยวข้องกับการอ้างอิงและกาวไม่สามารถส่งคืนเป็นคำตอบของคำขอที่ชัดเจนสำหรับบันทึกที่พวกเขาอ้างถึง
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.