DNS दुनिया भर में प्रचार करने में विफल है

Question

मैंने serverfault.com के लिए DNS प्रविष्टि से संबंधित कुछ भी नहीं बदला है , लेकिन कुछ उपयोगकर्ता आज रिपोर्ट कर रहे थे कि serverfault.com DNS उनके लिए हल करने में विफल है ।

मैंने एक उचित क्वेरी चलाई और मैं इस बात की पुष्टि कर सकता हूं - serverfault.com dns देश के मुट्ठी भर में हल करने में विफल हो रहा है, बिना किसी विशेष कारण के कि मैं विचार कर सकता हूं। ( व्हाट्सएप माई डीएनएस के माध्यम से भी पुष्टि की गई है जो दुनिया भर में कुछ इसी तरह से पिंग करता है, इसलिए इसे दो अलग-अलग स्रोतों द्वारा एक मुद्दे के रूप में पुष्टि की गई है।)

• यह क्यों हो रहा है, अगर मैंने DNS को serverfault.com से नहीं छुआ है?

• हमारा रजिस्ट्रार (जीएजी) GoDaddy है, और मैं बिना किसी घटना के अधिकांश भाग के लिए डिफ़ॉल्ट DNS सेटिंग्स का उपयोग करता हूं। क्या मुझसे कुछ ग़लत हो रहा है? क्या डीएनएस के देवता मुझे त्याग चुके हैं?

• इसे ठीक करने के लिए क्या ऐसा कुछ है, जो मेरे लिए करना संभव है? DNS के साथ हंसने का कोई तरीका या DNS को दुनिया भर में सही तरीके से प्रचारित करने के लिए मजबूर करना?

अपडेट: सोमवार को 3:30 बजे पीएसटी के रूप में, सब कुछ सही लगता है .. जस्टपिंग रिपोर्ट साइट सभी स्थानों से उपलब्ध है। बहुत बहुत जानकारीपूर्ण प्रतिक्रियाओं के लिए धन्यवाद, मैंने बहुत कुछ सीखा और अगली बार ऐसा होने पर इस क्यू का उल्लेख करूंगा।

Comments

जेफ, अपने दिमाग को आराम से रखने के लिए - यह निश्चित रूप से आप नहीं हैं। यह GoDaddy हो सकता है, लेकिन यह ग्लोबल क्रॉसिंग की अधिक संभावना है, विशेष रूप से 204.245.39.50 पर राउटर

— Alnitak

Answer 1

यह सीधे DNS समस्या नहीं है, यह इंटरनेट के कुछ हिस्सों और serverfault.com के लिए DNS सर्वरों के बीच नेटवर्क रूटिंग समस्या है। चूंकि नेमसर्वर तक नहीं पहुंचा जा सकता है इसलिए डोमेन हल करना बंद कर देता है।

जहाँ तक मैं बता सकता हूँ कि रूटिंग समस्या IP पते के साथ (Global Crossing?) राउटर पर है 204.245.39.50।

जैसा कि @radius द्वारा दिखाया गया है , पैकेट ns52 (जैसा कि stackoverflow.com द्वारा उपयोग किया जाता है ) यहाँ से 208.109.115.121और वहाँ से सही तरीके से काम करते हैं। हालाँकि, पैकेट्स को ns22 के बजाय जाना है 208.109.115.201।

के बाद से उन दोनों पतों दोनों एक ही कर रहे हैं /24और इसी BGP घोषणा एक के लिए भी है /24इस ऐसा नहीं होना चाहिए ।

मैंने अपने नेटवर्क के माध्यम से ट्रेसरआउट्स किया है जो अंततः GoDaddy पर जाने के लिए ग्लोबल क्रॉसिंग के बजाय MFN Above.net का उपयोग करता है और /24स्तर से नीचे किसी भी मार्ग चालन का कोई संकेत नहीं है - दोनों नाम सर्वरों के यहां से समान ट्रेसरआउट हैं।

