Il DNS non si è propagato in tutto il mondo

Non ho modificato nulla in relazione alla voce DNS per serverfault.com , ma alcuni utenti hanno segnalato oggi che il DNS serverfault.com non riesce a risolverli .

Ho eseguito una query justping e posso in qualche modo confermarlo: serverfault.com dns sembra non riuscire a risolversi in una manciata di paesi, senza un motivo particolare per cui riesco a discernere. (confermato anche tramite What's My DNS che esegue alcuni ping in tutto il mondo in modo simile, quindi è confermato come problema da due diverse fonti.)

• Perché dovrebbe succedere questo, se non ho toccato il DNS per serverfault.com?

• il nostro registrar è (gag) GoDaddy e utilizzo le impostazioni DNS predefinite per la maggior parte senza incidenti. Sto facendo qualcosa di sbagliato? Gli dei del DNS mi hanno abbandonato?

• c'è qualcosa che posso fare per risolvere questo problema? Qualche modo per far andare avanti il ​​DNS o forzare la propagazione corretta del DNS in tutto il mondo?

Aggiornamento: a partire da lunedì alle 3:30 PST, tutto sembra corretto .. Il sito di report di JustPing è raggiungibile da tutte le località. Grazie per le molte risposte molto istruttive, ho imparato molto e mi riferirò a questo Q la prossima volta che accadrà.

Questo non è direttamente un problema DNS, è un problema di routing di rete tra alcune parti di Internet e i server DNS per serverfault.com. Poiché non è possibile raggiungere i nameserver, il dominio smette di risolversi.

Per quanto ne so, il problema di routing si trova sul router (Global Crossing?) Con indirizzo IP 204.245.39.50.

Come mostrato da @radius , i pacchetti a ns52 (usati da stackoverflow.com ) passano da qui a 208.109.115.121e da lì funzionano correttamente. Tuttavia, i pacchetti a ns22 vanno invece a 208.109.115.201.

Poiché tali due indirizzi sono entrambi nella stessa /24ed il corrispondente annuncio BGP è anche un /24questo non dovrebbe accadere .

Ho fatto traceroute tramite la mia rete che alla fine usa MFN Above.net invece di Global Crossing per arrivare a GoDaddy e non c'è traccia di trucchi di routing al di sotto del /24livello: entrambi i server dei nomi hanno traceroute identici da qui.

Le uniche volte in cui ho mai visto qualcosa del genere è stato rotto Cisco Express Forwarding (CEF). Questa è una cache a livello hardware utilizzata per accelerare il routing dei pacchetti. Sfortunatamente solo occasionalmente si sincronizza con la tabella di routing reale e tenta di inoltrare i pacchetti tramite l'interfaccia errata. Le voci CEF possono scendere al /32livello anche se la voce della tabella di routing sottostante è per a /24. È difficile trovare questo tipo di problemi, ma una volta identificati sono normalmente facili da risolvere.

Ho inviato un'e-mail a GC e ho anche provato a parlare con loro, ma non creeranno un biglietto per i non clienti. Se qualcuno di voi è un cliente di GC, prova a segnalarlo ...

AGGIORNAMENTO alle 10:38 UTC Come ha notato Jeff, il problema è stato risolto. I traceroute su entrambi i server sopra menzionati passano ora al passaggio 208.109.115.121successivo.

i tuoi server DNS per serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] sono irraggiungibili. per le ultime 20 ore, almeno dalle due maggiori isole della Svezia [ telia , tele2 , bredband2 ].

contemporaneamente sono raggiungibili i server DNS "adiacenti" per stackoverflow.com e superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com].

traceroute di esempio su 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          

e su 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. ???

forse ha rovinato il filtro / qualcuno ha innescato una protezione indesiderata di ddos ​​e ha inserito nella lista nera alcune parti di Internet. probabilmente dovresti contattare il tuo fornitore di servizi DNS - vai papà.

puoi verificare se il problema è [parzialmente] risolto da:

