DNS không lan truyền trên toàn thế giới

Tôi đã không thay đổi bất cứ điều gì liên quan đến mục nhập DNS cho serverfault.com , nhưng một số người dùng đã báo cáo rằng DNS serverfault.com không thể giải quyết cho họ .

Tôi đã chạy một truy vấn chỉ và tôi có thể xác nhận điều này - serverfault.com dns dường như không giải quyết được ở một số quốc gia, không có lý do cụ thể nào mà tôi có thể nhận ra. (cũng được xác nhận qua What My DNS , một số ping trên toàn thế giới theo cách tương tự, do đó, nó được xác nhận là một vấn đề của hai nguồn khác nhau.)

• Tại sao điều này sẽ xảy ra, nếu tôi chưa chạm vào DNS cho serverfault.com?

• công ty đăng ký của chúng tôi là (gag) GoDaddy và tôi sử dụng cài đặt DNS mặc định cho hầu hết các phần mà không có sự cố. Tôi có làm điều gì sai? Các vị thần của DNS đã bỏ rơi tôi?

• tôi có thể làm gì để khắc phục điều này không? Có cách nào để thu hút DNS cùng hoặc buộc DNS truyền bá chính xác trên toàn thế giới không?

Cập nhật: kể từ thứ Hai lúc 3:30 sáng PST, mọi thứ đều có vẻ chính xác .. Trang web báo cáo JustPing có thể truy cập từ tất cả các địa điểm. Cảm ơn bạn đã phản hồi rất nhiều thông tin, tôi đã học được rất nhiều và sẽ đề cập đến Q này vào lần tiếp theo điều này xảy ra ..

Đây không phải là sự cố DNS trực tiếp, đây là sự cố định tuyến mạng giữa một số phần của internet và máy chủ DNS cho serverfault.com. Vì máy chủ tên không thể truy cập, tên miền dừng giải quyết.

Theo như tôi có thể nói vấn đề định tuyến là trên bộ định tuyến (Global Crossing?) Có địa chỉ IP 204.245.39.50.

Như được hiển thị bởi @radius , các gói đến ns52 (được sử dụng bởi stackoverflow.com ) chuyển từ đây đến 208.109.115.121và từ đó hoạt động chính xác. Tuy nhiên các gói đến ns22 đi thay thế 208.109.115.201.

Kể từ khi hai địa chỉ đều trong cùng /24và thông báo BGP tương ứng cũng là một /24này không nên xảy ra .

Tôi đã thực hiện theo dõi thông qua mạng của mình, cuối cùng sử dụng MFN Inside.net thay vì Global Crossing để đến GoDaddy và không có dấu hiệu của bất kỳ thủ thuật định tuyến nào dưới /24cấp - cả hai máy chủ tên đều có dấu vết giống hệt nhau từ đây.

Lần duy nhất tôi từng thấy một cái gì đó như thế này, nó đã bị hỏng Cisco Express Forwarding (CEF). Đây là bộ đệm cấp phần cứng được sử dụng để tăng tốc định tuyến gói. Thật không may, đôi khi nó không đồng bộ với bảng định tuyến thực và cố gắng chuyển tiếp các gói thông qua giao diện sai. Các mục CEF có thể giảm xuống /32mức ngay cả khi mục nhập bảng định tuyến cơ bản dành cho a /24. Thật khó để tìm ra những loại vấn đề này, nhưng một khi đã xác định chúng thường dễ khắc phục.

Tôi đã gửi thư điện tử cho GC và cũng đã cố gắng nói chuyện với họ, nhưng họ sẽ không tạo vé cho những người không phải là khách hàng. Nếu bất kỳ ai trong số bạn là khách hàng của GC, vui lòng thử và báo cáo điều này ...

CẬP NHẬT lúc 10:38 UTC Như Jeff đã lưu ý vấn đề hiện đã được xóa. Traceroutes cho cả hai máy chủ được đề cập ở trên bây giờ đi qua 208.109.115.121bước nhảy tiếp theo.

máy chủ dns của bạn cho serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] không thể truy cập được. trong khoảng thời gian cuối cùng ~ 20h, ít nhất là từ các cặp đôi chính ở Thụy Điển [ telia , tele2 , bredband2 ].

đồng thời các máy chủ dns 'láng giềng' cho stackoverflow.com & superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] có thể truy cập được.

mẫu theo dõi đến 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          

và đến 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. ???

có thể làm hỏng bộ lọc / ai đó đã kích hoạt một số bảo vệ ddos ​​không mong muốn và đưa vào danh sách đen một số phần của internet. có lẽ bạn nên liên hệ với nhà cung cấp dịch vụ dns của bạn - đi cha.

bạn có thể xác minh nếu sự cố được [một phần] giải quyết bằng cách:

1. kiểm tra xem godaddy có phản ứng và thay đổi máy chủ tên hay không - ví dụ: tra cứu serverfault.com tại http://www.squish.net/dnscheck/ bằng cách sử dụng loại recort: ANY
2. kiểm tra xem máy chủ tên được cung cấp có phản hồi ping [không khoa học lắm không vì máy chủ tên có thể hoạt động tốt và vẫn chặn icmp, nhưng trong trường hợp này có vẻ như icmp được phép cho các máy chủ khác] từ telia qua kính nhìn .

