Pourquoi les caches DNS du navigateur n'atténuent-elles pas les attaques DDOS contre les fournisseurs DNS?
Pourquoi la récente attaque DDoS contre le fournisseur DNS Dyn et d'autres attaques similaires ont-elles réussi? Bien sûr, une attaque DDoS peut faire tomber une entité, et si cette entité contrôle les serveurs DNS, les requêtes vers ces serveurs de noms échoueront et les domaines répertoriés sous ces serveurs de noms ne seront pas accessibles par un hôte qui ne dispose pas déjà d'informations IP pour eux.
Mais puisque les navigateurs mettent en cache les enregistrements DNS, de nombreux hôtes auront déjà des informations IP pour ces domaines (au moins jusqu'à ce que leurs entrées de cache expirent) et donc le fait que les serveurs de noms soient en panne ne devrait pas avoir d'importance pour les hôtes avec des caches. Mais cela ne semble pas être le cas: lors de l'attaque d'hier, je n'ai pas pu accéder à github, npm, etc.
Vous avez raison de dire que le cache DNS permettrait d'éviter qu'un serveur de noms ne soit disponible. Il est extrêmement courant d'avoir un TTL de 5 minutes ou moins. Par conséquent, 5 minutes après l'attaque DDOS a fait tomber Dyn, votre cache aurait été invalide et vous n'auriez pas pu frapper github, etc.
Une petite modification de conception des caches DNS pourrait faire une grande différence. La plupart des caches DNS suppriment une entrée lorsque le TTL expire. Un cache peut plutôt conserver l'entrée, mais la marquer comme expirée. Si une requête arrive pour une entrée expirée, le cache essaiera d'abord de résoudre le nom en amont, et si cela échoue, renvoyer l'entrée expirée. Je m'attends à ce que cela soit techniquement en violation du protocole DNS, mais toujours un meilleur comportement d'échec.
Cependant, je ne m'attends pas à voir cela se produire. L'impact de l'arrêt des serveurs DNS serait toujours significatif - tous les sites que vous n'avez pas dans votre cache. L'accent restera sur le maintien de l'infrastructure DNS opérationnelle.
Mise à jour: @MatthieuM a souligné que EdgeDNS fait cela.
@Shackledtodesk est correct (+1), le cache du navigateur est conservé pendant une courte période. Ironiquement, certaines des meilleures références à ce sujet ont été publiées par Dyn:
Un programme simple que j'ai écrit pour interroger les 1000 meilleurs sites Web (selon Alexa) affiche 212 hits avec une valeur TTL de 300 (5 minutes), 192 hits avec un TTL de 3600 (1 h), 116 hits avec un TTL de 600 (10 min) et 79 hits avec un TTL de 86400). Le reste des résultats ont eu des hits dans les années 50 et moins, allant de TTL de 5 (1 hit) à a TTL de 864000 (1 hit).
Ceci est une citation de Ben Anderson, chercheur et rédacteur technique chez Dyn.
En regardant ces résultats, vous pouvez voir que sur une petite quantité si votre navigateur invalide le cache DNS. Et votre résolution DNS commence à échouer.
Référence
PS: Pour ajouter l'insulte à la blessure, l'article lié de Dyn soutient que le cache DNS du navigateur est une mauvaise chose.
Les navigateurs ne mettent pas en cache les enregistrements DNS
Ceci est une fonction du résolveur qui est un complément à la pile réseau.
La mise en cache DNS n'aiderait pas beaucoup
Les mirai esclaves sont capables de mener un nombre illimité d'attaques différentes selon les directives du CnC. Dans le cas de l'attaque contre la sécurité de Krebbs et DYN, les attaquants ont simplement rempli leur bande passante de trafic - peu importait vraiment le trafic. Bien que le DNS puisse être exploité pour une attaque d'amplification indirecte, je crois comprendre que cela ne s'applique pas dans le cas des attaques contre Krebss et DYN. Le DNS a été utilisé dans cette dernière attaque car il n'a pas été possible de filtrer le trafic réel du trafic d'attaque.
Si les enregistrements DNS étaient mis en cache ailleurs accessibles aux utilisateurs normaux (sur les caches DNS, pas dans les navigateurs), l'attaque aurait eu beaucoup moins d'impact, mais le modèle commercial DYN cible principalement l'hébergement DNS et la fourniture aux utilisateurs finaux. Ce dernier aurait malgré tout été perturbé. La présence des données dans les caches intermédiaires/autres fournisseurs d'utilisateurs finaux dépend du volume de trafic et du délai d'expiration (d'après mon expérience, les délais d'expiration inférieurs à 2 heures sont inefficaces). De plus, un site à fort trafic aura plusieurs points de présence géographiques ainsi que plusieurs enregistrements A à chaque POP - les adresses de multidiffusion sont coûteuses et (en raison de edns-client-subnet) ne sont pas nécessaires autres que pour DNS (en l'absence d'attaques DOS ).
Le DNS a été principalement conçu pour fournir un mappage stable (et peu cohérent) des noms aux adresses. Dans les bons vieux jours, le Time To Live (TTL) sur les enregistrements DNS était généralement de l'ordre de 3600 à 86400 secondes. On s'attendait à ce que celui qui a demandé un enregistrement particulier vous obtiendrez toujours la même réponse.
Certaines personnes ont ensuite pensé que si elles utilisaient des TTL très courts, elles pouvaient effectuer des astuces DNS stupides qui contraignaient le DNS à faire des choses ce n'était pas prév.
Par exemple, certaines appliances d'équilibrage de charge ont des serveurs DNS intégrés qui surveillent la santé des serveurs principaux et fournissent une réponse différente à chaque demande entrante en fonction de leur charge actuelle.
Certains opérateurs regardent l'adresse source de la requête entrante et renvoient différentes réponses pour rediriger le client vers le cluster d'applications le plus proche (alias "Global Server Load Balancing").
Apropos l'attaque de Dyn la semaine dernière - la bonne pratique DNS était que vous distribuiez vos serveurs DNS faisant autorité sur plusieurs réseaux (et/ou opérateurs) afin qu'une attaque ou une panne sur l'un vous laisse toujours exécuter DNS.
Cependant, les "astuces" susmentionnées impliquent des algorithmes et une "intelligence" sur mesure qui ne sont pas inhérents au DNS lui-même, de sorte qu'il devient très difficile (voire impossible) de s'appuyer sur la résilience intégrée du DNS. Un système qui génère des réponses synthétisées au lieu d'utiliser un fichier de zone ne peut pas être partagé entre plusieurs opérateurs utilisant AXFR.
Le cache DNS atténue les attaques DDOS contre les fournisseurs DNS, mais le cache NE DEVRAIT durer que peu de temps.
La durée maximale pendant laquelle un enregistrement de ressource doit être mis en cache est spécifiée par le serveur, appelé TTL.
La signification du champ TTL est une limite de temps pendant laquelle un RR peut être conservé dans un cache. Cette limite ne s'applique pas aux données faisant autorité dans les zones; elle est également expirée, mais par les politiques d'actualisation de la zone. Le TTL est attribué par l'administrateur pour la zone d'où proviennent les données. Alors que les TTL courts peuvent être utilisés pour minimiser la mise en cache, et un zéro TTL interdit la mise en cache, les réalités des performances Internet suggèrent que ces heures devraient être de l'ordre de jours pour l'hôte typique. Si un changement peut être anticipé, le TTL peut être réduit avant à la modification pour minimiser les incohérences lors de la modification, puis est revenu à sa valeur précédente après la modification.
(extrait de RFC 1034)
Le serveur peut indiquer au résolveur que l'enregistrement peut être mis en cache pendant plus de 68 ans, ce qui est généralement assez long pour qu'une attaque soit corrigée. Mais les serveurs ne le font généralement pas. Les grands sites Web ne veulent pas qu'une défaillance du réseau les affecte pendant longtemps. Une façon de le faire est de définir le TTL de leurs enregistrements de ressources sur une durée relativement courte, comme 5 minutes. De cette façon, ils peuvent modifier leur enregistrement DNS au cas où certains de leurs serveurs Et les clients interrogeant le RR toutes les 5 minutes ne sont pas beaucoup surchargés que de l'interroger une seule fois.
De plus, les applications mettent généralement le RR en mémoire cache. Les enregistrements sont donc perdus une fois l'application redémarrée. (Il existe des exceptions. Vous pouvez par exemple vider le cache de BIND dans le système de fichiers.)
Je veux mentionner Namecoin ici. Il stocke les noms de domaine sur le disque, dans une blockchain. Si votre site Web utilise un domaine .bit, il est peu probable qu'il tombe en panne uniquement à cause du fournisseur DNS.