मुझे आश्चर्य हो रहा है कि एक DNS सर्वर को क्वेरी करने और कैशिंग (के साथ dig) को बायपास करने का एक तरीका है । अक्सर मैं DNS सर्वर पर एक ज़ोन बदलता हूं और मैं जांचना चाहता हूं कि क्या यह मेरे वर्कस्टेशन से सही तरीके से हल होता है। लेकिन जब से सर्वर ने अनुरोधों को हल किया है, मुझे अक्सर पुराने मिलते हैं। सर्वर को पुनः लोड करना या लोड करना वास्तव में कुछ अच्छा नहीं है।
जवाबों:
आप @किसी विशेष सर्वर से डोमेन देखने के लिए सिंटैक्स का उपयोग कर सकते हैं । यदि DNS सर्वर उस डोमेन के लिए आधिकारिक है, तो प्रतिक्रिया कैश्ड परिणाम नहीं होगी।
dig @ns1.example.com example.com
आप NSएक डोमेन के लिए रिकॉर्ड के लिए पूछकर आधिकारिक सर्वर पा सकते हैं :
dig example.com NS
+norecurse। +recurseडिफ़ॉल्ट रूप से कभी-कभी एक DNS सर्वर आपके प्रश्न की पूरी तरह से व्याख्या करने के तरीके को बदल देगा।
+traceलेकिन कैशिंग से सावधान रहें। एंड्रयू बी ने एक अच्छा विवरण लिखा है कि नाम बदलने वालों के बदलने के इंतजार में कैशिंग आपको कैसे चकमा दे सकती है।
dig @8.8.8.8 example.com। रिकॉर्ड वहाँ बहुत तेजी से दिखाई देते हैं।
इसके कैश का उपयोग किए बिना जवाब देने के लिए मजबूर करने के लिए कोई मानक, विश्वसनीय तरीका नहीं है। अपने आप में एक नेमवेर नहीं है, यह केवल एक उपकरण है, जो आपके द्वारा कॉन्फ़िगर किए गए नेमसर्वरों में से जो भी आपने कॉन्फ़िगर किया है, जो कि DNS डीएनएस अनुरोधों का उपयोग करता है। वहाँ है "प्रत्यावर्तन का उपयोग नहीं करते" कहने का एक तरीका है, लेकिन यह नहीं है कि आप क्या चाहते हैं - यह बस व्यापक इंटरनेट पर डोमेन नाम के किसी भी लुकअप रोका जा सके।
यदि आप किसी कैशियर को उसके कैशे से जवाब देने से रोकना चाहते हैं, तो आपको यह प्राप्त करना होगा कि नेमसर्वर पर कॉन्फ़िगरेशन को बदलकर , लेकिन यदि आप नेमसर्वर को नियंत्रित नहीं करते हैं, तो आप ऐसा नहीं कर सकते।
हालाँकि, आप कॉन्फ़िगर किए गए नेमसर्वर को बायपास करने के लिए खुदाई कर सकते हैं, और अपना स्वयं का पुनरावर्ती अनुरोध कर सकते हैं जो रूट सर्वर पर वापस जाता है। ऐसा करने के लिए, +traceविकल्प का उपयोग करें ।
dig example.com +trace
व्यवहार में, क्योंकि यह केवल आपके स्थानीय कैशिंग रिज़ॉल्वर के बजाय आधिकारिक सर्वर को क्वेरी करेगा, परिणाम तब भी बासी नहीं होगा, यदि वे सर्वर आंतरिक कैशिंग को नियोजित करते हैं। उपयोग करने +traceका अतिरिक्त लाभ यह है कि आपको पथ के साथ किए गए सभी अलग-अलग अनुरोध देखने को मिलते हैं।
+norecurseबस नेमसेवर को बताता है कि उसके पास जो भी जानकारी है (कैश्ड जानकारी सहित, यदि कोई है), तो वह सही नहीं है। +traceकाम करेगा क्योंकि यह एक आधिकारिक सर्वर के लिए सभी तरह से पुनरावृत्ति श्रृंखला का पालन करेगा।
+norecurseसिफारिश को हटाने के लिए संशोधित किया है क्योंकि यह समस्या को भ्रमित करता है।
यहाँ नोट करने के लिए कुछ महत्वपूर्ण है, जो मुझे +traceलगता है कि कई लोग कभी भी शामिल नहीं करते हैं जब बात करते हैं कि +traceइसका मतलब है कि खोदने वाला ग्राहक ट्रेस करेगा, न कि आपके कॉन्फ़िगरेशन में निर्दिष्ट DNS सर्वर (/etc/resolv.conf)। तो, दूसरे शब्दों में, आपका खुदाई क्लाइंट एक पुनरावर्ती DNS सर्वर की तरह काम करेगा, क्या आपको यह पूछना चाहिए। लेकिन - महत्वपूर्ण बात, आपको कैश नहीं मिला है।
अधिक विवरण - इसलिए यदि आपने पहले ही mxउपयोग करने के लिए रिकॉर्ड मांगा है dig -t mx example.comऔर आपका /etc/resolv.conf 8.8.8.8 है तो ज़ोन के टीटीएल के अंदर कुछ भी करने से कैश्ड परिणाम वापस आ जाएगा। एक तरह से, यदि आप अपने स्वयं के क्षेत्र के बारे में कुछ खोज रहे हैं और Google इसे कैसे देखता है, तो आपने अपने ज़ोन के TTL के लिए Google के साथ अपने DNS परिणामों को जहर दे दिया है। बुरा नहीं अगर आपके पास एक छोटा टीटीएल है, तो कुछ हद तक बकवास अगर आपके पास 1 आर है।
इसलिए, जब +traceआप Google को FIRST समय के लिए पूछ रहे थे , तो आपको यह देखने में मदद मिलेगी कि WOULD क्या है, और इसमें कोई कैश्ड प्रविष्टि नहीं है, यह आपको एक गलत विचार दे सकता है कि Google सभी को वही बताएगा जो आपका +traceपरिणाम था, जो यदि आप पहले से पूछ चुके हैं और आपके पास लंबे समय तक टीटीएल है, तो यह नहीं होगा, क्योंकि यह तब तक कैश से सेवा करेगा जब तक कि टीटीएल की समय सीमा समाप्त नहीं हो जाती - यह वही होगा जो आपके द्वारा +traceबताए गए तरीके से काम करेगा।
IMO का बहुत अधिक विवरण नहीं हो सकता है।
dig mydomain.com +traceबस मुझे resolvdस्टब से परिणाम देता है 127.0.0.53। देखें github.com/systemd/systemd/issues/5897
+traceखुदाई का उपयोग निर्दिष्ट नेमसर्वर (उदाहरण के लिए, 8.8.8.8 यदि आपने क्या कॉन्फ़िगर किया है) का उपयोग करके पहले लुकअप (रूट ज़ोन) के लिए ट्रेस शुरू होता है , लेकिन इसके बाद यह आगे के प्रश्नों के लिए दिए गए नेमसर्वर का उपयोग करता है। इसलिए यदि आपका कॉन्फ़िगर किया गया नेमसेवर काम नहीं कर रहा है या रूट नेमसर्वर्स के लिए किसी क्वेरी का ठीक से जवाब नहीं देता है, तो आपको समस्या हो सकती है (जैसा कि ऊपर टिप्पणी में है)।
यह बैश example.com की DNS प्रविष्टियों को खोदेगा, जिसमें यह पहली बार सूचीबद्ध सर्वर है:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
यहाँ एक .zshrc (और शायद .bashrc) के लिए एक उपनाम के समान है:
# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }
यहाँ के लिए उत्पादन है: /।
☀ checkdns slashdot.org dev
-->Server DNS Query
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org. 21600 IN SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org. 86400 IN NS ns3.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns4.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns0.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns2.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns1.dnsmadeeasy.com.
slashdot.org. 3600 IN MX 10 mx.sourceforge.net.
slashdot.org. 3600 IN TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org. 3600 IN TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org. 300 IN A 216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms
--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms
यह समाधान याद करने के लिए अव्यवहारिक होने के लिए पर्याप्त जटिल है, लेकिन समस्या को ठीक नहीं करने के लिए पर्याप्त सरल है। digमेरी ख़ासियत नहीं है - सुधारों का स्वागत है :-)