अधीनस्थ पहचान
एपेक्स स्तर एनएस रिकॉर्ड का उपयोग एक मास्टर सर्वर द्वारा अपने अधीनस्थों की पहचान करने के लिए किया जाता है। जब एक आधिकारिक नेमसर्वर पर डेटा बदलता है, तो वह उस सूची के सभी साथियों के लिए DNS NOTIFYसंदेशों ( RFC 1996 ) के माध्यम से इसका विज्ञापन करेगा । वे सर्वर बदले में SOAरिकॉर्ड के लिए एक अनुरोध (जिसमें सीरियल नंबर शामिल है) के साथ वापस कॉल करेंगे , और उस क्षेत्र की एक और हालिया प्रतिलिपि को नीचे खींचने के बारे में निर्णय लेंगे।
- इन संदेशों को
NSअनुभाग में सूचीबद्ध नहीं किए गए सर्वर पर भेजना संभव है , लेकिन इसके लिए सर्वर विशिष्ट कॉन्फ़िगरेशन निर्देशों (जैसे ISC BIND के also-notifyनिर्देश) की आवश्यकता होती है। एपेक्स NS रिकॉर्ड में डिफ़ॉल्ट कॉन्फ़िगरेशन के तहत सूचित करने के लिए सर्वर की मूल सूची शामिल है।
- यह ध्यान देने योग्य है कि माध्यमिक सर्वर इन
NSरिकॉर्ड्स के आधार पर एक-दूसरे को NOTIFY संदेश भी भेजेंगे , जिसके परिणामस्वरूप आमतौर पर लॉग इन रिफ्यूल्स होते हैं। यह सर्वरों को केवल उन क्षेत्रों के लिए सूचना भेजने के निर्देश द्वारा अक्षम किया जा सकता है जिनके लिए वे (BIND:) के स्वामी हैं notify master;, या NSकॉन्फ़िगरेशन में स्पष्ट रूप से परिभाषित नोटिफ़िकेशन के पक्ष में पूरी तरह से आधारित सूचनाओं को छोड़ने के लिए । (BIND: notify explicit;)
आधिकारिक परिभाषा
ऊपर दिए गए प्रश्न में एक गिरावट थी:
डोमेन के लिए आधिकारिक सर्वर को निर्धारित करने के लिए DNS सर्वरों को कैशिंग द्वारा उनका उपयोग नहीं किया जाता है। यह नेमसर्वर गोंद द्वारा नियंत्रित किया जाता है, जिसे रजिस्ट्रार स्तर पर परिभाषित किया गया है। कुलसचिव इस जानकारी का उपयोग गोंद रिकॉर्ड बनाने के लिए कभी नहीं करता है।
यह पहुंचने के लिए एक आसान निष्कर्ष है, लेकिन सटीक नहीं है। 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रिकॉर्ड अंत में बदले जा सकते हैं, जब वे ताजा कर रहे हैं। ये अस्थाई रिकॉर्ड समाप्त होने पर TTL के रूप में होते हैं, या जब कोई व्यक्ति स्पष्ट रूप से उन अभिलेखों के उत्तर का अनुरोध करता है।
Aऔर AAAAज़ोन डेटा के बाहर रिकॉर्ड (यानी ज़ोन के comबाहर डेटा के लिए ग्लू को परिभाषित करने वाले नेमवेर्स com, जैसे example.net) निश्चित रूप से ताज़ा हो जाएंगे, क्योंकि यह एक अच्छी तरह से समझी जाने वाली अवधारणा है कि एक सूचनाकर्ता को ऐसी जानकारी का आधिकारिक स्रोत नहीं माना जाना चाहिए । (RFC 2181)- जब
NSरेफ़रल के माता-पिता और बच्चे के पक्षों के बीच रिकॉर्ड के मान अलग-अलग होते हैं (जैसे कि नेमवेर्स रजिस्ट्रार कंट्रोल पैनल में दर्ज किए गए NSरिकॉर्ड से अलग होते हैं जो उन्हीं सर्वरों पर रहते हैं), अनुभव किए गए व्यवहार असंगत, अप करने के लिए और बच्चे सहित NSअभिलेखों को पूरी तरह से नजरअंदाज किया जा रहा है। इसका कारण यह है कि व्यवहार मानकों द्वारा अच्छी तरह से परिभाषित नहीं किया गया है, और कार्यान्वयन विभिन्न पुनरावर्ती सर्वर कार्यान्वयन के बीच भिन्न होता है। दूसरे शब्दों में, पूरे इंटरनेट पर लगातार व्यवहार की उम्मीद तभी की जा सकती है जब किसी डोमेन के लिए नेमवेरर्स परिभाषाएँ एक रेफरल के माता-पिता और बच्चे के बीच संगत हों ।
इसका लंबा और छोटा यह है कि पूरे इंटरनेट पर पुनरावर्ती DNS सर्वर गंतव्यों के बीच वापस आ जाएंगे यदि रेफरल के मूल पक्ष पर परिभाषित रिकॉर्ड उन रिकॉर्डों के आधिकारिक संस्करणों से सहमत नहीं हैं। प्रारंभ में रेफरल में मौजूद डेटा को केवल आधिकारिक परिभाषाओं द्वारा प्रतिस्थापित किया जाना पसंद किया जाएगा। चूंकि कैश को लगातार पूरे इंटरनेट पर खरोंच से बनाया जा रहा है, इसलिए इंटरनेट के लिए इस कॉन्फ़िगरेशन के साथ वास्तविकता के एकल संस्करण पर समझौता करना असंभव है। यदि आधिकारिक रिकॉर्ड मानकों के अनुसार कुछ गैरकानूनी कर रहे हैं, जैसे कि NSएएएल द्वारा परिभाषित उपनामों की ओर इशारा करते हुएCNAME, यह समस्या निवारण के लिए और भी कठिन हो जाता है; डोमेन कार्यशील और सॉफ़्टवेयर के लिए वैकल्पिक होगा जो उल्लंघन को अस्वीकार करता है। (यानी ISC BIND / नामित)
RFC 2181 .45.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.