DNS dünya çapında yayılmıyor

Serverfault.com için DNS girişi ile ilgili hiçbir şeyi değiştirmedim , ancak bazı kullanıcılar bugün serverfault.com DNS'in onlar için çözemediğini bildirdi .

Bir hakaret sorgusu çalıştırdım ve bunu doğrulayabiliyorum - serverfault.com dns, ayırt edebilmem için hiçbir sebep olmadan, birkaç ülkede çözemedi. (aynı zamanda dünya çapında bazı ping'leri benzer şekilde yapan, Benim DNS'im aracılığıyla da onaylandı , bu nedenle iki farklı kaynak tarafından sorun olarak onaylandı.)

• Serverfault.com için DNS’e dokunmadıysam, bu neden oluyor?

• kayıt şirketimiz (gag) GoDaddy'dir ve çoğunlukla olay için varsayılan DNS ayarlarını kullanıyorum. Yanlış bir şey mi yapıyorum? DNS tanrıları beni terk etti mi?

• Bunu düzeltmek için yapabileceğim bir şey var mı? DNS’i kazmak veya DNS’i dünya çapında doğru bir şekilde yaymaya zorlamak için herhangi bir yol var mı?

Güncelleme: Pazartesi günü saat 3: 30'da PST, her şey doğru görünüyor .. JustPing raporları sitesi tüm konumlardan erişilebilir durumda. Çok bilgilendirici cevaplar için teşekkür ederim, çok şey öğrendim ve bir dahaki sefere bu Q'ya atıfta bulunacağım.

Bu doğrudan bir DNS sorunu değil, internetin bazı bölümleriyle serverfault.com için DNS sunucuları arasında bir ağ yönlendirme sorunudur. Ad sunucularına erişilemediğinden, etki alanı çözümlenmeyi durdurur.

Yönlendirme sorununun IP adresli (Global Crossing?) Yönlendirici üzerinde olduğunu söyleyebildiğim kadarıyla 204.245.39.50.

@Radius tarafından gösterildiği gibi , ns52'ye ( stackoverflow.com tarafından kullanıldığı gibi) paketler buradan ve oradan doğru şekilde çalışır. Bununla birlikte, ns22'ye paketler yerine .208.109.115.121208.109.115.201

Bu iki adres de aynı içinde olduğundan /24ve ilgili BGP duyuru bir için de /24bu olmamalıydı .

GoDaddy'e ulaşmak için nihayetinde Global Crossing yerine MFN Above.net kullanan ve ağın üzerinden traceroutes yaptım ve /24seviyenin altında herhangi bir yönlendirme hilesi belirtisi yok - her iki isim sunucusu da buradan aynı traceroutes içeriyor.

Böyle bir şey gördüğüm tek zaman Cisco Express Forwarding (CEF) kırıldı . Bu, paket yönlendirmeyi hızlandırmak için kullanılan bir donanım düzeyinde önbellektir. Ne yazık ki, sadece zaman zaman gerçek yönlendirme tablosu ile senkronize olmuyor ve paketleri yanlış arayüz üzerinden iletmeye çalışıyor. CEF girişleri /32, altta yatan yönlendirme tablosu girişi a olsa bile seviyeye düşebilir /24. Bu tür sorunları bulmak zor, ancak bir kez tanımlandıkları zaman düzeltmeleri kolaydır.

GC'ye e-posta gönderdim ve onlarla konuşmaya da çalıştım, ancak müşteriler olmayanlar için bilet oluşturmayacaklar. İçinizden birinin ise şunlardır GC müşterisi, denemek ve bu rapor edin ...

GÜNCELLEME 10:38 UTC Jeff'in belirttiği gibi, problem şimdi çözüldü. Yukarıda belirtilen her iki sunucuya ilişkin traceroutes şimdi bir 208.109.115.121sonraki atlamadan geçiyor .

dns sunucularınızı serverfault.com için [ns21.domaincontrol.com, ns22.domaincontrol.com. ] erişilemiyor. son ~ 20 saat boyunca, en azından İsveç'teki çift ana isps'ten [ telia , tele2 , bredband2 ].

Aynı zamanda 'komşu' stackoverflow.com ve superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] için dns sunucularına ulaşılabilir.

ns52.domaincontrol.com için örnek traceroute:

 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          

ve 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. ???

belki berbat bir şekilde filtreleme / birisi istenmeyen bazı ddos ​​korumasını tetikledi ve internetin bazı bölümlerini kara listeye aldı. Muhtemelen dns servis sağlayıcınıza danışmalısınız - git baba.

Sorunun [kısmen] çözüldüğünü doğrulayabilirsiniz:

