DNS nie rozprzestrzenia się na całym świecie

Nie zmieniłem niczego związanego z wpisem DNS dla serverfault.com , ale niektórzy użytkownicy zgłaszali dziś, że DNS serverfault.com nie rozwiązuje ich .

Pobiegłem zapytanie justping i mogę potwierdzić tego rodzaju - serverfault.com dns wydaje się być w przypadku braku rozwiązać w kilku krajach, bez żadnego konkretnego powodu, że mogę dostrzec. (potwierdzone również przez What's My DNS, który wykonuje podobne pingi na całym świecie, więc zostało to potwierdzone przez dwa różne źródła).

• Dlaczego tak się dzieje, jeśli nie dotknąłem DNS serverfault.com?

• naszym rejestratorem jest (gag) GoDaddy i używam domyślnych ustawień DNS w przeważającej części bez żadnych incydentów. czy robię coś źle? Czy bogowie DNS mnie opuścili?

• czy jest coś, co mogę zrobić, aby to naprawić? Czy jest jakiś sposób, aby gęsić DNS razem lub zmusić DNS do prawidłowej propagacji na całym świecie?

Aktualizacja: od poniedziałku o 3:30 czasu PST wszystko wygląda poprawnie. Witryna raportów JustPing jest dostępna ze wszystkich lokalizacji. Dziękuję za wiele bardzo pouczających odpowiedzi, wiele się nauczyłem i odniosę się do tego Q następnym razem, gdy to się stanie.

Nie jest to bezpośrednio problem DNS, to problem z routingiem sieciowym między niektórymi częściami Internetu a serwerami DNS dla serverfault.com. Ponieważ nie można uzyskać dostępu do serwerów nazw, domena przestaje być rozpoznawana.

O ile wiem, problem z routingiem występuje na routerze (Global Crossing?) Z adresem IP 204.245.39.50.

Jak pokazano przez @radius pakiety do ns52 (używane przez stackoverflow.com ) przechodzą stąd 208.109.115.121i stamtąd działa poprawnie. Jednak pakiety do ns22 zamiast tego idą do 208.109.115.201.

Ponieważ te dwa adresy są zarówno w tym samym /24i odpowiednie zawiadomienie BGP jest również dla /24tego nie powinno się zdarzyć .

Zrobiłem traceroute za pośrednictwem mojej sieci, która ostatecznie używa MFN Above.net zamiast Global Crossing, aby dostać się do GoDaddy i nie ma żadnych śladów routingu poniżej /24poziomu - oba serwery nazw mają stąd identyczne traceroute.

Jedyny raz, kiedy widziałem coś takiego, był zepsuty Cisco Express Forwarding (CEF). Jest to pamięć podręczna na poziomie sprzętowym używana do przyspieszenia routingu pakietów. Niestety czasami okazjonalnie nie synchronizuje się z prawdziwą tabelą routingu i próbuje przekazywać pakiety przez niewłaściwy interfejs. Pozycje CEF mogą zejść do /32poziomu, nawet jeśli podstawowy wpis tablicy routingu jest dla /24. Znalezienie tego rodzaju problemów jest trudne, ale po zidentyfikowaniu można je zwykle łatwo naprawić.

Wysłałem e-mail do GC i próbowałem z nimi porozmawiać, ale nie stworzą biletu dla osób niebędących klientami. Jeśli ktoś z was jest klientem GC, spróbuj zgłosić to ...

AKTUALIZACJA o 10:38 UTC Jak zauważył Jeff, problem został już rozwiązany. Trasy na oba wyżej wymienione serwery przechodzą teraz przez 208.109.115.121następny przeskok.

twoje serwery dns dla serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] są nieosiągalne. przez ostatnie ~ 20 godzin, przynajmniej od kilku głównych isps w Szwecji [ telia , tele2 , bredband2 ].

w tym samym czasie można dotrzeć do serwerów sąsiadów dns dla stackoverflow.com i superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com].

przykładowy traceroute do 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          

i do 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. ???

może spieprzyło filtrowanie / ktoś uruchomił niechcianą ochronę przed DDOS i umieścił na czarnej liście niektóre części Internetu. prawdopodobnie powinieneś skontaktować się z usługodawcą dns ​​- idź tatusiu.

możesz sprawdzić, czy problem został [częściowo] rozwiązany przez:

