टीएल; डीआर: हाँ मध्यवर्ती उप-डोमेन को मौजूद होने की आवश्यकता है, कम से कम जब डीएनएस की परिभाषा के अनुसार, इसकी आवश्यकता होती है; वे भले ही ज़ोनफाइल में मौजूद न हों।
पहले खत्म करने के लिए एक संभावित भ्रम; "खाली नॉन-टर्मिनल" की परिभाषा
हो सकता है कि आप दो चीजों को भ्रमित कर रहे हों, क्योंकि अन्य उत्तर भी करने लगते हैं। अर्थात्, नामों के लिए क्वेरी करते समय क्या होता है बनाम आप अपने नेमसर्वर और ज़ोनफ़ाइल की सामग्री को कैसे कॉन्फ़िगर करते हैं।
डीएनएस पदानुक्रमित है। किसी भी पत्ती नोड के अस्तित्व के लिए, इसके लिए अग्रणी सभी घटक मौजूद होने चाहिए, इस अर्थ में कि यदि वे इसके लिए क्वियर हैं, तो जिम्मेदार आधिकारिक नेमसर्वर को त्रुटि के बिना जवाब देना चाहिए।
जैसा कि RFC 8020 में समझाया गया है (जो कि हमेशा नियम का दोहराव होता है, लेकिन बस कुछ DNS प्रदाताओं को एक अनुस्मारक की आवश्यकता होती है), यदि किसी भी प्रश्न के लिए, एक आधिकारिक नामवर उत्तर NXDOMAIN (जो है: यह संसाधन रिकॉर्ड मौजूद नहीं है), तब इसका अर्थ है कि यह संसाधन "नीचे" कोई भी लेबल मौजूद नहीं है।
अपने उदाहरण में, यदि के लिए एक प्रश्न intermediate.example.comरिटर्न NXDOMAIN, तो कोई भी उचित पुनरावर्ती नेम सर्वर तुरंत जवाब देगा NXDOMAINके लिए leaf.intermediate.example.comक्योंकि इस रिकॉर्ड मौजूद नहीं कर सकते यह सभी लेबल रिकॉर्ड के रूप में मौजूद नहीं है, तो।
यह पहले से ही RFC 4592 में वाइल्डकार्ड (जो यहाँ असंबंधित हैं) के बारे में बताया गया था :
डोमेन नेम स्पेस एक ट्री स्ट्रक्चर है। पेड़ में नोड्स या तो
कम से कम एक RRSet और / या वंशज हैं जो सामूहिक रूप
से कम से कम एक RRSet के मालिक हैं। एक नोड बिना किसी आरआरसेट के साथ मौजूद हो सकता है, अगर उसके
वंशज हैं; यह नोड एक खाली गैर-टर्मिनल है।
बिना वंश के एक नोड एक पत्ती नोड है। खाली पत्ता नोड्स मौजूद नहीं है।
.US डोमेन नामों के साथ एक व्यावहारिक उदाहरण
आइए एक TLD से एक ऐतिहासिक उदाहरण के साथ बहुत सारे लेबल के साथ एक कार्य उदाहरण लें .US। ऑनलाइन किसी भी उदाहरण को उठाते हुए, हमें उपयोग करते हैं www.teh.k12.ca.us।
बेशक यदि आप इस नाम के लिए क्वेरी करते हैं, या यहां तक कि teh.k12.ca.usआप वापस Aरिकॉर्ड प्राप्त कर सकते हैं । हमारे उद्देश्य के लिए यहां कुछ भी निर्णायक नहीं है (इसके बीच में एक CNAME भी है, लेकिन हमें इसकी परवाह नहीं है):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
चलिए अब के लिए क्वेरी करते हैं k12.ca.us(मैं इसके आधिकारिक नाम नहीं लिख रहा हूँ, लेकिन यह वास्तव में परिणाम नहीं बदलता है):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
इस उत्तर से हम क्या सीखते हैं?
पहला, यह एक सफलता है क्योंकि स्थिति है NOERROR। अगर यह कुछ और था और विशेष रूप से NXDOMAINतब teh.k12.ca.us, न ही www.teh.k12.ca.usमौजूद हो सकता है।
दूसरा, ANSWER सेक्शन खाली है। के लिए कोई Aरिकॉर्ड नहीं हैं k12.ca.us। यह एक त्रुटि नहीं है, इस प्रकार ( A) इस रिकॉर्ड के लिए मौजूद नहीं है, लेकिन शायद इस रिकॉर्ड के लिए अन्य रिकॉर्ड प्रकार मौजूद हैं या यह रिकॉर्ड एक ईएनटी, उर्फ "खाली नॉन टर्मिनल" है: यह खाली है, लेकिन यह एक पत्ता नहीं है, वहाँ चीजें "नीचे" हैं ( आरएफसी 7719 में परिभाषा देखें ), जैसा कि हम पहले से ही जानते हैं (लेकिन आम तौर पर संकल्प ऊपर है, इसलिए हम नीचे एक स्तर पर जाने से पहले इस चरण तक पहुंचेंगे और विपरीत नहीं जैसे हम प्रदर्शन के लिए यहां कर रहे हैं। उद्देश्य)।
यही कारण है कि वास्तव में, एक शॉर्टकट के रूप में, हम कहते हैं कि स्थिति कोड है NODATA: यह एक वास्तविक स्थिति कोड नहीं है, इसका मतलब सिर्फ NOERROR+ खाली ANSWER अनुभाग है, जिसका अर्थ है कि इस विशिष्ट रिकॉर्ड प्रकार के लिए कोई डेटा नहीं है, लेकिन दूसरों के लिए हो सकता है।
यदि आप अगले "अप" लेबल के साथ क्वेरी करते हैं, तो आप उसी परिणाम के लिए उसी प्रयोग को दोहरा सकते हैं, यही नाम है ca.us।
क्वेरीज़ के परिणाम बनाम ज़ोनफ़ाइल सामग्री
अब कहां से भ्रम की स्थिति आ सकती है? मेरा मानना है कि यह किसी गलत विचार से आ सकता है कि DNS नाम के किसी भी डॉट का मतलब प्रतिनिधिमंडल है। यह गलत है। अलग तरह से कहा, आपका example.comज़ोनफ़ाइल ऐसा हो सकता है, और यह पूरी तरह से वैध और काम कर रहा है:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
इस तरह के ज़ोनफ़ाइल के साथ, इस नेमसर्वर को क्वेरी करने पर आपको ऊपर देखा गया व्यवहार ठीक मिलेगा: खाली उत्तर के साथ एक क्वेरी intermediate.example.comवापस आ जाएगी NOERROR। आपको इसे विशेष रूप से ज़ोनफाइल में बनाने की आवश्यकता नहीं है (यदि आपको अन्य कारणों से इसकी आवश्यकता नहीं है), आधिकारिक नामवर "इंटरमीडिएट" उत्तरों को संश्लेषित करने का ध्यान रखेगा, क्योंकि यह देखता है कि इसे खाली गैर-टर्मिनल (किसी भी) की आवश्यकता है अन्य "इन-इन" यदि अन्य लेबल थे) तो यह पत्ते का नाम देखता है leaf.intermediate.example.com।
ध्यान दें कि यह कुछ क्षेत्रों में वास्तव में एक व्यापक मामला है, लेकिन आप इसे नहीं देख सकते क्योंकि यह अधिक "अवसंरचना" रिकॉर्ड को लक्षित करता है जो लोगों के सामने नहीं आते हैं:
- रिवर्स जोन जैसे
in-addr.arpया ip6.arpa, और विशेष रूप से अंतिम एक। आपके पास जैसे रिकॉर्ड होंगे 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.और जाहिर है कि प्रत्येक बिंदु पर एक प्रतिनिधिमंडल नहीं है, न ही प्रत्येक लेबल पर संसाधन रिकॉर्ड संलग्न हैं
- में
SRVरिकॉर्ड, की तरह _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., एक डोमेन कई हो सकता है _proto._tcp.example.comऔर _proto._udp.example.com SRVरिकॉर्ड क्योंकि डिजाइन द्वारा उन्हें इस फ़ॉर्म को होना आवश्यक है, लेकिन एक ही समय में _tcp.example.comऔर _udp.example.comखाली गैर टर्मिनल रहेगा क्योंकि रिकॉर्ड के रूप में इस्तेमाल कभी नहीं
- आपके पास वास्तव में DKIM जैसे विभिन्न प्रोटोकॉल के लिए "अंडरस्कोर लेबल" के आधार पर नामों के विशिष्ट निर्माण के कई अन्य मामले हैं। डीकेआईएम आपको डीएनएस रिकॉर्ड पसंद करने के लिए बाध्य करता है
whatever._domainkey.example.com, लेकिन जाहिर है _domainkey.example.comकि इसका उपयोग कभी नहीं किया जाएगा, इसलिए यह एक खाली गैर-टर्मिनल बना रहेगा। इस के लिए एक ही है TLSAमें डेन रिकॉर्ड (पूर्व: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==), या URIरिकॉर्ड (पूर्व: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Nameserver व्यवहार और मध्यवर्ती उत्तरों की पीढ़ी
क्यों नेमस्वर स्वचालित रूप से ऐसे मध्यवर्ती उत्तरों को संश्लेषित करता है? DNS के लिए कोर रिज़ॉल्यूशन एल्गोरिथ्म, जैसा कि RFC 1034 सेक्शन 4.3.2 में विस्तृत है, इसका कारण यह है कि हम इसे ले लें और नाम के लिए उपरोक्त आधिकारिक नेमवेर को क्वेरी करते समय इसे संक्षेप में प्रस्तुत करें intermediate.example.com(यह QNAMEनीचे प्रोटोकॉल में है):
- उस क्षेत्र के लिए उपलब्ध ज़ोन खोजें जो QNAME का निकटतम पूर्वज है। यदि ऐसा क्षेत्र पाया जाता है, तो चरण 3 पर जाएं, अन्यथा चरण 4।
example.comनेमसेवर जोन को QNAME के निकटतम पूर्वज के रूप में पाता है , इसलिए हम चरण 3 पर जा सकते हैं।
अब हमारे पास यह है:
- ज़ोन में, लेबल द्वारा लेबल से मेल खाना शुरू करें। [..]
ए। यदि पूरे QNAME का मिलान किया जाता है, तो हमें नोड मिल गया है। [..]
ख। यदि कोई मैच हमें आधिकारिक डेटा से बाहर ले जाएगा, तो हमारे पास एक रेफरल है। यह तब होता है जब हम एक क्षेत्र के नीचे एनएस आरआर के कटिंग अंक के साथ एक नोड का सामना करते हैं। [..]
सी। यदि कुछ लेबल पर, एक मैच असंभव है (यानी, संबंधित लेबल मौजूद नहीं है), तो यह देखने के लिए देखें कि क्या "*" लेबल मौजूद है। [..]
हम मामलों को ख और ग को समाप्त कर सकते हैं, क्योंकि हमारे ज़ोनफ़िल का कोई प्रतिनिधिमंडल नहीं है (इसलिए अन्य नेमसर्वरों का कोई संदर्भ नहीं होगा, कोई मामला नहीं ख) और न ही वाइल्डकार्ड (इसलिए कोई मामला नहीं है)।
हमें केवल मामले से ही निपटना है।
हम ज़ोन में, लेबल द्वारा लेबल से मेल खाना शुरू करते हैं। इसलिए, भले ही हमारे पास एक लंबा sub.sub.sub.sub.sub.sub.sub.sub.example.comनाम था, किसी बिंदु पर, हम मामले में पहुंचते हैं: हमें एक रेफरल नहीं मिला, न ही एक वाइल्डकार्ड, लेकिन हम उस अंतिम नाम पर समाप्त हो गए जिसके लिए हम एक परिणाम चाहते थे।
फिर हम मामले की बाकी सामग्री लागू करते हैं:
यदि नोड पर डेटा एक CNAME है
हमारा मामला नहीं, हम इसे छोड़ देते हैं।
अन्यथा, सभी आरआर की नकल करें जो उत्तर खंड में क्यूटीपीईई से मेल खाते हैं और चरण 6 पर जाते हैं।
हम जो भी क्यूटीपीई चुनते हैं ( Aऔर AAAA, NSआदि) हमारे पास कोई आरआर नहीं है intermediate.example.comक्योंकि यह ज़ोनफाइल में नहीं दिखता है। इसलिए यहां कॉपी खाली है। अब हम चरण 6 पर समाप्त होते हैं:
केवल स्थानीय डेटा का उपयोग करते हुए, अन्य आरआर को जोड़ने का प्रयास करें जो क्वेरी के अतिरिक्त अनुभाग के लिए उपयोगी हो सकता है। बाहर जाएं।
यहां हमारे लिए प्रासंगिक नहीं है, इसलिए हम सफलता के साथ समाप्त करते हैं।
यह वास्तव में देखे गए व्यवहार की व्याख्या करता है: इस तरह के प्रश्न वापस आ जाएंगे NOERRORलेकिन कोई डेटा भी नहीं।
अब, आप अपने आप से पूछ सकते हैं: "लेकिन फिर अगर मैं किसी भी नाम का उपयोग करता हूं, another.example.comतो उपरोक्त एल्गोरिथ्म द्वारा मुझे समान उत्तर (कोई त्रुटि नहीं) मिलना चाहिए", लेकिन टिप्पणियों के बजाय NXDOMAINउस मामले में रिपोर्ट करेंगे ।
क्यूं कर?
क्योंकि पूरे एल्गोरिथ्म को समझाया गया है, इसके साथ शुरू होता है:
निम्नलिखित एल्गोरिथ्म मानता है कि आरआर को कई पेड़ संरचनाओं में आयोजित किया जाता है, प्रत्येक क्षेत्र के लिए एक और कैश के लिए एक और
इसका अर्थ है कि उपरोक्त ज़ोन इस पेड़ में तब्दील हो गया है:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
इसलिए, एल्गोरिथ्म का पालन करते हुए, ऊपर से, आप वास्तव में एक पथ पा सकते हैं: com > example > intermediate(क्योंकि पथ com > example > intermediate > leafमौजूद है) लेकिन another.example.com, जब com > exampleआप anotherपेड़ में लेबल नहीं ढूंढते हैं, तो बच्चों के नोड के रूप में example। इसलिए हम ऊपर से पसंद के हिस्से में आते हैं:
यदि "*" लेबल मौजूद नहीं है, तो जांचें कि क्या हम जिस नाम की तलाश कर रहे हैं वह क्वेरी में मूल QNAME है या एक नाम जो हमने CNAME के कारण अनुसरण किया है। यदि नाम मूल है, तो प्रतिक्रिया और निकास में एक आधिकारिक नाम त्रुटि सेट करें। अन्यथा सिर्फ बाहर निकलें।
लेबल *मौजूद नहीं है, और हमने पालन नहीं किया CNAME, इसलिए हम मामले में हैं: set an authoritative name error in the response and exitउर्फ NXDOMAIN।
ध्यान दें कि उपरोक्त सभी ने अतीत में भ्रम पैदा किया था। यह कुछ RFC में एकत्र किया गया है। उदाहरण के लिए देखें इस अप्रत्याशित स्थान (वाइल्डकार्ड्स को परिभाषित करते हुए DNS स्पेसिफिकेशंस का आनंद बहुत ही अभेद्य है): RFC 4592 "डोमेन नेम सिस्टम में वाइल्डकार्ड्स की भूमिका" और विशेष रूप से इसके सेक्शन 2.2 "एक्स्टेंसेंस रूल्स" को भी शुरुआत में भाग में उद्धृत किया गया था। मेरा जवाब है लेकिन यहाँ यह अधिक पूर्ण है:
खाली गैर-टर्मिनल [RFC2136, खंड 7.16] डोमेन नाम हैं जिनके पास कोई संसाधन रिकॉर्ड नहीं है, लेकिन उप-डोमेन हैं जो करते हैं। धारा 2.2.1 में,
"_tcp.host1.example।" एक खाली गैर-टर्मिनल नाम का एक उदाहरण है।
खाली गैर-टर्मिनलों को आरएफसी 1034 के खंड 3.1 में इस पाठ द्वारा प्रस्तुत किया गया है:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
कोष्ठबद्ध "जो खाली हो सकता है" निर्दिष्ट करता है कि खाली गैर-
टर्मिनलों को स्पष्ट रूप से पहचाना जाता है और यह खाली गैर-टर्मिनल
"मौजूद" हैं।
उपर्युक्त पैराग्राफ़ को पढ़ने से एक
व्याख्या हो सकती है कि सभी संभावित डोमेन मौजूद हैं -
एक डोमेन नाम [RFC1035] के लिए 255 ऑक्टेट की सुझाई गई सीमा तक। उदाहरण के लिए,
www.example। एक आरआर हो सकता है, और जहां तक व्यावहारिक रूप से
चिंतित है, डोमेन ट्री का एक पत्ता है। लेकिन परिभाषा
का अर्थ यह लिया जा सकता है कि उप.प्लेक्स। यह भी मौजूद है, जिसमें कोई डेटा नहीं है। विस्तार से, सभी संभव डोमेन मौजूद हैं, नीचे रूट से।
जैसा कि RFC 1034 भी "एक आधिकारिक नाम त्रुटि दर्शाता है जो यह दर्शाता है कि नाम 4.3.3 सेक्शन में मौजूद नहीं है", इसलिए यह स्पष्ट रूप से मूल परिभाषा का इरादा नहीं है, अगले खंड में एक अद्यतन परिभाषा की आवश्यकता को सही ठहराता है।
और फिर अगले खंड में परिभाषा वह पैराग्राफ है जिसे मैंने शुरुआत में उद्धृत किया था।
ध्यान दें कि RFC 8020 ( NXDOMAINवास्तव में NXDOMAIN, इसका मतलब है कि अगर आप उत्तर देते NXDOMAINहैं intermediate.example.com, तो leaf.intermediate.example.comमौजूद नहीं हो सकता है) को अनिवार्य रूप से अनिवार्य किया गया था क्योंकि विभिन्न DNS प्रदाता इस व्याख्या का पालन नहीं करते थे और जिससे कहर पैदा होता था, या वे सिर्फ कीड़े थे, उदाहरण के लिए इसे देखें 2013 में एक ओपनसोर्स आधिकारिक नाम कोड में तय किया गया: https://github.com/PowerDNS/pdns/issues/127
लोगों को तब केवल उनके लिए विशिष्ट काउंटर उपाय करने की आवश्यकता होती है: जो आक्रामक रूप से कैशिंग नहीं है NXDOMAINक्योंकि उन प्रदाताओं के लिए यदि आपको NXDOMAINकुछ नोड मिलते हैं , तो इसका मतलब यह हो सकता है कि आपको NXDOMAINइसके नीचे एक और नोड की तुलना में कुछ और मिल सकता है।
और यह QNAME न्यूनतमकरण (RFC 7816) को प्राप्त करना असंभव बना रहा था ( अधिक जानकारी के लिए https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname/min/pdf देखें) , जबकि यह गोपनीयता बढ़ाना चाहता था। DNSSEC के मामले में खाली गैर-टर्मिनलों के अस्तित्व ने अतीत में भी समस्याएं पैदा कीं, गैर-अस्तित्व को संभालने के आसपास (देखें https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647) /AFNIC_OARC_Dallas.pdf अगर दिलचस्पी है, लेकिन आपको वास्तव में पहले DNSSEC की अच्छी समझ की आवश्यकता है)।
निम्नलिखित दो संदेश उन समस्याओं का एक उदाहरण देते हैं जो एक प्रदाता को इस नियम को रिक्त गैर-टर्मिनलों पर ठीक से लागू करने में सक्षम होना था, यह मुद्दों के कुछ परिप्रेक्ष्य देता है और हम वहां क्यों: