DNS ไม่สามารถเผยแพร่ทั่วโลก

ฉันไม่ได้เปลี่ยนแปลงอะไรที่เกี่ยวข้องกับรายการ DNS สำหรับ serverfault.comแต่ผู้ใช้บางคนรายงานในวันนี้ว่าserverfault.com DNS ไม่สามารถแก้ไขได้

ฉันใช้คำสั่ง justpingและฉันสามารถยืนยันสิ่งนี้ได้ - serverfault.com DNS ดูเหมือนจะล้มเหลวในการแก้ปัญหาในหลายประเทศโดยไม่มีเหตุผลใดที่ฉันสามารถแยกแยะได้ (ได้รับการยืนยันผ่านWhat's My DNSซึ่งทำการ Ping ทั่วโลกในลักษณะเดียวกันดังนั้นจึงได้รับการยืนยันว่าเป็นปัญหาจากสองแหล่งที่แตกต่างกัน)

• ทำไมสิ่งนี้ถึงเกิดขึ้นถ้าฉันไม่ได้แตะ DNS สำหรับ serverfault.com

• ผู้รับจดทะเบียนของเราคือ (ปิดปาก) GoDaddy และฉันใช้การตั้งค่า DNS เริ่มต้นเป็นส่วนใหญ่โดยไม่เกิดปัญหา ฉันกำลังทำอะไรผิดหรือเปล่า? มีเทพเจ้าแห่ง DNS ที่ทิ้งฉันไปไหม

• มีอะไรที่ฉันสามารถทำได้เพื่อแก้ไขปัญหานี้หรือไม่? มีวิธีใดที่จะใช้ DNS หรือบังคับให้ DNS ทำการเผยแพร่ทั่วโลกอย่างถูกต้อง?

อัปเดต: ณ วันจันทร์เวลา 3:30 น. PST ทุกอย่างดูถูกต้อง .. เว็บไซต์ JustPing สามารถเข้าถึงได้จากทุกที่ ขอบคุณสำหรับคำตอบที่ให้ข้อมูลมากมายฉันเรียนรู้มากและจะอ้างถึงคำถามนี้ในครั้งต่อไปที่สิ่งนี้เกิดขึ้น ..

นี่ไม่ใช่ปัญหา DNS โดยตรง แต่เป็นปัญหาการกำหนดเส้นทางเครือข่ายระหว่างบางส่วนของอินเทอร์เน็ตและเซิร์ฟเวอร์ DNS สำหรับ serverfault.com เนื่องจากเนมเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้โดเมนหยุดแก้ไข

เท่าที่ผมสามารถบอกปัญหาเส้นทางอยู่บนเราเตอร์ (ข้ามโลก?) 204.245.39.50มีที่อยู่

ในฐานะที่เป็นแสดงให้เห็นโดย@radiusแพ็คเก็ตที่จะ ns52 (ที่ใช้โดยstackoverflow.com ) ผ่านจากที่นี่ไป208.109.115.121และจากที่นั่นทำงานอย่างถูกต้อง อย่างไรก็ตามแพ็กเก็ต NS22 208.109.115.201ไปแทน

เนื่องจากทั้งสองอยู่มีทั้งในแบบเดียวกัน/24และประกาศ BGP สอดคล้องกันนอกจากนี้ยังมีสำหรับ/24นี้ไม่ควรเกิดขึ้น

ฉันทำ traceroutes ผ่านเครือข่ายของฉันซึ่งท้ายที่สุดก็ใช้ MFN Above.net แทน Global Crossing เพื่อไปที่ GoDaddy และไม่มีวี่แววของเล่ห์เหลี่ยมการกำหนดเส้นทางต่ำกว่า/24ระดับ - เซิร์ฟเวอร์ชื่อทั้งคู่มี traceroutes เหมือนกันจากที่นี่

ครั้งเดียวที่ฉันเคยเห็นบางสิ่งเช่นนี้มันเสียCisco Express Forwarding (CEF) นี่คือแคชระดับฮาร์ดแวร์ที่ใช้เพื่อเร่งการกำหนดเส้นทางแพ็คเก็ต น่าเสียดายที่บางครั้งมันไม่ได้ซิงค์กับตารางเส้นทางจริงและพยายามส่งต่อแพ็คเก็ตผ่านอินเตอร์เฟซที่ผิด รายการตระเว ณ สามารถไปลงไปที่ระดับแม้ว่ารายการตารางเส้นทางอ้างอิงคือหา/32 /24เป็นการยากที่จะค้นหาปัญหาประเภทนี้ แต่เมื่อพบว่าปกติแล้วมันจะง่ายต่อการแก้ไข

ฉันส่งอีเมลถึง GC แล้วและพยายามพูดกับพวกเขา แต่พวกเขาจะไม่สร้างตั๋วสำหรับลูกค้าที่ไม่ใช่ ถ้าใด ๆ ของคุณเป็นลูกค้าของ GC โปรดลองและรายงานนี้ ...

ปรับปรุงที่ 10:38 UTC ในขณะที่เจฟฟ์ได้สังเกตเห็นว่าปัญหาได้ถูกลบไปแล้ว Traceroutes ไปยังเซิร์ฟเวอร์ทั้งสองที่กล่าวถึงข้างต้นตอนนี้ไปผ่าน208.109.115.121hop ต่อไป

เซิร์ฟเวอร์ dns ของคุณสำหรับ serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com ] ไม่สามารถเข้าถึงได้ สำหรับ ~ 20 ชม. อย่างน้อยจาก isps สำคัญสองสามคู่ในสวีเดน [ telia , tele2 , bredband2 ]

