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

रेकर्ड अवस्थित छ भनेर प्रमाणित गरेर सुरु गर्छु, त्यसपछिको समय क्वेरी मार्गमा बिताउँछु। यी छुट्टै प्रणाली हुन् र फरक तरिकाले असफल हुन्छन्।

केही परिवर्तन गर्नु अघि असफलताको आकार पढ्नुहोस्

तीन नतिजाले तीन फरक कुरा जनाउँछन्, र एउटा क्वेरीले तिनलाई छुट्याउँछ: क्लाइन्टले वास्तवमै प्रयोग गरिरहेको resolver विरुद्ध नामका लागि dig चलाउनुहोस्।

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

समय सकिनु नेटवर्कको बारेमा एउटा भनाइ हो। NXDOMAIN DNS दृश्यको बारेमा भनाइ हो। सार्वजनिक उत्तर नीतिको बारेमा भनाइ हो। समय सकिँदै गर्दा जोन रेकर्ड सम्पादन गर्नु मुद्दाको एकमात्र उपयोगी प्रमाण फ्याँक्नु हो।

VPC को प्लस-दुई ठेगाना दूरस्थ resolver किन होइन

CIDR प्लस-दुई ठेगाना VPC भित्रका स्रोतहरूका लागि स्थानीय सेवा हो। AWS ले दस्तावेज गर्छ कि स्थानीय नेटवर्कबाट, वा अर्को VPC को DNS सर्भरबाट, क्वेरी सिधै त्यो ठेगानामा पठाउनु समर्थित छैन र अस्थिर नतिजा दिन सक्छ।

यसको अर्थ प्रयोग कहिल्यै काम गरेको देखिँदैन भन्ने होइन। यसको अर्थ व्यवहार त्यस्तो सम्झौता होइन जुन हेल्पडेस्क स्क्रिप्टमा राख्न सकिन्छ। समर्थित दिशा इनबाउन्ड Resolver एन्डपोइन्ट हो: तपाईंको VPC भित्र ठेगानाको जोडी, तपाईंको नियन्त्रित नेटवर्कबाट पुग्न सकिने, जसले AWS बाहिरबाट आउने क्वेरी स्वीकार गर्छ।

मार्ग त्यो क्रममा बनाउनुहोस् जसमा यो सफा रूपमा असफल हुन्छ

तीन हप हुनैपर्छ, र प्रत्येकको असफल हुने आफ्नै तरिका छ।

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

फर्वार्डरलाई VPN मार्फत एन्डपोइन्ट ठेगानासम्म मार्ग चाहिन्छ, र फर्किने मार्ग पनि चल्नुपर्छ। पोर्ट 53 मा परम्परागत DNS का लागि एन्डपोइन्टले UDP र TCP मा जवाफ दिन्छ, त्यसैले दुवै प्रोटोकललाई अनुमति चाहिन्छ र दुवैले बीचको कुनै पनि स्टेटफुल जाँचबाट पार पाउनुपर्छ।

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

आउटबाउन्ड एन्डपोइन्टले विपरीत दिशाको सेवा गर्छ र तपाईंको ल्यापटपबाट आउने क्वेरीको जवाफ दिँदैन।

दुवै छेउबाट प्रमाणित गर्नुहोस्

क्लाइन्टबाट फर्वार्डरविरुद्ध क्वेरी गर्नुहोस्, त्यसपछि फर्वार्डरबाट एन्डपोइन्टविरुद्ध। क्लाइन्ट असफल हुँदा फर्वार्डर सफल भयो भने अन्तर ती दुईबीच हुन्छ।

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

सार्वजनिक र निजी नामस्थान जानाजान अलग राख्नुहोस्। Split DNS त्यो नीति हो जुन तपाईं कन्फिगर गर्नुहुन्छ, एउटा खोजको संयोगले डाटा फर्काउनुको साइड इफेक्ट होइन।

जे म गर्दिनँ

एउटा खोज चलाउने NAT नियम थपेर त्यसलाई डिजाइन भन्ने छैन।

एउटा परीक्षणले एकचोटि रेकर्ड फर्कायो भनेर म हरेक दूरस्थ क्लाइन्टलाई प्लस-दुई ठेगानातिर मोड्ने छैन। र एउटै फर्वार्डरलाई पहुँच चाहिँदा एन्डपोइन्टको सुरक्षा नीति सम्पूर्ण VPN पूलसम्म फैलाउने छैन। संस्थाले पहिले नै VPC भित्र स्वीकृत फर्वार्डर चलाइरहेको छ भने पहिले त्यो डिजाइन पढ्नुहोस्, किनकि तपाईंले थप्ने दोस्रो एन्डपोइन्ट त्यही हो जुन कसैले दस्तावेज गर्दैन।

सम्बन्धित लेखहरू