DNS रिज़ॉल्यूशन त्रुटि डीबग करना

मैं auth.otc.t-systems.comCloudflare के सर्वर के साथ डोमेन के लिए DNS रिज़ॉल्यूशन त्रुटि डिबग कर रहा हूं , लेकिन अटक गया। अजीब बात यह है कि क्वेरी को चलाने वाली मशीन के आधार पर लुकअप सफल / विफल हो जाता है, लेकिन मैं यह नहीं पता लगा सकता हूं कि कॉन्फ़िगरेशन कहां भिन्न है।

विफलता हमेशा निम्न संदेश के साथ होती है: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 Cloudflare का DNS है।

मैंने अब तक क्या प्रयास किया है:

nslookup auth.otc.t-systems.com 1.1.1.1विभिन्न मशीनों पर चल रहा है :
- यह काम और घर के इंटरनेट के साथ मेरी मशीन पर विफल रहता है (हालांकि यह दोनों मामलों में Google के DNS के साथ सफल होता है)।
- यह काम इंटरनेट के साथ एक सहयोगी मशीन पर विफल रहता है।
- यह एक ssh सत्र में एक दूरस्थ सर्वर के लिए सफल होता है।
अब मुझे लगता है कि हमारे काम के इंटरनेट पर कुछ अजीब कॉन्फ़िगरेशन है, जिससे लुकअप विफल हो जाता है। हालाँकि, मुझे नहीं पता कि मुझे क्या देखना चाहिए और मुझे कुछ ऑनलाइन nslookup सेवाएं भी मिलीं जो असफल रहीं:
- विफल: https://network-tools.com/nslook/Default.asp?domain=auth.otc.t-systems.com&type=1&server=1.1.1.1&class=1&port=53&tout=5000&go.x=21&go.y=13
- काम करता है: http://www.kloth.net/services/nslookup.php

कोई संकेत है कि मैं इसे आगे कैसे डिबग कर सकता हूं?

networking domain-name-system

— थॉमस ओबरमूलर
स्रोत

तुम भी साथ की कोशिश की 1.0.0.1या यदि आप आईपीवी 6 है 2606:4700:4700::1111और 2606:4700:4700::1001, वे सब CloudFlare भी हैं। इसके अलावा ब्लॉग पर देखें ।cloudflare.com / fixing - reachability - to - 1-1-1-1-1 - glo और इसके अंतिम पैराग्राफ में समस्या की रिपोर्ट करने के तरीके दिए गए हैं।

— पैट्रिक मेव्ज़ेक

जवाबों:

खुदाई का उपयोग करके देखें। बीस साल पहले उन्होंने nslookup को अपदस्थ करने की कोशिश की थी, लेकिन इसकी दृढ़ता अब मांसपेशियों की स्मृति में आ गई है और इससे छुटकारा पाना असंभव है, लेकिन खुदाई कहीं बेहतर है। उदाहरण के लिए।

dig +trace auth.otc.t-systems.com @1.1.1.1

आपके लिए पूरी तरह से प्रस्ताव का पता लगाएगा, और आप देख सकते हैं कि वे कहां भिन्न हैं।

— Sirch
स्रोत

धन्यवाद, मुझे नहीं पता था कि nslookup के बारे में। मैंने अब खुदाई कमांड की कोशिश की है और अजीब तरह से यह मेरी मशीन पर सही आईपी लौटाता है। मैंने अपनी मशीन और स्थानीय मशीन दोनों पर कमांड से आउटपुट पोस्ट किया है यहाँ gist.github.com/thomas88/600d367387505a13223a5270c89eedda । जो भी खुदाई अलग होती है, मेरा ब्राउज़र (मैक पर क्रोम) nslookup के अनुरूप अधिक लगता है - यह पते को हल नहीं कर सकता है।

— थॉमस ओबमुलर