ในเวลาเดียวกันเซิร์ฟเวอร์ 'เพื่อนบ้าน' dns สำหรับ stackoverflow.com & superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] สามารถเข้าถึงได้

ตัวอย่าง traceroute ไปยัง 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 ​​ที่ไม่ต้องการและขึ้นบัญชีดำบางส่วนของอินเทอร์เน็ต บางทีคุณควรติดต่อผู้ให้บริการ DNS ของคุณ - ไปพ่อ

คุณสามารถตรวจสอบว่าปัญหาได้รับการแก้ไขโดย:

1. ตรวจสอบว่า godaddy ตอบสนองและเปลี่ยนเซิร์ฟเวอร์ชื่อ - เช่น lookup serverfault.com ที่http://www.squish.net/dnscheck/โดยใช้ประเภท recort: ANY
2. ตรวจสอบว่าชื่อเซิร์ฟเวอร์ที่ให้บริการตอบสนองต่อการ ping [ไม่ได้ทางวิทยาศาสตร์มากตั้งแต่ชื่อเซิร์ฟเวอร์สามารถทำงานได้ดีและยังคงปิดกั้น ICMP แต่ในกรณีนี้มันดูเหมือนว่า ICMP ที่ได้รับอนุญาตไปยังเซิร์ฟเวอร์อื่น] จาก Telia ผ่านกระจกมอง

แก้ไข : traceroutes จากสถานที่ทำงาน

โปแลนด์

 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       

แก้ไข : ทั้งหมดทำงานได้ดีในขณะนี้แน่นอน

คำแนะนำของฉัน: ตามที่อธิบายโดย Alnitak ปัญหาไม่ใช่ DNS แต่เป็นเส้นทาง (อาจเป็น BGP) ความจริงที่ว่าไม่มีการเปลี่ยนแปลงใด ๆ ในการตั้งค่า DNS เป็นเรื่องปกติเนื่องจากปัญหาไม่ได้อยู่ใน DNS

วันนี้ serverfault.com มีการตั้งค่า DNS ที่แย่มากซึ่งไม่เพียงพอสำหรับไซต์ที่สำคัญเช่นนี้:

• เซิร์ฟเวอร์ชื่อสองตัวเท่านั้น
• ไข่ทั้งหมดในตะกร้าเดียวกัน (ทั้งสองอยู่ใน AS เดียวกัน)

