सवाल कैश का उपयोग किए बिना हल करने के लिए फोर्स खोदें


मैं सोच रहा हूं कि एक DNS सर्वर और बाईपास कैशिंग पूछने का कोई तरीका है (के साथ dig)। अक्सर मैं DNS सर्वर पर एक ज़ोन बदलता हूं और मैं यह जांचना चाहता हूं कि यह मेरे वर्कस्टेशन से सही तरीके से हल हो जाए या नहीं। लेकिन चूंकि सर्वर ने अनुरोधों को हल किया है, इसलिए मुझे अक्सर पुराने लोग मिलते हैं। सर्वर को पुनरारंभ करना या लोड करना वास्तव में कुछ अच्छा नहीं है।


70
2018-03-21 17:15


मूल




जवाब:


आप इसका उपयोग कर सकते हैं @ किसी विशेष सर्वर से डोमेन को देखने के लिए वाक्यविन्यास। यदि DNS सर्वर उस डोमेन के लिए आधिकारिक है, तो प्रतिक्रिया कैश्ड परिणाम नहीं होगी।

dig @ns1.example.com example.com

आप पूछने के द्वारा आधिकारिक सर्वर पा सकते हैं NS एक डोमेन के लिए रिकॉर्ड:

dig example.com NS

100
2018-03-21 17:21



ओह ठीक है। हाँ मैं @ वाक्यविन्यास से परिचित था, लेकिन इसके बजाय आधिकारिक सर्वर से पूछने का विचार नहीं था। धन्यवाद! - Daniel
साइड नोट: उन मामलों में जहां आप यह देखने की कोशिश कर रहे हैं कि एक कैशिंग सर्वर क्या प्रतिक्रिया प्राप्त करेगा, +norecurse इसकी सिफारिश की जाती है। +recurse डिफ़ॉल्ट रूप से चालू होता है कभी-कभी एक DNS सर्वर आपके प्रश्न को पूरी तरह से समझता है। - Andrew B
क्या होगा यदि आप आधिकारिक सर्वरों को बदलने की प्रतीक्षा कर रहे हैं? - guaka
@ KasperSouren क्या आप आधिकारिक सर्वर या अभिभावक पर गोंद रिकॉर्ड पर एनएस रिकॉर्ड के बारे में बात कर रहे हैं? आप माता-पिता के साथ पा सकते हैं +trace लेकिन कैशिंग से सावधान रहें। एंड्रयू बी ने नेमसर्वर बदलने के लिए प्रतीक्षा करते समय कैशिंग आपको कैसे चालित कर सकते हैं, इस बारे में एक अच्छी व्याख्या लिखी। - Ladadadada
आप Google डीएनएस पर भी जांच सकते हैं dig @8.8.8.8 example.com। रिकॉर्ड वहां बहुत तेजी से दिखाई देते हैं। - machineaddict


अपने कैश का उपयोग किए बिना जवाब देने के लिए नेमसर्वर को मजबूर करने के लिए कोई मानक, विश्वसनीय तरीका नहीं है। खुद को खोदना एक नेमसर्वर नहीं है, यह केवल एक उपकरण है जो मानक DNS अनुरोधों का उपयोग करके आपके द्वारा कॉन्फ़िगर किए गए नेमसर्वर पर आपकी क्वेरी को पास करता है। क्या आप वहां मौजूद हैं है "रिकर्सन का उपयोग न करें" कहने का एक तरीका है, लेकिन यह वही नहीं है जो आप चाहते हैं - यह व्यापक इंटरनेट पर डोमेन नामों के किसी भी लुकअप को रोक देगा।

यदि आप किसी नेमसर्वर को अपने कैश से प्रतिक्रिया देने से रोकना चाहते हैं, तो आपको कॉन्फ़िगरेशन को बदलकर इसे प्राप्त करना होगा नेमसर्वर पर, लेकिन अगर आप नेमसर्वर को नियंत्रित नहीं करते हैं, तो आप ऐसा नहीं कर सकते हैं।

हालांकि, आप खोद सकते हैं उपमार्ग कॉन्फ़िगर किए गए नेमसर्वर, और अपना स्वयं का रिकर्सिव अनुरोध करें जो रूट सर्वर पर वापस जाता है। ऐसा करने के लिए, का प्रयोग करें +trace विकल्प।

dig example.com +trace

अभ्यास में यह केवल आपके स्थानीय कैशिंग रिज़ॉल्वर की बजाय आधिकारिक सर्वर से पूछताछ करेगा, परिणाम तब भी बेवकूफ नहीं होंगे जब वे सर्वर आंतरिक कैशिंग को नियोजित करते हैं। उपयोग करने का जोड़ा लाभ +trace यह है कि आप पथ के साथ किए गए सभी अलग-अलग अनुरोधों को देखते हैं।


