Vous avez raison de dire que le cache DNS atténuerait l'indisponibilité d'un serveur de noms. Il est extrêmement courant d'avoir un TTL de 5 minutes ou moins. Par conséquent, 5 minutes après l'attaque DDOS qui a fait tomber Dyn, votre cache aurait été invalide et vous n'auriez pas pu frapper github, etc.

Une petite modification de la conception des caches DNS pourrait faire une grande différence. La plupart des caches DNS suppriment une entrée à l'expiration du TTL. Un cache pourrait à la place 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, retournera l'entrée expirée. Je pense que c'est 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) montre 212 résultats avec une valeur TTL de 300 (5 mins), 192 hits avec un TTL de 3600 (1 hr), 116 hits avec un TTL de 600 (10 mins) et 79 hits avec un TTL de 86400. Le reste des résultats avait des hits dans les années 50 et moins. , allant d'un TTL de 5 (1 hit) à un TTL de 864000 (1 hit).

Voici une citation de Ben Anderson, chercheur et rédacteur technique chez Dyn.

En regardant ces résultats, vous pouvez le voir sur une petite quantité si votre navigateur invalide le cache DNS. Et votre résolution DNS commence à échouer.

Référence

• Pourquoi la mise en cache DNS du navigateur Web peut être une mauvaise chose

_{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.

DNS La mise en cache n'aiderait pas beaucoup.

Les appareils mis en esclavage de mirai sont capables de mener n'importe quel nombre d'attaques différentes selon les instructions du CnC. Dans le cas de l'attaque contre la sécurité de Krebbs et DYN, les attaquants ont simplement rempli leur bande passante avec du trafic - peu importe le trafic. Bien que le DNS puisse être exploité pour une attaque indirecte par amplification, 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 ne permettait pas 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), alors 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 été perturbé de toute façon. 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 (mon expérience est que les délais d'expiration de moins de 2 heures sont inefficaces). En outre, un site à fort trafic aura plusieurs points de présence géographiques ainsi que plusieurs enregistrements A à chaque POP - les adresses de multidiffusion sont chères et (en raison d'edns-client-subnet) non requises autrement 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 le bon vieux temps, la durée de vie (TTL) des enregistrements DNS était généralement comprise entre 3600 et 86400 secondes. On s'attendait à ce que quiconque demande un enregistrement particulier vous obtienne toujours la même réponse .

Certaines personnes ont alors pensé que si elles utilisaient des TTL très courts, elles pourraient exécuter des astuces DNS stupides ® qui contraignent le DNS à faire des choses qu'il n'était pas censé faire .

Par exemple, certaines appliances d'équilibrage de charge ont des serveurs DNS intégrés qui surveillent la santé du back- serveurs finaux et fournissent une réponse différente à chaque requête 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 (aka "Global Server Load Balancing").

À propos de l'attaque de la semaine dernière contre Dyn - une bonne pratique DNS consistait à distribuer vos serveurs DNS faisant autorité sur plusieurs réseaux (et / ou opérateurs) afin que une attaque ou une panne sur l'un d'entre eux vous laisserait toujours avec DNS en cours d'exécution.

Cependant, les "astuces" mentionnées ci-dessus impliquent des algorithmes et «intelligence» 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 de mise en cache d'un enregistrement de ressource est spécifiée par le serveur, appelée TTL.

La signification du champ TTL est une limite de temps sur la durée pendant laquelle un RR peut être conservé dans un cache. Cette limite ne s'applique pas aux données faisant autorité dans les zones; il est également expiré, 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 des TTL courts peuvent être utilisés pour minimiser la mise en cache et qu'un TTL nul interdit la mise en cache, les réalités des performances Internet suggèrent que ces heures devraient être de l'ordre du jour pour l'hôte typique. Si un changement peut être anticipé, le TTL peut être réduit avant le changement pour minimiser les incohérences pendant le changement, puis ramené à sa valeur antérieure après le changement.

(extrait de RFC 1034)

Le serveur peut dire 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 la durée de vie de leurs enregistrements de ressources sur une durée relativement courte, par exemple 5 minutes. De cette façon, ils peuvent modifier leur enregistrement DNS en cas de défaillance de certains de leurs serveurs. Et les clients interrogeant le RR toutes les 5 minutes ne sont pas trop surchargés que de l'interroger une seule fois.

De plus, les applications mettent généralement en cache le RR dans la RAM. Ainsi, les enregistrements sont perdus une fois l'application redémarrée. (Il y a des exceptions. Vous pouvez vider le cache de BIND dans le système de fichiers par exemple.)

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.