เราเพิ่งเห็นผลลัพธ์: ความผิดพลาดในการกำหนดเส้นทาง (สิ่งที่ค่อนข้างพบได้ทั่วไปบนอินเทอร์เน็ต) ก็เพียงพอที่จะทำให้ serverfault.com หายไปสำหรับผู้ใช้บางคน (ขึ้นอยู่กับผู้ให้บริการของพวกเขาไม่ใช่ในประเทศของพวกเขา)

ฉันแนะนำให้เพิ่มเนมเซิร์ฟเวอร์เพิ่มเติมซึ่งอยู่ใน AS อื่น สิ่งนี้จะช่วยให้เกิดความยืดหยุ่นในการทำงานล้มเหลว คุณสามารถให้เช่ากับ บริษัท เอกชนหรือขอให้ผู้ใช้ serverfault เสนอบริการโฮสต์ DNS รอง (อาจใช้ได้เฉพาะเมื่อผู้ใช้มี> 1000 ตัวแทน :-)

ฉันยืนยันว่า NS21.DOMAINCONTROL.COM และ NS22.DOMAINCONTROL.COM นั้นไม่สามารถเข้าถึงได้จาก ISP Free.fr ในฝรั่งเศส
เช่นเดียวกับ pQd traceroute, ฉันก็สิ้นสุดหลังจาก 208.109.115.201 สำหรับทั้ง ns21 และ ns22

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.121 แทน 208.109.115.201 และ pQd มี traceroute เหมือนกัน จากที่ทำงานฉันไม่ได้ข้ามเราเตอร์ 204.245.39.50 (Global Crossing)

การติดตามเพิ่มเติมจากที่ทำงานและที่ทำงานไม่ได้ช่วยได้ แต่มีความเป็นไปได้สูงที่ Global Crossing จะมีรายการการกำหนดเส้นทางปลอมสำหรับ 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 (Go Daddy) กำลังโฆษณาเส้นทางที่ไม่ทำงานสำหรับ 208.109.255.11/32 และ 216.69.185.11/32

แก้ไข: คุณสามารถ telnet route-server.eu.gblx.net เพื่อเชื่อมต่อกับเซิร์ฟเวอร์เส้นทาง Global Crossing และติดตามเส้นทางจากภายในเครือข่าย Global Crossing

แก้ไข: ดูเหมือนว่าปัญหาเดียวกันได้เกิดขึ้นกับคนอื่น ๆ NS ไม่กี่วันที่ผ่านมาดู: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

สิ่งที่จะมีประโยชน์ก็คือการดูรายละเอียดการติดตามความละเอียดจากตำแหน่งที่ล้มเหลว ... ดูเลเยอร์ของเส้นทางการแก้ปัญหาที่ล้มเหลว ฉันไม่คุ้นเคยกับบริการที่คุณใช้ แต่อาจเป็นตัวเลือก

ความล้มเหลวนั้นอาจเป็นไปได้ว่าปัญหาคือ "ลดลง" ในทรีเนื่องจากความล้มเหลวที่รูทหรือ TLD จะส่งผลกระทบต่อโดเมนมากขึ้น (คุณหวังว่า) ในการเพิ่มความยืดหยุ่นคุณสามารถมอบสิทธิ์ให้กับบริการ DNS ตัวที่สองเพื่อให้มั่นใจในการแก้ไขปัญหาที่ซ้ำซ้อนได้ดีขึ้นหากมีปัญหากับเครือข่ายของตัวควบคุมโดเมน

ฉันประหลาดใจที่คุณไม่ได้โฮสต์ DNS ของคุณเอง ข้อได้เปรียบของการทำเช่นนั้นคือถ้า DNS เข้าถึงได้ดังนั้น (หวังว่า) ไซต์ของคุณ

อย่างน้อยจาก UPC ฉันได้รับปฏิกิริยานี้เมื่อพยายามรับ A ระเบียนของคุณจากเซิร์ฟเวอร์ที่มีสิทธิ์ของคุณ (ns21.domaincontrol.com)

; <<>> 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

เมื่อฉันลองสิ่งเดียวกันจากเครื่องในเครือข่ายอื่น (OVH) ฉันจะได้รับคำตอบ

; <<>> 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 อาจแคชการตอบสนองของ NXDOMAIN