यह स्पष्ट रूप से एक क्यू एंड ए का मंचन है, लेकिन यह अक्सर लोगों को भ्रमित करने के लिए जाता है और मुझे विषय को कवर करने वाला एक विहित प्रश्न नहीं मिल सकता है।
dig +traceएक महान नैदानिक उपकरण है, लेकिन इसके डिजाइन का एक पहलू व्यापक रूप से गलत समझा गया है: हर सर्वर का आईपी जिसे क्वियर किया जाएगा, वह आपके रिसॉल्वर लाइब्रेरी से प्राप्त किया जाता है । यह बहुत आसानी से अनदेखा कर दिया जाता है और अक्सर एक समस्या बन जाती है जब आपके स्थानीय कैश के पास नामांकित कैश के लिए गलत उत्तर होता है।
विस्तृत विश्लेषण
आउटपुट के नमूने के साथ टूटना आसान है; मैं पहले एनएस के प्रतिनिधिमंडल के सामने सब कुछ छोड़ दूंगा।
; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com
;; global options: +cmd
. 121459 IN NS d.root-servers.net.
. 121459 IN NS e.root-servers.net.
. 121459 IN NS f.root-servers.net.
. 121459 IN NS g.root-servers.net.
. 121459 IN NS h.root-servers.net.
. 121459 IN NS i.root-servers.net.
. 121459 IN NS j.root-servers.net.
. 121459 IN NS k.root-servers.net.
. 121459 IN NS l.root-servers.net.
. 121459 IN NS m.root-servers.net.
. 121459 IN NS a.root-servers.net.
. 121459 IN NS b.root-servers.net.
. 121459 IN NS c.root-servers.net.
e.root-servers.net. 354907 IN A 192.203.230.10
f.root-servers.net. 100300 IN A 192.5.5.241
f.root-servers.net. 123073 IN AAAA 2001:500:2f::f
g.root-servers.net. 354527 IN A 192.112.36.4
h.root-servers.net. 354295 IN A 128.63.2.53
h.root-servers.net. 108245 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 355208 IN A 192.36.148.17
i.root-servers.net. 542090 IN AAAA 2001:7fe::53
j.root-servers.net. 354526 IN A 192.58.128.30
j.root-servers.net. 488036 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 354968 IN A 193.0.14.129
k.root-servers.net. 431621 IN AAAA 2001:7fd::1
l.root-servers.net. 354295 IN A 199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms
. IN NS(रूट नेमसर्वर) के लिए प्रारंभिक क्वेरी स्थानीय रिज़ॉल्वर को हिट करती है, जो इस मामले में कॉमकास्ट है। ( 75.75.75.75) यह स्पॉट करना आसान है।- अगली क्वेरी के लिए है
serverfault.com. IN Aऔर इसके खिलाफ चलता है e.root-servers.net., बेतरतीब ढंग से रूट नेमवेरर्स की सूची से चुना गया जो हमें अभी मिला है। यह एक आईपी पता है 192.203.230.10, और तब से हम है +additionalसक्षम यह प्रतीत होता है गोंद से आ रही।
- चूंकि यह serverfault.com के लिए आधिकारिक नहीं है, यह
com.TLD नेमसर्वरों को सौंपा गया है ।
- यहां आउटपुट से जो स्पष्ट नहीं है वह
digयह है कि e.root-servers.net.गोंद से आईपी पते को प्राप्त नहीं किया गया है।
पृष्ठभूमि में, यह वही है जो वास्तव में हुआ था:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)
+traceधोखा दिया और गोंद को सलाह देने के बजाय अगले हॉप नेमसर्वर का आईपी पता प्राप्त करने के लिए स्थानीय रिज़ॉल्वर से परामर्श किया। ख़ुशामदी!
यह आमतौर पर "काफी अच्छा" है और अधिकांश लोगों के लिए समस्या का कारण नहीं होगा। दुर्भाग्य से, किनारे के मामले हैं। यदि किसी भी कारण से आपका अपस्ट्रीम DNS कैश नेमसर्वर के लिए गलत उत्तर प्रदान कर रहा है, तो यह मॉडल पूरी तरह से टूट जाता है।
वास्तविक दुनिया उदाहरण:
- डोमेन समाप्त हो रहा है
- गोंद रजिस्ट्रार पुनर्निर्देशन नेमसर्वर में पुन: अभिहित किया जाता है
- bogus IP को ns1 और ns2.yourdomain.com के लिए कैश किया जाता है
- डोमेन को पुनर्स्थापित गोंद के साथ नवीनीकृत किया जाता है
- फर्जी नाम वाले आईपी के साथ कोई भी कैश लोगों को एक वेबसाइट पर भेजना जारी रखता है जो कहता है कि डोमेन बिक्री के लिए है
उपरोक्त मामले में, +traceयह सुझाव देगा कि डोमेन स्वामी के स्वयं के नेमवेर्स समस्या के स्रोत हैं, और आप एक ग्राहक को गलत तरीके से बताने से दूर हैं कि उनके सर्वर गलत हैं। चाहे वह ऐसी कोई चीज़ हो जो आप कर सकते हैं (या करने के लिए तैयार हैं) एक और कहानी है, लेकिन सही जानकारी होना ज़रूरी है।
dig +trace एक महान उपकरण है, लेकिन किसी भी उपकरण की तरह, आपको यह जानने की जरूरत है कि यह क्या करता है और क्या नहीं करता है, और अपर्याप्त साबित होने पर समस्या को मैन्युअल रूप से समस्या का निवारण कैसे करें।
संपादित करें:
यह भी ध्यान दिया जाना चाहिए कि उपनामों पर इंगित करने वाले रिकॉर्ड के dig +traceबारे में आपको चेतावनी नहीं देगा । यह एक RFC उल्लंघन है जो ISC BIND (और संभवतः अन्य) सही करने का प्रयास नहीं करेगा। यह आपके स्थानीय रूप से कॉन्फ़िगर किए गए नेमसर्वर से प्राप्त रिकॉर्ड को स्वीकार करने में पूरी तरह से खुश होगा , जबकि अगर BIND पूर्ण पुनरावृत्ति कर रहा था, तो यह एक SERVFAIL के साथ पूरे क्षेत्र को अस्वीकार कर देगा।NSCNAME+traceA
यदि गोंद मौजूद है, तो यह समस्या निवारण के लिए मुश्किल हो सकता है; यह ठीक काम करेगा जब तक कि NS रिकॉर्ड्स को ताज़ा नहीं किया जाता है , तब तक अचानक टूट जाता है। एक उपनाम पर एक रिकॉर्ड अंक जब Glueless प्रतिनिधिमंडल हमेशा BIND की पुनरावृत्ति को तोड़ देगा NS।
+nssearch?