किन निजी 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 कुन माथिल्लो सर्भरलाई सोधियो देखाउँछ, र त्यो प्रायः तपाईंले अनुमान गरेको VPN ले पठाएको resolver हुँदैन।

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

कुन जोनले उत्तर दियो पढ्नुहोस्

निम्न कुरा बोकेको उत्तर: 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 र प्रमाणपत्रहरू नयाँ नामसँग नमिल्न सक्छन्।

जब सार्वजनिक र निजी प्रयोगकर्ताहरूले एउटै होस्टनाम राख्नुपर्छ, तब स्प्लिट-भ्यू DNS समर्थित डिजाइन हो र यसले प्रत्येक दृश्यमा रेकर्डहरू स्पष्ट रूपमा राख्नुपर्ने माग गर्छ। एउटै रेकर्ड भएको फराकिलो निजी जोनले त्यो जोनमुनिका सार्वजनिक निर्भरताहरू जोगाउँदैन; तिनलाई एक रेकर्ड भएको जोनले प्रतिस्थापन गर्छ।

क्लाइन्ट जनसंख्यालाई निजी दृश्यतर्फ लैजानुअघि अनुप्रयोगले साँच्चै कल गर्ने नामहरूको सूची बनाउनुहोस्। लगइन होस्ट, स्थिर सम्पत्ति होस्ट, रिडाइरेक्ट लक्ष्य र API अन्त्य बिन्दुहरू पहिले बिग्रन्छन्, र ती सामान्यतया धेरै टिमका रेकर्डहरूमा छरिएका हुन्छन्।

resolver को बाटो, त्यसपछि रुट ट्रेस गर्नुहोस्

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

नाम हल भएपछि, फर्काइएको ठेगानासम्मको बाटो छुट्टै चरणका रूपमा जाँच्नुहोस्, उदाहरणका लागि ip route get प्रयोग गरेर क्वेरीले फर्काएको ठेगानाविरुद्ध। ठेगानासम्म रुट नभएको सही निजी उत्तर रुटिङ समस्या हो, र रेकर्ड छैन भन्ने उत्तर DNS दृश्यको समस्या हो; दुवैलाई एउटै समस्या मान्दा टिक्ने सुधार आउँदैन। सेवाको TLS होस्टनाम र प्रमाणपत्र जाँचहरू अपरिवर्तित राख्नुहोस्, किनभने निजी ठेगानाले जडान कहाँ जान्छ भन्ने बदल्छ, कुन प्रमाणपत्र मान्य छ भन्नेमा केही पनि होइन।

परिवर्तन नोटमा जोन, सम्बन्ध, resolver र तपाईंले प्रमाणित गर्नुभएका नामहरू लेखेर अन्त्य गर्नुहोस्। तब अर्को पटक रेकर्ड थप्ने व्यक्तिलाई त्यो क्लाइन्ट जनसंख्याका लागि कुन नामस्थान आधिकारिक हो थाहा हुनेछ।