CDN ले आफ्ना ठेगाना बदल्दा VPN डोमेन नियम भाँचिन्छ
एक DNS उत्तर एक स्न्यापसट हो, इन्भेन्टरी होइन। नाममा आधारित नियम वा स्पष्ट प्रिफिक्स CDN-आधारित सेवाका लागि उपयुक्त छ कि भन्ने तीन सर्तले निर्धारण गर्छन्।
एक खोजीबाट ठेगाना आफ्नो रुटिङ नियममा प्रतिलिपि गर्नुहुन्छ, साइट चल्छ, र एक हप्तापछि चल्दैन। नियममा केही बदलिएको छैन। सेवा अर्को एज ठेगानामा सर्यो, क्लाइन्टले अर्को होस्टनाम समाधान गर्यो, वा सत्र IPv6 मा गयो। तपाईंअगाडिको निर्णय यो हो कि नाममा आधारित नियम वा स्पष्ट दायरा यो सेवाका लागि सही साधन हो, र तीन सर्तले त्यो निर्धारण गर्छन्। अगाडिको कुराले नामलाई ठेगानाबाट अलग गर्छ, किनकि तीमध्ये एक मात्र स्थिर छ।
एक खोजी इन्भेन्टरी किन होइन
सामग्री वितरण सञ्जालले रिजोल्भर, क्षेत्र र क्षणका लागि छानिएको ठेगानासहित उत्तर दिन्छ। फरक सञ्जालबाट दुई पटक सोध्नुहोस्, फरक उत्तर पाउन सक्नुहुन्छ। एक पटक सोध्नुहोस् र उत्तरलाई सेवाको ठेगाना सूची मान्नुहोस्, तब तपाईंले लेख्ने नियम नियम होइन, स्न्यापसट हुन्छ। DNS उत्तरलाई कन्फिगरेसन मान्ने सबै समस्या यही हो।
दोस्रो खाडल छ। एउटा देखिने होस्टनामले पूरै अनुप्रयोग विरलै ढाक्छ, किनकि लगइन, मिडिया र API ट्राफिकले प्रायः छुट्टै नाम प्रयोग गर्छन्। ठेगाना पट्टीको होस्टनामबाट बनेको नियमले पृष्ठ ढाकेर भिडियो छुटाउन सक्छ, जसलाई रुटिङ त्रुटि नभई आंशिक असफलता भनी पढिन्छ।
तेस्रो खाडल ठेगाना परिवार हो। केवल v4 का लागि नियमले AAAA रेकर्डबारे केही भन्दैन, जसलाई क्लाइन्टले रुचाउन सक्छ।
डोमेन नियम वा दायरा निर्धारण गर्ने तीन सर्त
पहिलो, सेवाले स्थिर प्रिफिक्सको समूह प्रकाशित गर्छ जसलाई तपाईं राख्न र अभिलेख गर्न सक्नुहुन्छ? यदि गर्छ, स्पष्ट दायरा इमानदार र सस्तो हुन्छन्। यदि गर्दैन, डोमेन नियम नै सेवालाई पछ्याउन सक्ने एकमात्र माध्यम हो।
दोस्रो, तपाईंको क्लाइन्टको डोमेन विधि रिफ्रेस हुन्छ? जो नियम जडान गर्दा एक पटक समाधान भएर फेरि कहिल्यै नहुने, त्यो राम्रो ब्रान्डिङ भएको स्न्यापसट हो। तेस्रो, विधिले सबडोमेन र दुवै ठेगाना परिवार ढाक्छ, वा तपाईंले टाइप गरेका नाम मात्र?
ती तीनको उत्तर दिनुहोस्, रोजाइ सामान्यतया स्पष्ट हुन्छ। अनुमानले परीक्षणमा चल्ने र उत्पादनमा असफल हुने नियम बनाउँछ।
सत्र जाँच्नुहोस्, पृष्ठ होइन
पृष्ठ लोड गर्नुहोस्, त्यसपछि महत्त्वपूर्ण कार्य गर्नुहोस्: साइन इन गर्नुहोस्, प्लेब्याक सुरु गर्नुहोस्, फाइल अपलोड गर्नुहोस्। तीमध्ये प्रत्येक फरक होस्टसम्म पुग्न सक्छ, र असफल हुने तपाईंको नियमले छुटाएको हो।
पृष्ठले के देखाउँछ भन्ने होइन, सत्रले वास्तवमा केसँग सम्पर्क गर्छ त्यो सूचीबद्ध गर्नुहोस्:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5तुलना गर्दा रिजोल्भर देखिने राख्नुहोस्, किनकि एउटा रिजोल्भरबाट चल्ने र अर्कोबाट असफल हुने नियमले तपाईंलाई CDN को उत्तरबारे बताउँछ, सुरुङबारे होइन। छोटो TTL ले तपाईंले अभिलेख गरेको उत्तरको म्याद हुन्छ भन्ने पनि जनाउँछ।
प्रत्येक विधिले वास्तवमा के ढाक्छ
दुवै विधि सेटिङ्स पृष्ठमा अदलबदल गर्न मिल्ने देखिन्छन् र भित्रबाट फरक व्यवहार गर्छन्।
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
कर्नेल ठेगाना मार्गले प्रिफिक्स मिलाउँछ। यसलाई होस्टनाम के हो भन्ने थाहा छैन, त्यसैले ठेगाना बदल्ने सेवालाई पछ्याउन सक्दैन। डोमेन नियमले नाम समाधान गरी नतिजा रुट गर्छ; यसले सेवालाई पछ्याउँछ तर रिजोल्भर, रिफ्रेस व्यवहार र सबडोमेनप्रति क्लाइन्टको व्यवहारमा निर्भर हुन्छ, त्यसैले नाम पछ्याउने नियम क्लाइन्टले वास्तवमा प्रयोग गर्ने रिजोल्भरसँग जाँच्नुपर्छ।
कुनै पनि अर्कोको सुपरसेट होइन, त्यसैले नोटबिना दुवै मिसाउँदा पछि भ्रम उत्पन्न हुन्छ।
सेवा बदलिएपछि फेरि जाँच्नुहोस्
क्लाइन्ट अपडेट वा सेवा परिवर्तनपछि त्यही सत्र परीक्षण फेरि चलाउनुहोस्। पहिले चलेको ठेगाना सूची त्यो अवधिको प्रमाण हो, सेवाको पूर्वाधारको स्थायी इन्भेन्टरी होइन।
कुन विधिले कुन होस्टनाम ढाक्छ, र अन्तिम जाँचको मिति लेख्नुहोस्।
त्यो नोट नै तपाईं रक्षा गर्न सक्ने नियम र कसैले छुन हिम्मत नगर्ने नियमबीचको फरक हो। सेवाले आफ्नै प्रिफिक्स सूची प्रकाशित गर्छ भने त्यो प्रयोग गर्नुहोस् र मिति उल्लेख गर्नुहोस्। यदि गर्दैन भने त्यसै भन्नुहोस्, र डोमेन नियमलाई त्यसको रिफ्रेस व्यवहारसहित छेउमा लेखेर राख्नुहोस्।