DNS gagal disebarkan ke seluruh dunia

Saya belum mengubah apa pun yang terkait dengan entri DNS untuk serverfault.com , tetapi beberapa pengguna melaporkan hari ini bahwa DNS serverfault.com gagal menyelesaikannya .

Saya menjalankan kueri justping dan saya dapat mengonfirmasi hal ini - serverfault.com dns tampaknya gagal diselesaikan di beberapa negara, tanpa alasan tertentu yang dapat saya pahami. (juga dikonfirmasikan melalui What's My DNS yang melakukan beberapa ping di seluruh dunia dengan cara yang serupa, sehingga dikonfirmasi sebagai masalah oleh dua sumber berbeda.)

• Mengapa ini terjadi, jika saya belum menyentuh DNS untuk serverfault.com?

• pendaftar kami adalah (gag) GoDaddy, dan saya menggunakan pengaturan DNS default untuk sebagian besar tanpa insiden. Apakah saya melakukan sesuatu yang salah? Sudahkah para dewa DNS meninggalkan saya?

• adakah yang bisa saya lakukan untuk memperbaikinya? Adakah cara untuk mengubah DNS, atau memaksa DNS untuk menyebar dengan benar di seluruh dunia?

Pembaruan: pada hari Senin jam 3:30 pagi PST, semuanya terlihat benar .. Situs laporan JustPing dapat dijangkau dari semua lokasi. Terima kasih atas banyak tanggapan yang sangat informatif, saya belajar banyak dan akan merujuk pada Q ini saat berikutnya hal ini terjadi ..

Ini bukan masalah DNS secara langsung, ini adalah masalah routing jaringan antara beberapa bagian internet dan server DNS untuk serverfault.com. Karena server nama tidak dapat dijangkau, domain berhenti menyelesaikan.

Sejauh yang saya tahu masalah routing pada router (Global Crossing?) Dengan alamat IP 204.245.39.50.

Seperti yang ditunjukkan oleh @radius , paket ke ns52 (seperti yang digunakan oleh stackoverflow.com ) lewat dari sini ke 208.109.115.121dan dari sana berfungsi dengan benar. Namun paket ke ns22 pergi ke 208.109.115.201.

Karena kedua alamat tersebut sama-sama sama /24dan pengumuman BGP yang sesuai juga untuk hal /24ini seharusnya tidak terjadi .

Saya telah melakukan traceroutes melalui jaringan saya yang pada akhirnya menggunakan MFN Above.net alih-alih Global Crossing untuk sampai ke GoDaddy dan tidak ada tanda-tanda tipu muslihat routing di bawah /24level - kedua server nama memiliki traceroute identik dari sini.

Satu-satunya saat saya pernah melihat sesuatu seperti ini adalah rusak Cisco Express Forwarding (CEF). Ini adalah cache level perangkat keras yang digunakan untuk mempercepat perutean paket. Sayangnya hanya sesekali keluar dari sinkronisasi dengan tabel routing nyata, dan mencoba meneruskan paket melalui antarmuka yang salah. Entri CEF dapat turun ke /32tingkat bahkan jika entri tabel routing yang mendasarinya adalah untuk a /24. Sulit menemukan masalah seperti ini, tetapi begitu teridentifikasi, biasanya mudah diperbaiki.

Saya telah mengirim email kepada GC dan juga mencoba berbicara dengan mereka, tetapi mereka tidak akan membuat tiket untuk non-pelanggan. Jika ada di antara Anda yang merupakan pelanggan GC, silakan coba dan laporkan ini ...

DIPERBARUI pada pukul 10:38 UTC Seperti yang telah dicatat Jeff, masalahnya kini telah beres. Traceroutes ke kedua server yang disebutkan di atas sekarang pergi melalui 208.109.115.121hop berikutnya.

server dns Anda untuk serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] tidak bisa dijangkau. untuk terakhir ~ 20 jam, setidaknya dari pasangan ISP utama di Swedia [ telia , tele2 , bredband2 ].

pada saat yang sama server 'tetangga' dns untuk stackoverflow.com & superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] dapat dijangkau.

contoh traceroute ke 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          

dan ke 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. ???

mungkin mengacaukan penyaringan / seseorang memicu beberapa perlindungan DDoS yang tidak diinginkan dan memasukkan beberapa bagian internet ke daftar hitam. mungkin Anda harus menghubungi penyedia layanan dns Anda - go daddy.

Anda dapat memverifikasi jika masalah [sebagian] diselesaikan dengan:

