डीएनएस इंटरनेट की फ़ोन बुक है, और यह उपमा आधी ही काम आती है। इंजीनियर को "नाम ढूँढ़ने" की कहानी नहीं चाहिए। आपको रिज़ॉल्यूशन पथ, वे रिकॉर्ड प्रकार जो आप शिप करते हैं, टीटीएल और कैश हर बदलाव को कैसे टालते हैं, और dig की मांसपेशी याददाश्त चाहिए, जब प्रोडक्शन कहे होस्ट ठीक है और यूज़र कहें नहीं।
अगर आप ऐप डिप्लॉय करते हैं, डोमेन कटओवर करते हैं, मेल सेट करते हैं, या डीएनएस बदलाव के बाद "मेरी मशीन पर चलता है" डिबग करते हैं, तो यह नक्शा है।
डीएनएस असल में क्या जवाब देता है
आप api.example.com टाइप करते हैं। मशीन को आईपी चाहिए (या फेलियर)। डीएनएस किसी नाम और प्रकार के लिए रिसोर्स रिकॉर्ड लौटाता है। आम सवाल है "इस होस्टनेम का ए/एएएए क्या है?" मेल एमएक्स माँगता है। सर्टिफ़िकेट और एंटी-स्पैम टीएक्सटी माँगते हैं। लोड बैलेंसर और मल्टी-क्लाउड अक्सर सीनेम पर टिके होते हैं।
डीएनएस एचटीटीपी राउटिंग, टीएलएस, या लोड बैलेंसिंग नहीं है। वे तब शुरू होते हैं जब क्लाइंट के पास गंतव्य पता हो (या सीनेम चेन किसी एक पर खत्म हो)। डीएनएस, टीसीपी हैंडशेक से पहले की डायरेक्टरी सीढ़ी है।
रिज़ॉल्यूशन पथ
ज़्यादातर लुकअप "एक सर्वर सब जवाब दे दे" नहीं होते। वे भूमिकाओं की छोटी श्रृंखला होते हैं।
भूमिकाएँ
| भूमिका | कौन | काम |
|---|---|---|
| स्टब रिज़ॉल्वर | ओएस / लाइबसी / आपकी भाषा का रनटाइम | रिकर्सिव रिज़ॉल्वर से पूछता है; अक्सर छोटा लोकल कैश रखता है |
| रिकर्सिव रिज़ॉल्वर | आईएसपी, 1.1.1.1, 8.8.8.8, कॉर्पोरेट डीएनएस, वीपीसी रिज़ॉल्वर |
पदानुक्रम चलता है, जवाब कैश करता है, स्टब को अंतिम परिणाम देता है |
| रूट नेमसर्वर | रूट ज़ोन (.) के ऑपरेटर |
सही टीएलडी सर्वर (com., org., io., …) की ओर इशारा |
| टीएलडी नेमसर्वर | उस टीएलडी का रजिस्ट्री | डोमेन के ऑथॉरिटेटिव नेमसर्वर की ओर इशारा |
| ऑथॉरिटेटिव नेमसर्वर | आपका डीएनएस होस्ट (रूट ५३, क्लाउडफ़्लेयर, एनएस१, खुद का बाइंड/पावरडीएनएस) | example.com के लिए आपके प्रकाशित रिकॉर्ड रखता है |
रिकर्सिव भारी काम करता है। लैपटॉप लगभग कभी रूट या टीएलडी से सीधे बात नहीं करता। कॉर्पोरेट नेटवर्क और क्लाउड वीपीसी अक्सर सभी स्टब को कंपनी या वीपीसी रिकर्सिव से गुज़ारते हैं। इसलिए "घर पर रिज़ॉल्व होता है, क्लस्टर में नहीं" बग की असली श्रेणी है।
www.example.com ए रिकॉर्ड का सुखद पथ
१. ऐप या ब्राउज़र स्टब से पूछता है: "www.example.com का ए?"
२. स्टब कॉन्फ़िगर्ड रिकर्सिव से पूछता है (डीएचसीपी, /etc/resolv.conf, या प्लेटफ़ॉर्म डिफ़ॉल्ट)।
३. अगर रिकर्सिव के पास उस नाम और प्रकार का ताज़ा कैश है, तुरंत जवाब। खत्म।
४. नहीं तो रिकर्सिव रूट से शुरू करता है (या com. / example.com के कैश्ड एनएस इस्तेमाल करता है):
- रूट: "
com.के लिए इन टीएलडी एनएस से पूछो।" - टीएलडी: "
example.comके लिए इन ऑथॉरिटेटिव एनएस से पूछो" (अक्सर एनएस होस्ट के ग्लू ए/एएएए के साथ)। - ऑथॉरिटेटिव: "यह ए है (या सीनेम, या एनएक्सडोमेन, या नोडेटा)।" ५. रिकर्सिव टीटीएल (और फेलियर पर नेगेटिव-कैश नियमों) के अनुसार कैश करता है, स्टब को जवाब देता है। ६. क्लाइंट आईपी(ओं) से कनेक्शन खोलता है।
क्वेरी आमतौर पर पोर्ट ५३ पर यूडीपी होती हैं। बड़े या ट्रंकेटेड जवाब टीसीपी ५३ पर गिरते हैं। डीएनएस ओवर एचटीटीपीएस (डोएच) और डीएनएस ओवर टीएलएस (डोट) इन्हीं सवालों को एन्क्रिप्टेड ट्रांसपोर्ट में लपेटते हैं; पदानुक्रम नहीं बदलता।
इटेरेशन बनाम रिकर्शन
- रिकर्सिव क्वेरी: स्टब कहता है "मेरे लिए पूरा रिज़ॉल्व करो।" रिकर्सिव चलता है।
- इटरेटिव क्वेरी: सर्वर रेफ़रल लौटाता है ("इन अन्य सर्वरों से पूछो") न कि अंतिम जवाब। रिज़ॉल्वर रूट/टीएलडी/ऑथॉरिटेटिव के खिलाफ इटरेटिव क्वेरी इस्तेमाल करते हैं, जबकि रिकर्सिव क्लाइंट को सेवा देते हैं।
अगर आप dig को ऑथॉरिटेटिव सर्वर पर बिना रिकर्शन अपेक्षा के चलाएँ, रेफ़रल या रिकर्शन मना मिल सकता है। यह सामान्य है।
वे रिकॉर्ड प्रकार जो आप एडिट करेंगे
हर आरआर प्रकार की ज़रूरत नहीं। ये पाँच ज़्यादातर प्रोडक्ट काम कवर करते हैं।
ए और एएएए
| प्रकार | मतलब |
|---|---|
| ए | नाम का आईपीवी४ पता |
| एएएए | नाम का आईपीवी६ पता |
उदाहरण:
api.example.com. 300 IN A 203.0.113.10
api.example.com. 300 IN AAAA 2001:db8::10
कई ए/एएएए रिकॉर्ड का मतलब कई जवाब। क्लाइंट चुनता है (अक्सर पहला, कभी राउंड-रॉबिन या फ़ैमिली के बीच हैपी-आईबॉल्स)। ड्यूल-स्टैक यानी ए और एएएए दोनों; टूटा आईपीवी६ और जीवित एएएए क्लासिक "कुछ यूज़र को साइट नहीं खुलती" है।
सीनेम
सीनेम नाम को दूसरे नाम से जोड़ता है, आईपी से नहीं।
www.example.com. 300 IN CNAME lb.example.net.
नियम जो काटते हैं:
१. सीनेम वाले नाम पर उसी ओनर पर अन्य डेटा नहीं होना चाहिए (ए + सीनेम साथ नहीं)। एपेक्स/@ सीनेम अक्सर मना या वेंडर के अलियास/एनेम से बदला जाता है।
२. रिज़ॉल्वर चेन तब तक चलते हैं जब तक ए/एएएए न मिले (या फेल)। लंबी चेन लेटेंसी और फेलियर पॉइंट बढ़ाती है।
३. बीच के सीनेम का टीटीएल भी मायने रखता है; प्रभावी कैश जीवन चेन से सीमित होता है।
जब वेंडर टारगेट होस्टनेम का मालिक हो (सीडीएन, मैनेज्ड एलबी) तो सीनेम। जब आप नियंत्रित आईपी पिन करें तो ए/एएएए।
एमएक्स
एमएक्स मेल सिस्टम को बताता है डोमेन के लिए कहाँ डिलीवर करें।
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
कम प्रेफ़रेंस नंबर पहले आज़माया जाता है (१०, फिर २०)। एमएक्स टारगेट को ए/एएएए में रिज़ॉल्व होना चाहिए; जहाँ हो सके नंगे सीनेम पर एमएक्स न लगाएँ (कुछ प्रोवाइडर अब भी चेताते या तोड़ते हैं)।
टीएक्सटी
टीएक्सटी मुक्त पाठ है। आम उपयोग:
- मेल ऑथ के लिए एसपीएफ़, डीकेआईएम, डीएमएआरसी
- क्लाउड और सास डोमेन वेरिफ़िकेशन (
google-site-verification=…, एकमी डीएनएस-०१ चैलेंज) - मनमाने प्रोडक्ट फ़्लैग (दुर्लभ; असली कॉन्फ़िग स्टोर बेहतर)
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
लंबे टीएक्सटी कोट किए टुकड़ों में बँट सकते हैं। डिबग करते समय स्ट्रिंग क्रम से जोड़ें।
त्वरित नक्शा
| प्रकार | जवाब | आम ओनर |
|---|---|---|
| ए / एएएए | कहाँ कनेक्ट करें (आईपी) | एपीआई होस्ट, एपेक्स (अगर अलियास नहीं) |
| सीनेम | कैनॉनिकल नाम | www, वेंडर-होस्टेड सबडोमेन |
| एमएक्स | मेल एक्सचेंजर | एपेक्स / मेल डोमेन |
| टीएक्सटी | नीति और सबूत स्ट्रिंग | एपेक्स, _dmarc, एकमी नाम |
एनएस और एसओए ज़ोन अधिकार और नेगेटिव कैश के लिए मायने रखते हैं। एसआरवी सर्विस डिस्कवरी और कुछ प्रोटोकॉल में आता है। जब खुद ज़ोन या कुबेरनेट्स-स्टाइल डिस्कवरी चलाएँ तब सीखें; रोज़ के ऐप डिप्लॉय मुख्यतः ऊपर के पाँच छूते हैं।
टीटीएल और कैश: डीएनएस "हमेशा क्यों लेता है"
टीटीएल (टाइम टू लिव) बताता है कैशिंग रिज़ॉल्वर अधिकार से दोबारा पूछे बिना जवाब कितनी देर दोबारा इस्तेमाल कर सकता है। रिकॉर्ड पर सेकंड में होता है।
api.example.com. 60 IN A 203.0.113.10
यहाँ रिकर्सिव उस ए को अधिकतम ६० सेकंड कैश कर सकते हैं। ब्राउज़र, ओएस, भाषा रनटाइम, जेवीएम, और साइडकार उसके ऊपर भी कैश कर सकते हैं। इसलिए "एक घंटे पहले टीटीएल घटाया" का मतलब नहीं कि हर क्लाइंट एक ही सेकंड में पलट गया।
व्यावहारिक टीटीएल आदतें
| स्थिति | आम टीटीएल दायरा | नोट |
|---|---|---|
| स्थिर एपेक्स / ब्रांड साइट | ३००से-३६००से | ठीक जब आईपी शायद ही हिलें |
| कटओवर से पहले | जल्दी घटाएँ (६०से-३००से) | बदलाव विंडो से पहले टीटीएल घटाएँ ताकि कैश खत्म हों |
| कटओवर के बाद | स्थिर होने पर फिर बढ़ाएँ | ऑथॉरिटेटिव पर मार कम, छोटे ब्लिप सोखे |
| बार-बार फ़ेलओवर | कम टीटीएल + हेल्थ-अवेयर डीएनएस या डीएनएस से बाहर छोटा रास्ता | अकेला डीएनएस मोटा फ़ेलओवर औज़ार है |
नेगेटिव जवाब (एनएक्सडोमेन, नोडेटा) भी कैश होते हैं, अक्सर एसओए मिनिमम / नेगेटिव-टीटीएल फ़ील्ड से। गलत डिलीट अधिकार पर "ठीक" होने के बावजूद मिनटों चिपक सकता है।
जवाब कहाँ छिपते हैं
१. ब्राउज़र डीएनएस कैश २. ओएस स्टब कैश ३. कॉर्पोरेट या वीपीसी रिकर्सिव कैश ४. पब्लिक रिज़ॉल्वर कैश (कई यूज़र में साझा) ५. ऑथॉरिटेटिव (सत्य का स्रोत, पर हर क्लाइंट अभी वही नहीं देखता)
जब कोई कहे "डीएनएस अपडेट हो गया," पूछें कौन सी परत जाँची। अधिकार सही + रिकर्सिव पुराना, कटओवर की आम कहानी है।
डिग से डिबग
dig मानक औज़ार है। साफ़ फ़्लैग और पूरे संदेश के लिए nslookup से बेहतर।
बुनियादी लुकअप
# सिस्टम रिज़ॉल्वर से डिफ़ॉल्ट ए
dig api.example.com
# खास प्रकार
dig AAAA api.example.com
dig MX example.com
dig TXT example.com
dig CNAME www.example.com
# सिर्फ़ छोटा जवाब
dig +short api.example.com
dig +short MX example.com
खास सर्वर से पूछें
# पब्लिक रिकर्सिव
dig @1.1.1.1 api.example.com
dig @8.8.8.8 api.example.com
# ऑथॉरिटेटिव (पैरेंट या पैनल से एनएस)
dig @ns-123.awsdns-45.com api.example.com
ऑथॉरिटेटिव बनाम रिकर्सिव तुलना करें। अगर अधिकार सही है और गूगल/क्लाउडफ़्लेयर अभी पुराना आईपी दिखाते हैं, तो टीटीएल का इंतज़ार है या आप गलत रिकॉर्ड सेट देख रहे हैं (गलत नाम, गलत प्रकार, गलत अकाउंट ज़ोन)।
पदानुक्रम ट्रेस करें
dig +trace api.example.com
+trace ठंडे रिकर्सिव की तरह रूट → टीएलडी → ऑथॉरिटेटिव चलता है। "डेलिगेशन टूटा?" और ग्लू समस्याओं के लिए बढ़िया।
उपयोगी फ़्लैग
| फ़्लैग | उपयोग |
|---|---|
+short |
स्क्रिप्ट के लिए संक्षिप्त जवाब |
+norecurse |
आरडी बिट के बिना; रेफ़रल देखें |
+trace |
रूट से पूरा इटरेटिव पथ |
+dnssec |
वैलिडेट करते समय आरआरएसआईजी/डीएनएसकी डेटा |
+tcp |
टीसीपी ज़बरदस्ती (ट्रंकेशन या फ़ायरवॉल) |
-p 53 |
गैर-डिफ़ॉल्ट पोर्ट (लैब / वैकल्पिक लिसनर) |
स्टेटस लाइन पढ़ें
HEADER सेक्शन में स्टेटस मायने रखता है:
| स्टेटस | मतलब |
|---|---|
| एनओएरर | क्वेरी सफल (नोडेटा पर आंसर खाली हो सकता है) |
| एनएक्सडोमेन | नाम मौजूद नहीं |
| सर्वफ़ेल | रिज़ॉल्वर फेल (टूटी चेन, डीएनएससेक, अपस्ट्रीम टाइमआउट) |
| रिफ़्यूज़्ड | सर्वर उस क्वेरी का जवाब नहीं देगा |
फ़्लैग भी देखें: aa मतलब उस ज़ोन के लिए ऑथॉरिटेटिव जवाब। ra मतलब रिकर्शन उपलब्ध। ad डीएनएससेक वैलिडेशन में ऑथेंटिकेटेड डेटा से जुड़ा।
उदाहरण: डिग से कटओवर चेकलिस्ट
# 1. पैरेंट किन एनएस को डेलिगेट करता है?
dig NS example.com +short
# 2. अधिकार अभी क्या कहता है?
dig @YOUR_AUTH_NS api.example.com A +noall +answer
# 3. बड़े पब्लिक रिकर्सिव क्या कहते हैं?
dig @1.1.1.1 api.example.com A +noall +answer
dig @8.8.8.8 api.example.com A +noall +answer
# 4. कैश्ड जवाब पर बचा टीटीएल (रिकर्सिव से)
dig api.example.com A
# आंसर पर टीटीएल नंबर देखें; उस रिज़ॉल्वर पर घटता जाता है
अगर स्प्लिट-होराइज़न डीएनएस है (अंदरूनी जवाब पब्लिक से अलग), हमेशा उसी नेटवर्क वर्ग के होस्ट से टेस्ट करें जहाँ फेलिंग क्लाइंट है।
वे फेलियर मोड जो इंजीनियर सच में खाते हैं
१. कटओवर से पहले टीटीएल नहीं घटाया। पुराने आईपी दुनिया भर के रिकर्सिव कैश में चिपकते हैं। लोकप्रिय रिकॉर्ड पर घंटों या एक दिन पहले टीटीएल घटाएँ।
२. एपेक्स पर सीनेम। कुछ यूआई देते हैं; कई मानक और प्रोवाइडर नहीं। अलियास/एनेम या सादा ए/एएएए।
३. गलत रिकॉर्ड प्रकार। क्लाइंट एएएए ढूँढ़ते हैं, आपने सिर्फ़ ए छपा (या उलटा)। या मेल टूटता है क्योंकि एमएक्स पुराने होस्ट पर है जबकि ए अपडेट हुआ।
४. ग्लू / एनएस बेमेल। रजिस्ट्रार पर नेमसर्वर बदले पर नया ज़ोन खाली, या एनएस होस्ट रिज़ॉल्व नहीं। dig +trace दिखाता है।
५. कॉर्पोरेट रिकर्सिव ओवरराइड। घर पर लैपटॉप 1.1.1.1 इस्तेमाल करता है; दफ़्तर में ट्रैफ़िक फ़िल्टरिंग रिज़ॉल्वर से गुज़रता है, अपना कैश और नीति।
६. ऐप-स्तरीय डीएनएस कैश। जावा, नोड कनेक्शन पूल, एनवॉय, मोबाइल ओएस कैश आपके "डिग हरा तो ऐप हरा" मॉडल को नज़रअंदाज़ करते हैं।
७. सर्च डोमेन और एनडॉट्स। /etc/resolv.conf सर्च लिस्ट कुबेरनेट्स में api को api.default.svc.cluster.local बना देती है। यह डीएनएस है, और हैरान करता है।
डीएनएस तब सही है जब नाम, प्रकार, व्यू (पब्लिक बनाम प्राइवेट), और कैश परत उसी क्लाइंट से मेल खाएँ जिसकी आपको चिंता है। सिर्फ़ ऑथॉरिटेटिव पैनल ठीक करना ज़रूरी है, पर्याप्त नहीं।
रखने लायक न्यूनतम मानसिक मॉडल
१. स्टब रिकर्सिव से पूछता है; रिकर्सिव रूट → टीएलडी → ऑथॉरिटेटिव चलता है (जब तक कैश हिट न हो)।
२. आप ऑथॉरिटेटिव सर्वर पर रिकॉर्ड (ए, एएएए, सीनेम, एमएक्स, टीएक्सटी, …) प्रकाशित करते हैं।
३. टीटीएल नियंत्रित करता है कैश आपके एडिट से कितना पिछड़ सकते हैं।
४. dig @server name TYPE बताता है कोई परत अभी क्या मानती है।
५. डीएनएस बदलाव के बाद आउटेज आमतौर पर कैश लैग, गलत नाम/प्रकार, या टूटा डेलिगेशन होते हैं, "इंटरनेट डाउन" नहीं।
वह पथ और dig सीख लें तो यह रहस्य कमांड नहीं, बल्कि जब होस्टनेम संदिग्ध हो तब पहला औज़ार बन जाता है।