खाजगी 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 आणि तुम्ही पडताळलेली नावे लिहून पूर्ण करा। मग पुढच्या वेळी रेकॉर्ड जोडणाऱ्या व्यक्तीला त्या क्लायंट लोकसंख्येसाठी कोणते नावस्थान अधिकृत आहे हे कळेल।