1. sprawdzanie, czy godaddy zareagował i zmienił serwery nazw - np. odnośnik serverfault.com na http://www.squish.net/dnscheck/ przy użyciu typu recort: DOWOLNY
2. sprawdzić, czy dostarczone serwery nazw odpowiada na ping [niezbyt naukowy ponieważ serwery nazw może działać dobrze i nadal blokować ICMP, ale w tym przypadku wydaje się, że ICMP jest dozwolone do innych serwerów] z Telia poprzez Looking Glass .

edycja : traceroutes z miejsc pracy

Polska

 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              

Niemcy

 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       

edycja : teraz wszystko działa dobrze.

Moje sugestie: jak wyjaśnił Alnitak, problemem nie jest DNS, ale routing (prawdopodobnie BGP). Fakt, że nic się nie zmieniło w konfiguracji DNS jest normalny, ponieważ problem nie dotyczył DNS.

serverfault.com ma dziś bardzo słabą konfigurację DNS, z pewnością niewystarczającą dla tak ważnej witryny:

• tylko dwa serwery nazw
• wszystkie jajka w tym samym koszu (oba są w tym samym AS)

Właśnie widzieliśmy wynik: usterka routingu (coś, co jest dość powszechne w Internecie) jest wystarczająca, aby serwerfault.com zniknął dla niektórych użytkowników (w zależności od ich operatorów, a nie ich krajów).

Proponuję dodać więcej serwerów nazw, znajdujących się w innym AS. Pozwoliłoby to na odporność na awarie. Możesz wypożyczyć je prywatnym firmom lub poprosić użytkowników, którzy popełniają błąd serwera, o zaoferowanie dodatkowego hostingu DNS (może być tylko wtedy, gdy użytkownik ma> 1000 powtórzeń :-)

Potwierdzam, że NS21.DOMAINCONTROL.COM i NS22.DOMAINCONTROL.COM są również nieosiągalne z ISP Free.fr we Francji.
Podobnie jak pQd traceroute, moje również kończą się po 208.109.115.201 zarówno dla ns21, jak i 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  * * *

Ale ns52.domaincontrol.com (208.109.255.26) działa i jest w tej samej podsieci co 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  * * *

Jak widać, tym razem po 204.245.39.50 idziemy do 208.109.115.121 zamiast 208.109.115.201. I pQd ma ten sam traceroute. Z miejsca pracy nie przekroczyłem routera 204.245.39.50 (Global Crossing).

Przydałoby się więcej traceroute z miejsca pracy i miejsca pracy, ale jest wysoce prawdopodobne, że Global Crossing ma fałszywy wpis routingu dla 208.109.255.11/32 i 216.69.185.11/32 jako 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 działają dobrze.

Trudno jest ustalić, dlaczego ma on fałszywy wpis routingu. Prawdopodobnie 208.109.115.201 (Go Daddy) reklamuje niedziałającą trasę dla 208.109.255.11/32 i 216.69.185.11/32.

EDYCJA: Możesz telnet route-server.eu.gblx.net, aby połączyć się z serwerem trasy Global Crossing i zrobić traceroute z sieci Global Crossing

EDYCJA: Wygląda na to, że ten sam problem wystąpił już u innych NS kilka dni temu, patrz: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Przydałoby się szczegółowe śledzenie rozdzielczości w lokalizacjach, w których występują awarie ... Zobacz, na której warstwie ścieżki rozdzielczości nie działa. Nie znam usługi, z której korzystasz, ale być może jest to gdzieś opcja.

W przeciwnym razie problemy najprawdopodobniej znajdują się „niżej” w drzewie, ponieważ awarie w katalogu głównym lub domenach TLD wpłynęłyby na więcej domen (można mieć nadzieję). Aby zwiększyć odporność, możesz delegować do drugiej usługi DNS, aby zapewnić lepszą redundancję rozdzielczości, jeśli występują problemy z sieciami Domaincontrol.

Dziwię się, że nie hostujesz własnego DNS. Zaletą robienia tego w ten sposób jest to, że DNS jest osiągalny, podobnie jak (mam nadzieję) Twoja witryna.

Przynajmniej od UPC dostaję tę reakcję, gdy próbuję uzyskać rekord A z twojego autorytatywnego serwera (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

Gdy próbuję tego samego z komputera w innej sieci (OVH), otrzymuję odpowiedź

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

Mam podobne zachowanie w przypadku kilku innych domen, więc zakładam, że UPC (przynajmniej) cicho przekierowuje zapytania DNS do własnego buforującego serwera nazw i fałszuje odpowiedzi. Jeśli Twój DNS źle się zachował, może to wyjaśniać, ponieważ serwery nazw UPC mogą buforować odpowiedź NXDOMAIN.