क्यों एक निजी Route 53 ज़ोन सार्वजनिक नामों के लिए NXDOMAIN लौटाता है

निजी Route 53 ज़ोन सार्वजनिक रिकॉर्ड के साथ विलय होने के बजाय नाम का उत्तर बदल देते हैं, और इसी वजह से लोग सबसे बुरे क्षण में चौंक जाते हैं। एक आंतरिक रिकॉर्ड जोड़ें api.example.net के लिए एक निजी ज़ोन में example.net, उसे VPC से जोड़ें, और उस मूल के अंतर्गत हर दूसरा नाम अब केवल निजी ज़ोन से उत्तर पाता है। जो क्लाइंट कल www.example.net तक पहुँच सकता था, उसे आज नकारात्मक उत्तर मिलता है। नीचे की समीक्षा उसी विफल क्वेरी से शुरू होती है और उस ज़ोन की ओर बाहर जाती है जिसने उसका उत्तर दिया।

कंसोल से नहीं, क्वेरी से शुरू करें

जिस क्लाइंट ने समस्या दर्ज की, उसी पर विफलता दोहराएँ और सटीक नाम तथा रिकॉर्ड प्रकार लिखें। जो नाम A के लिए विफल होता है, वह AAAA के लिए अब भी हल हो सकता है, और कैश किए गए नाम को फिर आज़माने वाला ब्राउज़र छिपा देता है कि कौन-सा टूटा है। क्वेरी दो बार चलाएँ: एक बार उस resolver से जो क्लाइंट वास्तव में उपयोग करता है, और एक बार उसे बायपास करने वाले ट्रेस के साथ।

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

दूसरा कमांड ही महत्वपूर्ण है। उसकी स्टेटस लाइन और authority अनुभाग उस ज़ोन का नाम देते हैं जिसने उत्तर बनाया, इसलिए आप निजी ज़ोन से आए नकारात्मक उत्तर को टाइमआउट, अवरुद्ध पोर्ट या ऐसे resolver से अलग कर सकते हैं जिसे क्वेरी कभी मिली ही नहीं। resolvectl दिखाता है कि किस अपस्ट्रीम से पूछा गया, और अक्सर वह वह resolver नहीं होता जिसे आपने माना था कि VPN ने भेजा है।

यदि ट्रेस की गई क्वेरी सार्वजनिक पता लौटाती है और सामान्य क्वेरी नहीं, तो सार्वजनिक रिकॉर्ड अक्षुण्ण है और उत्तर निजी दृश्य दे रहा है। यही एक तुलना तय करती है कि इस पृष्ठ के बाकी हिस्से का कौन-सा आधा आप पर लागू होता है।

पढ़ें कि किस ज़ोन ने उत्तर दिया

ऐसा उत्तर जो NXDOMAIN लेकर आता है और authority अनुभाग में निजी ज़ोन का SOA रखता है, उस ज़ोन का निर्णायक उत्तर है, विफल लुकअप नहीं। Route 53 Resolver ने निजी होस्टेड ज़ोन इसलिए चुना क्योंकि नाम मेल खाता था, फिर माँगे गए प्रकार का कोई रिकॉर्ड नहीं मिला, और प्रलेखित व्यवहार यह है कि प्रश्न को सार्वजनिक DNS पर भेजने के बजाय नकारात्मक उत्तर लौटाया जाए।

चयन विशिष्टता का पालन करता है। कई अतिव्यापी निजी नामस्थान होने पर सबसे विशिष्ट मेल खाता ज़ोन जीतता है, और चुने गए चाइल्ड ज़ोन में न होने वाले नाम के लिए व्यापक निजी मूल को दूसरा मौका नहीं मिलता। फ़ॉरवर्डिंग नियम एक और परत जोड़ते हैं, क्योंकि किसी डोमेन-विशिष्ट Resolver नियम के कारण निजी होस्टेड ज़ोन का संबंध हार सकता है। यह निष्कर्ष निकालने से पहले कि कोई ज़ोन खाली है, संबंधों और नियमों की सूची बनाएँ।

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

दोनों कमांडों को ज़ोन के मालिक खाते के क्रेडेंशियल चाहिए, और दूसरे को पहले से ज़ोन आईडी चाहिए। उसे अपनी आईडी से बदलें; ऊपर दिया गया प्लेसहोल्डर जानबूझकर असली नहीं है।

निजी ज़ोन क्यों जीतता है

संबंध ही ज़ोन को VPC के लिए दृश्यमान बनाता है, और उस VPC का resolver उसे लागू करता है। जिस VPC से क्लाइंट का ट्रैफ़िक आता है, उससे जुड़ा न होने वाला निजी ज़ोन बिल्कुल भी प्रभाव नहीं डालता, जबकि गलत VPC से संबंध गलत आबादी के लिए निजी उत्तर बनाता है। रिकॉर्ड संपादित करने से पहले संबंधों की सूची जाँचें, क्योंकि ज़ोन सही होकर भी अदृश्य रह सकता है।

