Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

Go Daddy planté, une des plus grosses pannes dans le DNS

Première rédaction de cet article le 10 septembre 2012
Dernière mise à jour le 5 octobre 2012


Go Daddy est de loin le plus gros bureau d'enregistrement de .com et de nombreux autres TLD. Il sert aussi d'hébergeur DNS. Ce soir, tous leurs serveurs de noms sont injoignables, entraînant l'impossibilité de joindre des millions de noms de domaine, et donc les serveurs situés derrière. C'est l'une des plus grandes pannes qu'ait jamais connu le DNS. Elle illustre une nouvelle fois l'importance de s'assurer de la résilience de son service DNS, notamment par le biais de la redondance.

Le lundi 10 septembre, il est 19h00 UTC et la panne dure depuis déjà un certain temps (premier signalement sur la liste outages vers 18h00 UTC). Prenons un hasard un nom de domaine hébergé chez Go Daddy, 1stoptr.com. Tentons une interrogation :


% dig A 1stoptr.com

; <<>> DiG 9.8.1-P1 <<>> A 1stoptr.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Pas de réponse. Qu'arrive-t-il aux serveurs de noms ? Demandons au parent (VeriSign) les serveurs de noms de 1stoptr.com :


% dig @a.gtld-servers.net NS 1stoptr.com       

; <<>> DiG 9.8.1-P1 <<>> @a.gtld-servers.net NS 1stoptr.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38711
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1stoptr.com.                   IN      NS

;; AUTHORITY SECTION:
1stoptr.com.            172800  IN      NS      wsc1.jomax.net.
1stoptr.com.            172800  IN      NS      wsc2.jomax.net.
...
;; ADDITIONAL SECTION:
wsc1.jomax.net.         172800  IN      A       216.69.185.1
wsc2.jomax.net.         172800  IN      A       208.109.255.1

Ces deux serveurs sont bien chez Go Daddy comme on peut le vérifier avec whois :

% whois 216.69.185.1
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=216.69.185.1?showDetails=true&showARIN=false&ext=netref2
#

NetRange:       216.69.128.0 - 216.69.191.255
CIDR:           216.69.128.0/18
OriginAS:       
NetName:        GO-DADDY-COM-LLC
NetHandle:      NET-216-69-128-0-1
Parent:         NET-216-0-0-0-0
NetType:        Direct Allocation
...

Et ils ne répondent pas :


%  dig @216.69.185.1  A 1stoptr.com

; <<>> DiG 9.7.3 <<>> @216.69.185.1 A 1stoptr.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Et, surtout, c'est la même chose pour tous les serveurs de noms de Go Daddy. Le domaine de l'hébergeur lui-même, godaddy.com n'est pas davantage accessible :


% dig +nodnssec +nssearch godaddy.com

; <<>> DiG 9.7.3 <<>> +nodnssec +nssearch godaddy.com
;; global options: +short +cmd
;; connection timed out; no servers could be reached

Et comme pas de DNS égal pas de Web, ni d'autres services, on voit l'ampleur de la panne... Celle-ci a duré jusqu'à environ 20h40 UTC, où il y a eu une légère rémission, avant que cela ne re-plante. Finalement, le service a été rétabli quelques heures après (apparemment en migrant une partie de l'infrastructure sur la plate-forme de VeriSign). C'est donc assez long, même en cas de dDoS.

Que s'est-il passé ? Sur le moment, une personne se prétendant Anonymous a revendiqué l'action. Mais n'importe qui peut envoyer un tweet et, comme il ne donnait aucun détail technique, il était donc difficile de savoir si c'est vrai. La première déclaration officielle de Go Daddy incriminait un problème technique interne dans leurs routeurs. L'hypothèse d'une attaque par déni de service distribué aussi réussie contre une infrastructure anycastée était certes possible mais, quand même, cela aurait en effet très difficile à réussir.

Au fait, pourquoi Anonymous aurait-il attaqué Go Daddy ? Peut-être parce qu'ils aiment les éléphants ? Ou parce qu'ils sont choqués des publicités de mauvais goût de Go Daddy, à base de pinups vulgaires en bikini ? Mais Go Daddy est aussi connu pour son soutien à SOPA (voir Wikipédia), et pour être un des hébergeurs les plus rapides à censurer ses clients lorsque le gouvernement ou l'industrie du divertissement le demande (voir l'affaire JotForm ou celle de RateMyCop). Comme disent les policiers, il y a donc beaucoup trop de suspects...

Finalement, le 5 octobre, Go Daddy a publié un rapport technique très détaillé. Le problème (si on prend ce rapport au pied de la lettre mais il semble cohérent avec les faits observés) était bien dans les routeurs. Une combinaison d'incidents avait entraîné l'apparition d'un très grand nombre de routes, dépassant la capacité de la table de routage. Ces routes ont été propagées en interne, plantant ainsi la totalité des routeurs. Même une fois le problème technique analysé, la correction a été longue car chaque fois qu'un des sites de Go Daddy repartait, tout le trafic se précipitait vers lui... et le replantait.

Autres articles :

Une amusante ligne de script shell pour détecter si un de vos sites Web dépend de Go Daddy (merci à climagic). À exécuter dans le répertoire où se trouve la config Apache :

grep ServerName * | grep -io "[a-z0-9-]*\.[a-z]*$" | \
     sort -u | while read -r d; do whois $d | grep -q "GODADDY" &&echo $d; done # site check

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)