2. Le cache poisoning

Afin de ne pas redemander systématiquement les noms les plus utilisés, les DNS maintiennent un cache. Ce cache sert à accélérer les réponses aux stations clientes du DNS. En effet si le DNS demande l'adresse d'Ebay ou de Google (ce qui arrive très souvent dans une entreprise) il ne sert à rien de poser systématiquement la question directement au serveur DNS de Google ou d'Ebay. En effet l'adresse de ces serveurs à peu de chance de varier sur une courte période ou cela est exceptionnel. Afin donc de ne pas surcharger le système et d'accélérer les réponses, la réponse est stockée dans le cache du DNS local. Le but de l'empoisonnement est de fausser ce cache !

En 1993, Christophe Schuba, Ingénieur chez SUN, professeur et participant à l'IEEE, a été le premier à alerter les administrateurs sur le problème du « DNS cache Poisoning ». Il s'agissait d'envoi d'informations surnuméraire à une requête adressée à un DNS. Les informations supplémentaires peuvent être stockées dans le cache, c'est-à-dire une mémoire tampon, du DNS l'incitant, lors des requêtes suivantes, à répondre de façon erronée Le nom de domaine ou la machine demandée est alors remplacé par un autre nom ou une autre machine.

En 1997, le CERT publie une alerte indiquant que les numéros de séquence des réponses sont devenus « prédictibles » pour les attaquants. Ces numéros de séquence servent à organiser les paquets participants à une requête DNS. Ceux-ci avaient la possibilité de répondre à la place du serveur DNS. Le logiciel de DNS BIND, de loin le plus répandu, incrémentait de 1 le numéro des transactions à chaque nouvelle requête. Il suffisait donc à l'attaquant d'essayer des numéros de séquence (1, 2, 3, 4, 5, etc .), pour trouver rapidement le bon et marquer ces paquets avec le numéro correspondant, à ce stade, il pouvait facilement s'insérer dans la conversation et tromper le DNS en lui renvoyant de fausses informations.