1. godaddy'nin ad sunucularına tepki verip vermediğini kontrol etme - örneğin http://www.squish.net/dnscheck/ adresindeki serverfault.com adresinde aranan kayıt türü: ANY
2. sağlanan ad sunucuları ping yanıt [ad sunucuları iyi çalışır ve hala icmp engelleyebilirsiniz beri çok bilimsel değil ama durumda icmp diğer sunuculara izin verildiğini görünüyor] aracılığıyla Telia'ya gelen kontrol camı görünümlü .

düzenleme : çalışma yerlerinden traceroutes

Polonya

 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              

Almanya

 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       

düzenleme : tüm gerçekten şimdi çalışıyor.

Önerilerim: Alnitak tarafından açıklandığı gibi, sorun DNS değil yönlendirmedir (muhtemelen BGP). DNS kurulumunda hiçbir şeyin değişmemiş olması normaldir, çünkü sorun DNS'de olmadığı için.

serverfault.com bugün çok zayıf bir DNS kurulumuna sahip, kesinlikle böyle bir site için yetersiz:

• sadece iki isim sunucusu
• aynı sepetteki bütün yumurtalar (her ikisi de aynı AS’dedir)

Sonucu az önce gördük: bir yönlendirme arızası (Internet'te oldukça yaygın olan bir şey) serverfault.com'un bazı kullanıcılar için (ülkelerinde değil operatörlerine bağlı olarak) kaybolması için yeterlidir.

Diğer AS'de bulunan daha fazla ad sunucusu eklemenizi öneririm. Bu, başarısızlığa direnç sağlar. Onları özel şirketlere kiralayabilir veya sunucu arızası kullanıcılarından ikincil DNS barındırma hizmeti vermelerini isteyebilirsiniz (yalnızca kullanıcı> 1000 rep :-) ise

NS21.DOMAINCONTROL.COM ve NS22.DOMAINCONTROL.COM’un Fransa’da ISP Free.fr’den de erişilemediğini onaylıyorum.
PQd traceroute gibi, benim de ns21 ve ns22 için 208.109.115.201 sonra sona erer.

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

Ancak ns52.domaincontrol.com (208.109.255.26) çalışır ve ns22.domaincontrol.com (208.109.255.11) ile aynı alt ağdadır.

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

Görebileceğiniz gibi, bu sefer 204.245.39.50'den sonra 208.109.115.201 yerine 208.109.115.121'ye gidiyoruz. Ve pQd aynı traceroute sahiptir. Çalışma yerinden bu 204.245.39.50 yönlendiricisini (Global Crossing) geçmedim.

İş yerinden ve çalışma yerinden daha fazla traceroute yardımcı olacaktır, ancak Global Crossing'in 208.109.255.11/32 ve 216.69.185.11/32 için 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69 olarak sahte bir yönlendirme girişi olması muhtemeldir. 185.12 iyi çalışıyor.

Neden bir yönlendirmeli girişe sahip olduğunu bilmek zor. Muhtemelen 208.109.115.201 (Go Daddy), 208.109.255.11/32 ve 216.69.185.11/32 için çalışmayan bir rota ilan ediyor.

EDIT: Global Crossing rota sunucusuna bağlanmak ve Global Crossing ağı içinden traceroute yapmak için route-server.eu.gblx.net adresinden telnet yapabilirsiniz.

EDIT: Birkaç gün önce NS ile aynı problemin yaşandığı görülüyor, bakınız: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

İşe yarayacak olan şey, başarısız olan konumlardan ayrıntılı bir çözüm izini görmek ... çözüm yolunun hangi katmanında başarısız olduğunu görmek. Kullanmakta olduğunuz hizmete aşina değilim, ama belki de bir yerlerde bir seçenek.

Bunu başaramazsanız, kökte veya TLD'lerde yaşanan problemler daha fazla alanı etkileyeceğinden, problemin ağaçta "daha düşük" olması muhtemeldir. Esnekliği artırmak için, domaincontrol ağlarında / ağlarında sorun varsa, çözünürlükte daha fazla yedeklilik sağlamak için ikinci bir DNS servisine yetki verebilirsiniz.

Kendi DNS'nizi barındırmamanıza şaşırdım. Bu şekilde yapmanın avantajı, DNS'ye erişilebiliyorsa, siteniz de (umarım) olur.

En azından UPC'den, A sunucunuzu yetkili sunucunuzdan (ns21.domaincontrol.com) almaya çalışırken bu reaksiyonu alıyorum.

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

Aynı şeyi farklı bir ağdaki bir makineden (OVH) denediğimde, bir cevap alıyorum

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

Diğer birkaç etki alanı için benzer davranışlar alıyorum, bu nedenle UPC'nin (en azından) sessizce DNS sorgularını kendi önbellekleme ad sunucularına yönlendirdiğini ve yanıtları taklit ettiğini varsayıyorum. DNS’niz kısaca yanlış davrandıysa, bu durumu UPC’nin ad sunucuları NXDOMAIN yanıtını önbelleğe alıyor olabilir.