इस क्वेरी के बीच digऔर इसके nslookupलिए अलग-अलग परिणामों की अपेक्षा करने का कोई कारण नहीं है । हालाँकि, 1.1.1.1यह एक अंदाज़ा है कि परिणाम किस आधार पर भिन्न हो सकता है, जिसके आधार पर क्वेरी को सर्वर द्वारा सेवा दी जा रही है।

— kasperd

Chrome, एक वेब क्लाइंट होने के नाते आपको पुनर्निर्देशित कर सकता है। क्या http हेडर ... कर्ल-आई <वेब पेज आप को प्राप्त करने के बारे में कुछ भी बताने की कोशिश कर रहे हैं?

— 10

दोनों का उपयोग करने की बात क्या है +traceऔर @1.1.1.1? क्या आप वाकई समझ रहे हैं कि ये विकल्प एक साथ कैसे काम करते हैं?

— बारमर

हां, मैं निश्चित हूं कि मैं समझता हूं कि ये कैसे एक साथ काम करते हैं। @ <पता> का उपयोग करने का बिंदु उन डीएनएस सर्वर को निर्दिष्ट करना होगा जो उनके ग्राहक दो स्थानों पर उपयोग कर रहे हैं। दिए गए उदाहरण में, इसका क्लाउडफ़ेयर है, लेकिन यदि कोई अन्य क्लाइंट किसी भिन्न dns सर्वर का उपयोग करता है, तो इसे वहाँ निर्दिष्ट किया जाएगा। उदाहरण के लिए, मैं कहां हूं, resolv.conf में सर्वर का पता एक कंपनी है, लेकिन मैं अभी भी 1.1.1.1 से हल कर सकता हूं

— सरच

नेटवर्क लोगों ने 1.1.1.1 उम्र के लिए स्विच / रूटर्स एपी के यादृच्छिक इंटरफेस में एक अन्य निजी पते के प्रतिस्थापन के रूप में उपयोग किया है। (मैं इस समय खुद एक ऐसे स्थान पर हूँ जहाँ जनता सैकड़ों वायरलेस APs के आईपी एड्रेस का सामना कर रही है 1.1.1.1)

मैं शर्त लगाता हूं कि आप उन मशीनों में पैसे कमा सकते हैं, जो आप Cloufare के 1.1.1.1 से बात नहीं कर सकते हैं कि आपके पास इस तरह के इंटरफेस के लिए एक (पीछे) मार्ग है।

उदाहरण के लिए, मेरे मामले में, 1.1.1.1 मुझे अपना आईपी पता दे रहा है:

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

— रुई एफ रिबेरो
स्रोत

यही कारण है कि RFC 3849 और RFC 5737 को सख्ती से लागू किया जाना है।

— कास्परड

"बहुत कम" कुछ भी निर्धारित करने के लिए एक मुश्किल आधार है, हालांकि। Cloudflare में बहुत सारे PoP हैं। 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msअसली बात मेरे RTT है।

— हाकन लिंडक्विस्ट

@ HåkanLindqvist आपका मूल्य है एक बाहरी कनेक्शन के लिए एक बहुत कम देरी लग रहे .... लेकिन हाँ, एक विश्वसनीय मीट्रिक नहीं।

— रुई एफ रिबेरो

@RuiFRibeiro विलंबता समान-शहर कनेक्टिविटी के लिए सही है, जिसमें कोई उच्च-विलंबता लिंक शामिल नहीं है। (ट्रेसरूटे मेरे आईएसपी के भीतर 4 पते दिखाता है, मेरे शहर में एक इंटरनेट एक्सचेंज में क्लाउडफ्लेयर पता, फिर 1.1.1.1।)

— हाकन लिंडक्विस्ट

ऐसा लगता है कि मैं Cloudflare DNS तक पहुंच सकता हूं, केवल यह मेरे लिए डोमेन के लिए विफल रहता है। मैं के लिए nslookup दौड़े हैं auth.otc.t-systems.comऔर serverfault.com। यहाँ tcpdump से परिणाम है: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— थॉमस ओबमुलेर