1. memeriksa apakah godaddy telah bereaksi dan mengubah server nama - mis. lookup serverfault.com di http://www.squish.net/dnscheck/ menggunakan tipe laporan: APAPUN
2. periksa apakah server nama yang disediakan merespons ping [tidak terlalu ilmiah karena server nama dapat berfungsi dengan baik dan masih memblokir icmp, tetapi dalam hal ini tampaknya icmp diizinkan ke server lain] dari telia melalui kaca pencarian .

sunting : pelacak dari tempat kerja

Polandia

 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              

jerman

 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       

sunting : semua berfungsi dengan baik sekarang memang.

Saran saya: seperti yang dijelaskan oleh Alnitak, masalahnya bukan DNS tetapi routing (mungkin BGP). Fakta bahwa tidak ada yang berubah dalam pengaturan DNS adalah normal, karena masalahnya bukan di DNS dia.

serverfault.com saat ini memiliki pengaturan DNS yang sangat buruk, tentu saja tidak cukup untuk situs penting seperti ini:

• hanya dua server nama
• semua telur dalam keranjang yang sama (keduanya berada di AS yang sama)

Kami baru saja melihat hasilnya: kesalahan routing (sesuatu yang cukup umum di Internet) cukup untuk membuat serverfault.com menghilang untuk beberapa pengguna (tergantung pada operator mereka, bukan pada negara mereka).

Saya sarankan untuk menambahkan lebih banyak server nama, yang terletak di AS lainnya. Ini akan memungkinkan ketahanan kegagalan. Anda dapat menyewanya untuk perusahaan swasta atau meminta pengguna serverfault untuk menawarkan hosting DNS sekunder (mungkin hanya jika pengguna memiliki> 1000 perwakilan :-)

Saya mengonfirmasikan bahwa NS21.DOMAINCONTROL.COM dan NS22.DOMAINCONTROL.COM juga tidak dapat diakses dari ISP Free.fr di Perancis.
Seperti traceroute pQd, tambang juga berakhir setelah 208.109.115.201 untuk ns21 dan 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  * * *

Tetapi ns52.domaincontrol.com (208.109.255.26) berfungsi dan berada dalam subnet yang sama dengan 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  * * *

Seperti yang Anda lihat, kali ini setelah 204.245.39.50 kita pergi ke 208.109.115.121 alih-alih 208.109.115.201. Dan pQd memiliki traceroute yang sama. Dari tempat kerja saya tidak melewati router 204.245.39.50 ini (Global Crossing).

Lebih banyak pelacak dari tempat kerja dan tidak bekerja akan membantu, tetapi sangat mungkin bahwa Global Crossing memiliki entri perutean palsu untuk 208.109.255.11/32 dan 216.69.185.11/32 sebagai 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 bekerja dengan baik.

Mengapa entri entri boged sulit untuk diketahui. Mungkin 208.109.115.201 (Go Daddy) mengiklankan rute yang tidak berfungsi untuk 208.109.255.11/32 dan 216.69.185.11/32.

EDIT: Anda dapat telnet route-server.eu.gblx.net untuk terhubung ke server rute Global Crossing dan melakukan traceroute dari dalam jaringan Global Crossing

EDIT: Tampaknya masalah yang sama sudah terjadi dengan orang lain NS beberapa hari yang lalu, lihat: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Apa yang akan berguna adalah melihat jejak resolusi terperinci dari lokasi yang gagal ... lihat lapisan jalan resolusi yang gagal itu. Saya tidak terbiasa dengan layanan yang Anda gunakan, tapi mungkin itu pilihan di suatu tempat.

Jika gagal, kemungkinan besar masalahnya "lebih rendah" di pohon, karena kegagalan pada root atau TLD akan memengaruhi lebih banyak domain (Anda berharap). Untuk meningkatkan ketahanan, Anda dapat mendelegasikan ke layanan DNS kedua untuk memastikan redundansi yang lebih baik dalam resolusi jika ada masalah dengan jaringan kontrol domain.

Saya terkejut Anda tidak meng-host DNS Anda sendiri. Keuntungan melakukannya dengan cara itu adalah jika DNS dapat dijangkau, demikian juga (semoga) situs Anda.

Setidaknya dari UPC, saya mendapatkan reaksi ini ketika mencoba untuk mendapatkan catatan A Anda dari server Anda yang berwenang (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

Ketika saya mencoba hal yang sama dari mesin di jaringan yang berbeda (OVH), saya mendapat jawaban

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

Saya mendapatkan perilaku serupa untuk beberapa domain lain, jadi saya berasumsi bahwa UPC (setidaknya) secara diam-diam mengarahkan kueri DNS ke server nama caching mereka sendiri, dan memalsukan balasan. Jika DNS Anda salah tingkah, ini bisa menjelaskannya karena server nama UPC mungkin men-caching respons NXDOMAIN.