अतिव्यापी नामस्थान भ्रम का दूसरा स्रोत हैं। example.net के लिए निजी ज़ोन और api.example.net के लिए निजी ज़ोन दोनों एक API क्वेरी से मेल खाते हैं, और अधिक विशिष्ट उत्तर देता है। यह तब उपयोगी है जब आप संकीर्ण आंतरिक नामस्थान चाहते हैं, और तब खतरनाक है जब संकीर्ण ज़ोन में वह रिकॉर्ड न हो जो व्यापक में है। निजी होस्टेड ज़ोन के विचार Route 53 दस्तावेज़ में नीचे गिरने का व्यवहार और नियमों की प्राथमिकता दोनों बताते हैं, और दूसरा अतिव्यापी ज़ोन जोड़ने से पहले उन्हें पढ़ना उचित है।

इनमें से कुछ भी सार्वजनिक ज़ोन नहीं बदलता। सार्वजनिक resolver अब भी सार्वजनिक रिकॉर्डों का सही उत्तर देते हैं, और इसीलिए VPC के बाहर के सभी को यह विफलता क्लाइंट की समस्या लगती है।

रिकॉर्ड जोड़ने से पहले नामस्थान चुनें

यदि केवल आंतरिक सेवाओं के एक नए परिवार को निजी नाम चाहिए, तो उसे एक समर्पित निजी सबडोमेन दें और सार्वजनिक मूल को अक्षुण्ण रहने दें। internal.example.net जैसा नाम www.example.net को छाया नहीं डाल सकता, और अनुपस्थित रिकॉर्ड का प्रभाव-क्षेत्र उन नामों तक सीमित रहता है जो आपने इसी उद्देश्य के लिए बनाए थे। कीमत यह है कि मौजूदा URL और प्रमाणपत्र नए नाम से मेल न खाएँ।

जब सार्वजनिक और निजी उपयोगकर्ताओं को एक ही होस्टनाम बनाए रखना होता है, तब split-view DNS समर्थित डिज़ाइन है और यह चाहता है कि आप हर दृश्य में रिकॉर्ड स्पष्ट रूप से बनाए रखें। एक ही रिकॉर्ड वाले व्यापक निजी ज़ोन उस ज़ोन के अंतर्गत सार्वजनिक निर्भरताओं को संरक्षित नहीं करता; वह उन्हें एक रिकॉर्ड वाले ज़ोन से बदल देता है।

क्लाइंट आबादी को निजी दृश्य की ओर मोड़ने से पहले उन नामों की सूची बनाएँ जिन्हें कोई एप्लिकेशन वास्तव में कॉल करता है। लॉगिन होस्ट, स्टैटिक एसेट होस्ट, रीडायरेक्ट लक्ष्य और API एंडपॉइंट सबसे पहले टूटते हैं, और वे आम तौर पर कई टीमों के रिकॉर्ड में बिखरे होते हैं।

resolver का पथ, फिर रूट ट्रेस करें

लैपटॉप निजी दृश्य तभी देखता है जब उसकी क्वेरी उस resolver तक पहुँचे जिसके पास संबंध है। VPN सर्वर पर hosts फ़ाइल संपादित करने से जुड़े क्लाइंटों को कुछ भी प्रकाशित नहीं होता, और सार्वजनिक resolver के साथ सेट क्लाइंट टनल चालू रहने तक सार्वजनिक उत्तर पाता रहेगा। क्लाइंट को मिला resolver पता पुष्टि करें, फिर क्वेरी सर्वर से नहीं, क्लाइंट से दोहराएँ।

नाम हल हो जाने पर, लौटाए गए पते तक का पथ अलग चरण के रूप में जाँचें, उदाहरण के लिए ip route get से क्वेरी द्वारा लौटाए गए पते के विरुद्ध। पते तक रूट के बिना सही निजी उत्तर रूटिंग समस्या है, और रिकॉर्ड अनुपस्थित होने का उत्तर DNS दृश्य की समस्या है; दोनों को एक समस्या मानने से ऐसे सुधार बनते हैं जो टिकते नहीं। सेवा के TLS होस्टनाम और प्रमाणपत्र जाँच अपरिवर्तित रखें, क्योंकि निजी पता बदलता है कि कनेक्शन कहाँ जाता है और कौन-सा प्रमाणपत्र मान्य है इस बारे में कुछ नहीं।

परिवर्तन नोट में ज़ोन, संबंध, resolver और जिन नामों को आपने सत्यापित किया उन्हें लिखकर समाप्त करें। तब अगली बार रिकॉर्ड जोड़ने वाला जान जाएगा कि उस क्लाइंट आबादी के लिए कौन-सा नामस्थान आधिकारिक है।