केवल समय मैंने कभी इस तरह से देखा है कि यह सिस्को एक्सप्रेस फ़ॉरवर्डिंग (सीईएफ) टूट गया था । यह पैकेट लेवल को तेज करने के लिए इस्तेमाल किया जाने वाला एक हार्डवेयर लेवल कैश है। दुर्भाग्य से बस कभी-कभी यह वास्तविक रूटिंग टेबल के साथ सिंक से बाहर हो जाता है, और गलत इंटरफ़ेस के माध्यम से पैकेट को आगे बढ़ाने की कोशिश करता है। CEF प्रविष्टियाँ /32स्तर तक जा सकती हैं, भले ही अंतर्निहित रूटिंग टेबल प्रविष्टि a के लिए हो /24। यह समस्याओं के इन प्रकारों को खोजने के लिए मुश्किल है, लेकिन एक बार पहचानने के बाद उन्हें ठीक करना आसान होता है।

मैंने GC को ई-मेल किया है और उनसे बात करने की भी कोशिश की है, लेकिन वे गैर-ग्राहकों के लिए टिकट नहीं बनाएंगे। आप में से किसी तो हैं जीसी के एक ग्राहक, कोशिश करते हैं और इसकी रिपोर्ट करें ...

10:38 UTC पर UPDATE जेफ़ ने नोट किया कि समस्या अब साफ़ हो गई है। ऊपर उल्लिखित दोनों सर्वरों के लिए ट्रेसरआउट अब 208.109.115.121अगले हॉप के माध्यम से जाते हैं ।

Comments

काश मैं तुम्हें और बढ़ा सकता। मैं आउटसोर्सिंग के लोगों की दुनिया में भयभीत हूँ, देवदासी के स्तर -1 हेल्डेस्क से संपर्क कर सकता हूं, जो समस्या के बहुत से विवरण और संभावित समस्या के स्पष्टीकरण से भी कम नहीं समझेगा ...

— pQd

Answer 2

serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com के लिए आपके डीएनएस सर्वर। ] अगम्य हैं। पिछले ~ 20h के लिए, कम से कम जोड़ी प्रमुख आईएसपी से स्वीडन में [ Telia , Tele2 , bredband2 ]।

एक ही समय में 'पड़ोसी' stackoverflow.com और superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] के लिए सर्वरों को पुनः प्राप्त कर रहे हैं।

ns52.domaincontrol.com पर नमूना अनुरेखक:

 1. xxxxxxxxxxx
 2. 83.233.28.193           
 3. 83.233.79.81            
 4. 213.200.72.5            
 5. 64.208.110.129          
 6. 204.245.39.50           
 7. 208.109.115.121         
 8. 208.109.115.162         
 9. 208.109.113.62          
10. 208.109.255.26          

और ns21.domaincontrol.com पर

 1. xxxxxxxxxxxx
 2. 83.233.28.193      
 3. 83.233.79.81       
 4. 213.200.72.5       
 5. 64.208.110.129     
 6. 204.245.39.50      
 7. 208.109.115.201    
 8. ???

शायद छानने से खराब हो गया / किसी ने कुछ अवांछित ddos ​​संरक्षण चालू कर दिया और इंटरनेट के कुछ हिस्सों को ब्लैकलिस्ट कर दिया। शायद आपको अपने डीएनएस सेवा प्रदाता से संपर्क करना चाहिए - डैडी।

समस्या के हल होने पर आप सत्यापित कर सकते हैं:

1. जाँच की जाती है कि क्या गोडैडी ने प्रतिक्रिया दी है और नाम सर्वर बदल दिए हैं - उदाहरण के लिए http://www.squish.net/dnscheck/ पर जाकर serverfault.com का पुनः प्रयोग करें: कोई भी
2. जाँच करें यदि प्रदान किया गया नाम सर्वर पिंग का जवाब देते हैं [नहीं तो बहुत ही वैज्ञानिक नाम सर्वर ठीक काम कर सकते हैं और अभी भी icmp को ब्लॉक कर सकते हैं, लेकिन इस मामले में ऐसा लगता है कि icmp को अन्य सर्वरों से] telia से देख ग्लास के माध्यम से अनुमति है ।

संपादित करें : कार्य स्थानों से ट्रेसरआउट

पोलैंड

 1. xxxxxxxxxxxxxxx
 2. 153.19.40.254               
 3. ???
 4. 153.19.254.236              
 5. 212.191.224.205             
 6. 213.248.83.129              
 7. 80.91.254.171               
 8. 80.91.249.105               
    80.91.251.230
    80.91.254.93
    80.91.251.52
 9. 213.248.89.182              
10. 204.245.39.50               
11. 208.109.115.121             
12. 208.109.115.162             
13. 208.109.113.62              
14. 208.109.255.26              

जर्मनी

 1. xxxxxxxxxxxx
 2. 89.149.218.181       
 3. 89.149.218.2         
 4. 134.222.105.249      
 5. 134.222.231.205      
 6. 134.222.227.146      
 7. 80.81.194.26         
 8. 64.125.24.6          
 9. 64.125.31.249        
10. 64.125.27.165        
11. 64.125.26.178        
12. 64.125.26.242        
13. 209.249.175.170      
14. 208.109.113.58       
15. 208.109.255.26       

संपादित करें : सभी अब वास्तव में ठीक काम करता है।

Comments

हां, यह निश्चित रूप से एक बाहरी समस्या है, जाहिरा तौर पर यूरोप के लिए स्थानीयकृत।

— अलनीतक

यह यूरोप के सभी प्रतीत नहीं होता है। Eircom ब्रॉडबैंड लाइनों (उदाहरण के लिए) serverfault.com ठीक हल।

— सियान

@Alnitak: यह पूरे यूरोप को प्रभावित नहीं कर रहा है - यह सुनिश्चित है। मैं स्वेच्छा में bredbandsbolaget से उन naem सर्वर तक पहुंच सकता हूं, पोलैंड और जर्मनी में कई isps।

— pQd

हालांकि Eircom ने पिछले दो हफ्तों में अपने ग्राहकों के लिए कुछ गंभीर मुसीबतें झेलीं

— अर्जन

पिछली बार मैंने एक समस्या देखी थी कि यह एक सिस्को राउटर पर सीईएफ टेबल भ्रष्टाचार था। कुछ होस्ट उपलब्ध थे और अन्य नहीं थे, भले ही वे एक ही / 24 सबनेट में थे। यह केवल कुछ आईएसपी से प्रभावित है, केवल यह बताता है कि उन आईएसपी में कुछ सामान्य आपूर्तिकर्ता हैं। एक कार्य कनेक्शन से यह पता लगाना आसान नहीं है कि क्यों।

— अलनीतक

Answer 3

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

serverfault.com के पास आज बहुत खराब DNS सेटअप है, निश्चित रूप से इस तरह की महत्वपूर्ण साइट के लिए अपर्याप्त है:

• केवल दो नाम सर्वर
• सभी अंडे एक ही टोकरी में (दोनों एक ही AS में हैं)

हमने केवल परिणाम देखा है: एक राउटिंग गड़बड़ (कुछ जो इंटरनेट पर काफी सामान्य है) सर्वरफॉल्ट.कॉम बनाने के लिए पर्याप्त है कुछ उपयोगकर्ताओं के लिए गायब हो जाता है (उनके ऑपरेटरों के आधार पर, उनके देशों पर नहीं)।

मैं अन्य नाम सर्वर को जोड़ने का सुझाव देता हूं, जो अन्य एएस में स्थित हैं। यह विफलता लचीलापन की अनुमति देगा। आप या तो उन्हें निजी कंपनियों को किराए पर दे सकते हैं या सर्वरफॉल्ट उपयोगकर्ताओं को द्वितीयक DNS होस्टिंग प्रदान करने के लिए कह सकते हैं (केवल तभी हो सकता है जब उपयोगकर्ता के पास 1000 डीएसओ <br है)

Comments

ज़ोनडिट डॉट कॉम मुफ्त डीएनएस होस्टिंग प्रदान करता है, मैं इसे वर्षों से उपयोग करता हूं और इसके साथ कभी कोई समस्या नहीं आती है।

— त्रिज्या

Answer 4

मैं पुष्टि करता हूं कि NS21.DOMAINCONTROL.COM और NS22.DOMAINCONTROL.COM भी फ्रांस में ISP Free.fr से अप्राप्य हैं।
PQd ट्रेसरआउट की तरह, मेरा भी ns21 और ns22 दोनों के लिए 208.109.115.201 के बाद समाप्त हो गया।

traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  2.526 ms  0.799 ms  0.798 ms
 2  78.224.126.254 (78.224.126.254)  6.313 ms  6.063 ms  6.589 ms
 3  213.228.5.254 (213.228.5.254)  6.099 ms  6.776 ms *
 4  212.27.50.170 (212.27.50.170)  6.943 ms  6.866 ms  6.842 ms
 5  212.27.50.190 (212.27.50.190)  8.308 ms  6.641 ms  6.866 ms
 6  212.27.38.226 (212.27.38.226)  68.660 ms  185.527 ms  14.123 ms
 7  204.245.39.50 (204.245.39.50)  48.544 ms  19.391 ms  19.753 ms
 8  208.109.115.201 (208.109.115.201)  19.315 ms  19.668 ms  34.110 ms
 9  * * *
10  * * *
11  * * *
12  * * *

लेकिन ns52.domaincontrol.com (208.109.255.26) काम करता है और ns22.domaincontrol.com (208.109.255.11) के समान सबनेट में है

traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  1.229 ms  0.816 ms  0.808 ms
 2  78.224.126.254 (78.224.126.254)  12.127 ms  5.623 ms  6.068 ms
 3  * * *
 4  212.27.50.170 (212.27.50.170)  13.824 ms  6.683 ms  6.828 ms
 5  212.27.50.190 (212.27.50.190)  6.962 ms *  7.085 ms
 6  212.27.38.226 (212.27.38.226)  35.379 ms  7.105 ms  7.830 ms
 7  204.245.39.50 (204.245.39.50)  19.896 ms  19.426 ms  19.355 ms
 8  208.109.115.121 (208.109.115.121)  37.931 ms  19.665 ms  19.814 ms
 9  208.109.115.162 (208.109.115.162)  19.663 ms  19.395 ms  29.670 ms
10  208.109.113.62 (208.109.113.62)  19.398 ms  19.220 ms  19.158 ms
11  * * *
12  * * *
13  * * *

जैसा कि आप देख सकते हैं, इस बार 204.245.39.50 के बाद हम 208.109.115.2018 के बजाय 208.109.115.121 पर जाते हैं। और pQd में एक ही अनुरेखक है। एक कामकाजी जगह से मैंने इस 204.245.39.50 राउटर (ग्लोबल क्रॉसिंग) को पार नहीं किया।

काम करने और गैर कामकाजी जगह से अधिक अनुरेखक मदद करेगा, लेकिन यह अत्यधिक संभावना है कि ग्लोबल क्रॉसिंग में 208.109.255.11/32 और 216.69.185.11/32 के लिए 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69 के रूप में फर्जी रूटिंग प्रविष्टि है। 185.12 अच्छा काम कर रहे हैं।

क्यों यह एक दलदल मार्ग प्रविष्टि है पता करने के लिए मुश्किल है। संभवतः 208.109.115.201 (गो डैडी) 208.109.255.11/32 और 216.69.185.11/32 के लिए एक गैर-कार्यशील मार्ग का विज्ञापन कर रहा है।

EDIT: ग्लोबल क्रॉसिंग रूट सर्वर से कनेक्ट करने और ग्लोबल क्रॉसिंग नेटवर्क के भीतर से ट्रेसरआउट करने के लिए आप रूट-server.eu.gblx.net को रूट कर सकते हैं।

संपादित करें: ऐसा लगता है कि एक ही समस्या पहले से ही दूसरों के साथ एनएस कुछ दिनों पहले हुई, देखें: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Comments

मुझे संदेह है कि आप विज्ञापन कर सकते हैं [bgp के माध्यम से] कुछ भी छोटा / 24 या 23 /। मैं बजाय फ़िल्टर गड़बड़ मार्ग पर शर्त लगा सकता हूँ।

— पीक्यूडी

ठीक है, लेकिन 204.245.39.50 गो डैडी और ग्लोबल क्रॉसिंग के बीच एक समर्पित राउटर हो सकता है। यह गो डैडी से किसी भी मार्ग को स्वीकार कर सकता है, लेकिन ग्लोबल क्रॉसिंग के अंदर अपस्ट्रीम राउटर केवल रूट / 24 होगा (बीजीपी टेबल 208.109.255.0 पर / 24 के रूप में विज्ञापित है)। गो डैडी सभी होस्ट को / 32 और ग्लोबल क्रॉसिंग राउटर के रूप में विज्ञापन दे सकते हैं / उन्हें बीजीपी पुनर्वितरण के लिए 24 के रूप में

