Écoutez cet article

Plusieurs applications DNS, en l’occurrence Microsoft DNS, prennent en charge EDNS0 qui étend les datagrammes de requête et de réponse. Lorsque vous mettez à niveau votre infrastructure DNS vers Windows 2008 R2 à partir de versions antérieures ou d’autres versions de DNS, vous pouvez remarquer un comportement particulier. Vous pouvez remarquer que certains noms d’hôtes ne peuvent plus être résolus à partir de ces nouveaux serveurs DNS. En revanche, d’autres noms d’hôtes semblent être résolus sans problème.

EDNS, ou Extension mechanisms for DNS, également connu sous le nom d’EDNS0, est une spécification visant à étendre la taille de plusieurs paramètres du protocole DNS (Domain Name System). Ce que vous constaterez en utilisant un analyseur de protocole, c’est que les paquets DNS contiendront un enregistrement de ressource OPT (optionnel) qui contient les paramètres supplémentaires.

Ces enregistrements optionnels peuvent être insérés dans les communications entre les nœuds DNS pour marquer un transfert de données utilisant EDNS. Les clients plus anciens qui ne prennent pas en charge EDNS ignorent simplement le nouveau type d’enregistrement. Les résolveurs DNS ne doivent envoyer des requêtes EDNS à un serveur DNS que s’ils sont prêts à accepter une réponse EDNS.

La cause de ce problème est très probablement due à l’incapacité de votre pare-feu périmétrique à autoriser le passage de ces paquets. Certains pare-feu sont câblés pour s’attendre à ce que les datagrammes DNS/UDP soient toujours d’une longueur maximale de 512 octets, ce qui est incorrect, et ils rejetteront tout simplement les datagrammes DNS/UDP plus longs. Si le pare-feu abandonne ou rejette ces paquets, la résolution des requêtes échouera car les requêtes du back-end expireront sans recevoir de réponse.

La façon la plus simple de résoudre ce problème est de configurer votre serveur DNS comme un « forwarder ». Si votre serveur DNS est configuré pour rediriger vers le(s) serveur(s) DNS de votre FAI ou un serveur DNS public, ce problème est immédiatement atténué. Une autre méthode qui peut être utilisée, si la redirection n’est pas une option, est de désactiver EDNS0 sur votre ou vos serveurs DNS. Cette option, à mon avis, est temporaire et ne doit pas être considérée comme la première option. 

Pour résoudre temporairement ce problème pendant que vous mettez à jour le firmware de votre pare-feu et/ou que vous le remplacez, vous pouvez désactiver EDNS0 sur vos serveurs DNS Windows.

Pour désactiver EDNS0, vous pouvez effectuer les modifications à partir de l’invite de commande ou en modifiant directement le registre.

Invite de commande (aucun redémarrage n’est nécessaire) :

dnscmd /config /EnableEDNSProbes 0 (La valeur « 0 » désactive EDNS0 et la valeur « 1 » l’active).

Registre (nécessite le redémarrage du service DNS) :

Créez un DWORD appelé EnableEDNSProbes et définissez-le sur 0 dans HKLM\SYSTEM\CurrentControlSet\services\DNS\Parameters.