chỉnh sửa : traceroutes từ nơi làm việc

Ba Lan

 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              

nước Đức

 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       

chỉnh sửa : tất cả các hoạt động tốt bây giờ thực sự.

Gợi ý của tôi: như Alnitak giải thích, vấn đề không phải là DNS mà là định tuyến (có thể là BGP). Thực tế là không có gì thay đổi trong thiết lập DNS là bình thường, vì vấn đề không nằm ở DNS của anh ta.

serverfault.com ngày nay có thiết lập DNS rất kém, chắc chắn không đủ cho một trang web quan trọng như thế này:

• chỉ có hai máy chủ tên
• tất cả trứng trong cùng một giỏ (cả hai đều trong cùng một AS)

Chúng ta vừa thấy kết quả: một trục trặc định tuyến (một điều khá phổ biến trên Internet) là đủ để làm cho serverfault.com biến mất đối với một số người dùng (tùy thuộc vào nhà khai thác của họ, không phải ở quốc gia của họ).

Tôi đề nghị thêm nhiều máy chủ tên, nằm trong AS khác. Điều này sẽ cho phép khả năng phục hồi thất bại. Bạn có thể thuê chúng cho các công ty tư nhân hoặc yêu cầu người dùng serverfault cung cấp dịch vụ lưu trữ DNS thứ cấp (có thể chỉ khi người dùng có> 1000 rep :-)

Tôi xác nhận rằng NS21.DOMAINCONTROL.COM và NS22.DOMAINCONTROL.COM cũng không thể truy cập được từ ISP Free.fr ở Pháp.
Giống như pQd traceroute, tôi cũng kết thúc sau 208.109.115.201 cho cả ns21 và 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  * * *

Nhưng ns52.domaincontrol.com (208.109.255.26) hoạt động và nằm trong cùng mạng con với 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  * * *

Như bạn có thể thấy, lần này sau 204.245.39.50 chúng ta chuyển đến 208.109.115.121 thay vì 208.109.115.201. Và pQd có cùng traceroute. Từ một nơi làm việc, tôi đã không vượt qua bộ định tuyến 204.245.39.50 này (Global Crossing).

Việc theo dõi nhiều hơn từ nơi làm việc và không làm việc sẽ giúp ích, nhưng rất có khả năng Global Crossing có một mục định tuyến không có thật cho 208.109.255.11 / 32 và 216,69.185.11 / 32 như 208.109.255.10, 208.109.255.12, 216,69.185.10, 216,69. 185,12 đang hoạt động tốt.

Tại sao nó có một mục định tuyến sa lầy là khó biết. Có lẽ là 208.109.115.201 (Go Daddy) đang quảng cáo một tuyến đường không hoạt động cho 208.109.255.11 / 32 và 216,69.185.11 / 32.

EDIT: Bạn có thể telnet route-server.eu.gblx.net để kết nối với máy chủ định tuyến Global Crossing và thực hiện theo dõi từ trong mạng Global Crossing

EDIT: Có vẻ như vấn đề tương tự đã xảy ra với những người khác NS vài ngày trước, xem: http://www.newtondoperics.com/forum/viewtopic.php?f=9&t=5277&start=0

Điều gì sẽ hữu ích là nhìn thấy dấu vết độ phân giải chi tiết từ các vị trí không thành công ... xem lớp nào của đường dẫn độ phân giải mà nó không hoạt động. Tôi không quen thuộc với dịch vụ bạn đang sử dụng, nhưng có lẽ đó là một lựa chọn ở đâu đó.

Không hiểu điều đó, rất có thể các vấn đề là "hạ thấp" trong cây, vì các lỗi ở gốc hoặc TLD sẽ ảnh hưởng đến nhiều miền hơn (bạn hy vọng). Để tăng khả năng phục hồi, bạn có thể ủy quyền cho dịch vụ DNS thứ hai để đảm bảo độ dự phòng tốt hơn trong độ phân giải nếu có vấn đề với (các) mạng của domaincontrol.

Tôi ngạc nhiên khi bạn không lưu trữ DNS của riêng bạn. Ưu điểm của việc làm theo cách đó là nếu DNS có thể truy cập được, thì (hy vọng là) trang web của bạn.

Ít nhất từ ​​UPC, tôi nhận được phản ứng này khi cố gắng lấy bản ghi A của bạn từ máy chủ có thẩm quyền của bạn (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

Khi tôi thử điều tương tự từ một máy trên một mạng khác (OVH), tôi nhận được câu trả lời

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

Tôi có hành vi tương tự đối với một vài tên miền khác, vì vậy tôi cho rằng UPC (ít nhất) đang âm thầm chuyển hướng các truy vấn DNS sang máy chủ tên bộ nhớ đệm của riêng chúng và giả mạo các câu trả lời. Nếu DNS của bạn đã được xử lý sai trong một thời gian ngắn, điều này có thể giải thích nó vì máy chủ tên của UPC có thể lưu vào bộ đệm phản hồi NXDOMAIN.