— त्रिज्या

(लेकिन मैं सहमत हूं कि यह थोड़ा बदसूरत होगा)

— त्रिज्या

मैं CEF टेबल भ्रष्टाचार पर शर्त लगा सकता हूँ ...

— Alnitak

Answer 5

जो काम करना आसान होगा, वह उन स्थानों से एक विस्तृत रिज़ॉल्यूशन ट्रेस देखना होगा जो विफल हो रहे हैं ... यह देखें कि रिज़ॉल्यूशन पथ की कौन सी परत विफल हो रही है। मैं आपके द्वारा उपयोग की जा रही सेवा से परिचित नहीं हूं, लेकिन शायद यह कहीं न कहीं एक विकल्प है।

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

Answer 6

मुझे आश्चर्य है कि आप अपने DNS को होस्ट नहीं करते हैं। इस तरह से करने का लाभ यह है कि यदि DNS उपलब्ध है, तो यह (उम्मीद है) आपकी साइट है।

Comments

अच्छा .. सभी अंडों को एक टोकरी में न रखना अच्छा है। शायद इसके लिए और भी बहुत कुछ है तो बस वेब होस्टिंग - शायद मेल सेवाएं? रिज़ॉल्यूशन के दृष्टिकोण से डीएनएस काफी अच्छा है। शायद सबसे अच्छा प्रदाता # 1 पर प्राथमिक डीएनएस और दूसरे प्रदाता (एस) में 2 डी डीएन सर्वर (एस) डालना है। जब तक उनमें से कोई भी पहुंच योग्य नहीं होगा - अंत उपयोगकर्ता को हल करने में सक्षम होगा।

— pQd

मैं स्वयं होस्ट करता हूं, लेकिन ISP के DNS सर्वरों को प्राइमरी के रूप में सूचीबद्ध करता है, भले ही वे वास्तव में दूसरी हैं। हां, यह बहुत ही शरारती है, और मैं पूरी तरह से शिकायत की बातें सुनने की उम्मीद करता हूं ... लेकिन इसका उल्टा असर है, हमें क्वैश्चन डीएनएस सर्वर के अतिरेक के साथ सेल्फ होस्टेड डीएनएस का पूरा नियंत्रण मिलता है। रिकॉर्ड के लिए टीटीएल काफी अधिक है कि अगर हम यह पता नहीं लगा सकते हैं कि 3 दिनों में किसी समस्या को कैसे ठीक किया जाए, तो बस एक टूटी हुई DNS सेटअप की तुलना में बड़े मुद्दे हैं। ओह, और @Paul, +1 को "हम सब कुछ आउटसोर्स कर सकते हैं क्योंकि हम कर सकते हैं" के समय में मूल विकल्प के रूप में स्व-होस्टिंग को इंगित करने के लिए।

— एवरी पायने

Answer 7

UPC से कम से कम, मुझे यह प्रतिक्रिया तब मिलती है जब आपके आधिकारिक सर्वर (ns21.domaincontrolrol) से आपका ए रिकॉर्ड प्राप्त करने का प्रयास किया जाता है।

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.       IN  A

;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE  rcvd: 33

जब मैं एक अलग नेटवर्क (ओवीएच) पर मशीन से एक ही चीज की कोशिश करता हूं, तो मुझे एक जवाब मिलता है

; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        3600    IN      NS      ns22.domaincontrol.com.

;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE  rcvd: 101

मुझे कुछ अन्य डोमेन के लिए समान व्यवहार मिलता है, इसलिए मुझे लगता है कि UPC (कम से कम) चुपचाप DNS प्रश्नों को अपने स्वयं के कैशिंग नेमवेयर पर पुनर्निर्देशित कर रहा है, और उत्तरों को खराब कर रहा है। यदि आपके DNS ने संक्षिप्त रूप से दुर्व्यवहार किया था, तो यह इसे समझा सकता है क्योंकि UPC के नेमवेर्स NXDOMI प्रतिक्रिया का कैशिंग कर सकते हैं।