19
2018-05-31 15:00



का उपयोग करते हुए +norecurse बस नेमसर्वर को जो भी जानकारी है (कैश की गई जानकारी, यदि कोई हो) लौटने के लिए कहती है, तो यह सही नहीं है। +trace काम करेगा क्योंकि यह एक आधिकारिक सर्वर के लिए सभी तरह से रिकर्सन श्रृंखला का पालन करेगा। - Raman
ध्यान दें कि मैंने इस जवाब को हटाने के लिए संशोधित किया है +norecurse सिफारिश के रूप में इस मुद्दे को उलझन में डाल दिया। - thomasrutter


यहां ध्यान देने योग्य कुछ महत्वपूर्ण है, जो मुझे लगता है कि कई लोगों के बारे में बात करते समय कभी भी शामिल नहीं होता है +trace क्या इसका उपयोग कर रहा है +trace इसका मतलब है कि डिग क्लाइंट ट्रेस करेगा, न कि आपके कॉन्फ़िगरेशन (/etc/resolv.conf) में निर्दिष्ट DNS सर्वर। तो, दूसरे शब्दों में, आपका डिग क्लाइंट एक रिकर्सिव DNS सर्वर की तरह काम करेगा, क्या आप इसे पूछना चाहिए। लेकिन - महत्वपूर्ण बात यह है कि आपको कैश नहीं मिला है।

अधिक जानकारी - इसलिए यदि आप पहले ही एक के लिए पूछ चुके हैं mx रिकॉर्ड का उपयोग करें dig -t mx example.com और आपका /etc/resolv.conf 8.8.8.8 है तो ज़ोन के टीटीएल के अंदर कुछ भी करने से कैश्ड परिणाम वापस आ जाएगा। एक तरह से, यदि आप अपने क्षेत्र के बारे में कुछ ढूंढ रहे हैं और Google इसे कैसे देखता है, तो आपने अपने जोन के टीटीएल के लिए Google के साथ अपने DNS परिणामों को जहर दिया है। यदि आपके पास एक छोटा टीटीएल है, तो बुरा नहीं है, अगर आपके पास 1 घंटा है तो कुछ हद तक बकवास।

तो, जबकि +trace यदि आप पहली बार Google से पूछ रहे थे और इसमें कोई कैश प्रविष्टि नहीं है, तो यह देखने में आपकी सहायता करेगा कि यह आपको एक झूठा विचार दे सकता है कि Google आपको सभी को वही बताएगा जो आपके जैसा है +trace नतीजा यह था कि अगर आप पहले पूछे गए थे और एक लंबा टीटीएल नहीं है, क्योंकि यह टीटीएल की अवधि समाप्त होने तक कैश से तब तक सेवा करेगा - फिर यह आपके जैसा ही होगा +traceपता चला।

आईएमओ बहुत ज्यादा जानकारी नहीं हो सकती है।


10
2018-05-24 23:10



क्या खुदाई का अपना कैश होता है या ओएस कैश का उपयोग करता है? - CMCDragonkai
डिग में कैश नहीं है। यदि अपस्ट्रीम नेमसर्वर इसका उपयोग कर रहा है, हालांकि, इससे इसका लाभ होता है। - thomasrutter
dig mydomain.com +trace बस मुझे वापस देता है resolvd से स्टब परिणाम 127.0.0.53। देख github.com/systemd/systemd/issues/5897 - James Bowery
उपयोग करते समय +trace गड्ढा करना शुरू करना पहले लुकअप (रूट ज़ोन) के लिए निर्दिष्ट नेमसर्वर (उदाहरण के लिए, 8.8.8.8 अगर आपने कॉन्फ़िगर किया है) का उपयोग कर ट्रेस, लेकिन इसके बाद यह आगे के प्रश्नों के लिए लौटा नेमसर्वर का उपयोग करता है। इसलिए यदि आपका कॉन्फ़िगर किया गया नेमसर्वर काम नहीं कर रहा है या रूट नेमसर्वर के लिए किसी क्वेरी का उचित प्रतिसाद नहीं देता है, तो आपको समस्याएं हो सकती हैं (उपरोक्त टिप्पणी में)। - thomasrutter


यह बैश example.com की DNS प्रविष्टियों को इसके पहले सूचीबद्ध नाम सर्वर से खो देगा:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • Example.com के प्राप्त करने के लिए आंतरिक खुदाई Google के DNS (8.8.8.8) से पूछती है नेमसर्वर।
  • बाहरी खुदाई example.com का पहला नाम सर्वर पूछताछ करता है।

यहां .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 मेरी विशेषता नहीं है -  सुधार स्वागत है :-)


1
2018-01-11 17:49