Jeudi 20 juin vers 0000 UTC, un certain nombre de domaines ont été redirigés vers les serveurs de noms de Ztomy. Voici par exemple ce qui est arrivé au plus célèbre de ces domaines, linkedin.com, vu par DNSDB <►http://www.bortzmeyer.org/dnsdb.html> :
first seen 2013-06-20 00:17:09 -0000
last seen 2013-06-20 04:13:15 -0000
linkedin.com. NS ns1617.ztomy.com.
linkedin.com. NS ns2617.ztomy.com.
Selon certains témoignages, 50 000 domaines sont concernés. Cisco, par observation passive du DNS (comme DNSDB), en a confirmé 5 000 <▻http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions>.
Les serveurs de noms de Ztomy ne fournissant pas les réponses attendues, plus personne ne pouvait accéder aux services de ces domaines. Cela a logiquement fait du buzz <▻http://www.theregister.co.uk/2013/06/20/linkedin_dns_hijacked> <▻http://www.reddit.com/r/netsec/comments/1gpl3p/linkedin_dns_has_been_hijacked_pointing_at_rogue> <▻http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking> mais, comme souvent en ce qui concerne le DNS, sans informations techniques fiables et avec un vocabulaire très flou (« DNS poisoning » utilisé à tort et à travers).
Le bureau d’enregistrement de linkedin.com, Network Solutions, reconnait sa faute, dans un communiqué très court en détail et contenant au moins une grosse erreur (le problème n’était pas Web mais DNS) <▻https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-webs>
Le meilleur article de synthèse sur ce problème, fait par des gens compétents, est celui de l’ISC <▻http://www.isc.org/blogs/hijacking-dns-error-ddos-what-happened-and-what-you-can-do>.
Il semble donc bien que le problème soit une erreur humaine ou un bogue : voulant rediriger des domaines attaqués vers un service de mitigation des attaques par déni de service (un service qu’on paie pour que la guerre ait lieu chez eux), Network Solutions s’est trompé et a envoyé ses clients chez Ztomy. Moins sexy qu’un piratage mais plus courant. Il y a plus de maladroits que de cyberguerriers chinois ou iraniens.
L’incident a rappelé la difficulté de la coordination dans l’Internet : une fois le problème corrigé, il a fallu vider les caches des résolveurs DNS <▻http://www.bortzmeyer.org/vider-cache-resolveur.html>, qui gardaient la mauvaise information en mémoire. Des tentatives de la part de Network Solutions, via des messages non authentifiés et ne contenant aucun détail ont suscité quelques sarcasmes <▻https://lists.dns-oarc.net/pipermail/dns-operations/2013-June/010346.html>.
Le problème continue sans doute en ce moment, puisque les TTL des domaines sont souvent très longs (ici, deux jours) :
craigslist.com. 172800 IN NS ns1620.ztomy.com.
craigslist.com. 172800 IN NS ns2620.ztomy.com.
#LinkedIn #NetworkSolutions #DNSDB #résilience #DNS #sécurité