# Qu'est-ce que l'empoisonnement du cache DNS ?

> L'empoisonnement du cache DNS (Domain Name System cache poisoning) se produit lorsqu'un résolveur récursif accepte de fausses données DNS et les stocke comme si elles étaient authentiques.

- URL canonique: https://yellowcube.eu/fr/glossary/domain-name-system-cache-poisoning/
- Éditeur: Yellow Cube
- Langue: fr
- Contact: hello@yellowcube.eu

## Contenu

Les clients ultérieurs peuvent recevoir la correspondance falsifiée depuis le cache, ce qui redirige le trafic ou provoque des échecs jusqu'à ce que l'entrée expire, soit remplacée ou soit supprimée. L'attaque corrompt les données de résolution en cache ; elle n'exige pas le contrôle de l'enregistrement du domaine ni de sa zone faisant autorité.

Les fausses données peuvent arriver dans une réponse forgée ou via un chemin de résolution compromis. Une correspondance forte (response matching) rend la falsification hors chemin plus difficile. La validation DNS Security Extensions (DNSSEC) rejette les données signées altérées lorsqu'une chaîne de confiance existe, mais n'authentifie ni les zones non signées ni chaque saut client-résolveur.

### Points clés

- **Étendue:** Identifier les résolveurs affectés, les noms et types d'enregistrements, le moment où l'enregistrement est entré dans le cache, sa durée de vie restante et les clients ou services qui l'ont reçu.
- **Preuves:** Comparer le contenu du cache aux données faisant autorité et aux résolveurs validants, puis examiner les journaux de réponses, les chemins de redirection (forwarding), les changements, les résultats de validation et l'activité redirigée.
- **Réduction du risque:** Maintenir le logiciel de résolution, employer une correspondance de réponses forte et une entropie de port source, restreindre la récursion et l'administration, valider DNSSEC lorsque c'est pertinent, protéger les canaux des résolveurs et surveiller les changements inattendus.
- **Limite importante:** Une réponse surprenante n'est pas automatiquement un empoisonnement. La mise en cache, le DNS split, le forwarding, les surcharges locales, l'équilibrage de charge et les erreurs de configuration peuvent produire des réponses qui diffèrent des données publiques ; des erreurs de signature peuvent aussi causer des échecs de validation DNSSEC.

### Termes associés

[Système de noms de domaine (DNS)](<https://yellowcube.eu/fr/glossary/domain-name-system/>) · [Sécurité du système de noms de domaine (DNS)](<https://yellowcube.eu/fr/glossary/domain-name-system-security/>) · [Détournement DNS](<https://yellowcube.eu/fr/glossary/domain-name-system-hijacking/>) · [Durée de vie (TTL)](<https://yellowcube.eu/fr/glossary/time-to-live/>) · [Pharming](<https://yellowcube.eu/fr/glossary/pharming/>)

### Sources

[IETF RFC 5452, Measures for Making DNS More Resilient against Forged Answers](https://www.rfc-editor.org/rfc/rfc5452.html) · [NIST SP 800-81 Rev. 3, Secure DNS Deployment Guide](https://csrc.nist.gov/pubs/sp/800/81/r3/final) · [ICANN : DNSSEC—What Is It and Why Is It Important?](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en/)

## Attribution et portée

Cette version Markdown est générée à partir des mêmes contenus approuvés que la page HTML canonique. Utilisez l’URL canonique pour toute citation.