La seule méthode réellement efficace nous paraît d'avoir deux DNS. Un premier, publique pour répondre aux requêtes concernant le domaine de l'entreprise, et un second, privé, pour répondre aux questions DNS des stations clientes du LAN qui veulent accéder à Internet. Ce second DNS interroge directement celui de l'ISP de l'entreprise ou même les « root servers ». Ces derniers sont placés sous très haute surveillance et il est extrêmement difficile de les attaquer L'attaque du DNS privé exige que l'attaquant soit lui-même au sein du réseau de l'entreprise ou se soit octroyé des droits équivalents par rebond. Le réseau de l'entreprise doit donc être lui-même sécurisé. Cela protègera l'entreprise concernée mais pas forcément ses clients car ceux-ci se reposent sur leurs propres DNS dont les caches est aussi successibles d'être empoisonnés. L'avantage et l'inconvénient d'un système distribué et hiérarchisé. SI l'un des DNS de la chaîne est compromis et empoisonné, les réponses peuvent être fausses. La sécurité ne repose donc plus entièrement sur les éléments que l'on possède mais sur toute la chaîne. De toute façon il reste indispensable de séparer le DNS dit « resolver » (celui qui répond aux questions des stations clientes de l'entreprise) et le DNS dit « server » qui répond aux requêtes des autres personnes qui cherchent à contacter l'entreprise et par exemple son site Web.

Une bonne configuration de DNS reste un travail d'expert.

Références

• [LUR] DNS Cache Poisoning, the next Generation
• [SCHUBA] Thèse de Doctorat
• [ANNIV] Wikipedia - Paradoxe des Anniversaires
• [CERTCC] Avis du CERT concernant la prédictabilité des séquences de BIND