1. verifica se godaddy ha reagito e modificato i server dei nomi - ad esempio, cerca serverfault.com su http://www.squish.net/dnscheck/ usando il tipo di risposta: ANY
2. controlla se i server dei nomi forniti rispondono al ping [non molto scientifico poiché i server dei nomi possono funzionare bene e continuano a bloccare icmp, ma in questo caso sembra che icmp sia autorizzato ad altri server] da telia attraverso lo specchio .

modifica : traceroutes da luoghi di lavoro

Polonia

 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              

Germania

 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       

modifica : tutto ora funziona davvero bene.

I miei suggerimenti: come spiegato da Alnitak, il problema non è il DNS ma il routing (probabilmente BGP). Il fatto che nulla sia stato modificato nell'impostazione DNS è normale, poiché il problema non era nel DNS.

serverfault.com ha oggi una configurazione DNS molto scarsa, sicuramente insufficiente per un sito importante come questo:

• solo due server dei nomi
• tutte le uova nello stesso cestino (entrambi sono nello stesso AS)

Abbiamo appena visto il risultato: un errore di routing (qualcosa che è abbastanza comune su Internet) è sufficiente per far scomparire serverfault.com per alcuni utenti (a seconda dei loro operatori, non dei loro paesi).

Suggerisco di aggiungere altri server dei nomi, situati in altri AS. Ciò consentirebbe la resilienza ai guasti. Puoi noleggiarli a società private o chiedere agli utenti serverfault di offrire hosting DNS secondario (potrebbe essere solo se l'utente ha> 1000 rappresentanti :-)

Confermo che NS21.DOMAINCONTROL.COM e NS22.DOMAINCONTROL.COM non sono raggiungibili da ISP Free.fr in Francia.
Come pQd traceroute, anche il mio termina dopo 208.109.115.201 sia per ns21 che per 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  * * *

Ma ns52.domaincontrol.com (208.109.255.26) funziona ed è nella stessa sottorete di 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  * * *

Come puoi vedere, questa volta dopo 204.245.39.50 andiamo a 208.109.115.121 invece di 208.109.115.201. E pQd ha lo stesso traceroute. Da un posto di lavoro non ho attraversato questo router 204.245.39.50 (Global Crossing).

Un maggior numero di traceroute dal luogo di lavoro e non lavorativo sarebbe utile, ma è altamente probabile che il Global Crossing abbia una voce di routing fasulla per 208.109.255.11/32 e 216.69.185.11/32 come 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 stanno funzionando bene.

Perché ha una voce di routing bloccata è difficile da sapere. Probabilmente 208.109.115.201 (Go Daddy) pubblicizza un percorso non funzionante per 208.109.255.11/32 e 216.69.185.11/32.

EDIT: è possibile telnet route-server.eu.gblx.net per connettersi al server di route Global Crossing ed eseguire traceroute all'interno della rete Global Crossing

EDIT: sembra che lo stesso problema si sia già verificato con altri NS pochi giorni fa, vedi: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Sarebbe utile vedere una traccia dettagliata della risoluzione dalle posizioni che non riescono ... vedere su quale livello del percorso di risoluzione sta fallendo. Non ho familiarità con il servizio che stai utilizzando, ma forse è un'opzione da qualche parte.

In caso contrario, è molto probabile che i problemi siano "più in basso" nella struttura, poiché i guasti alla radice o ai TLD influirebbero su più domini (si spera). Per aumentare la resilienza, è possibile delegare a un secondo servizio DNS per garantire una migliore ridondanza nella risoluzione in caso di problemi con le reti di controllo dominio.

Sono sorpreso che tu non abbia il tuo DNS. Il vantaggio di farlo in questo modo è se il DNS è raggiungibile, così è (si spera) il tuo sito.

Almeno da UPC, ottengo questa reazione quando provo a ottenere il tuo record A dal tuo server autorevole (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

Quando provo la stessa cosa da una macchina su una rete diversa (OVH), ottengo una risposta

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

Ricevo un comportamento simile per un paio di altri domini, quindi presumo che UPC (almeno) reindirizzi silenziosamente le query DNS al proprio server dei nomi nella cache e falsi le risposte. Se il DNS si fosse comportato in modo errato per un breve periodo, ciò potrebbe spiegarlo poiché i nameserver di UPC potrebbero memorizzare nella cache la risposta NXDOMAIN.