Après un an et demi de développement lancement d'un serveur DNS en cache , responsable de la transformation récursive des noms. PowerDNS Recursor est basé sur la même base de code que PowerDNS Authoritative Server, mais les serveurs DNS récursifs et autoritatifs de PowerDNS évoluent dans des cycles de développement différents et sont publiés sous forme de produits distincts. Le code du projet sous licence GPLv2.
Dans la nouvelle version, toutes les remarques concernant le traitement des paquets DNS avec des drapeaux EDNS ont été corrigées. Dans les anciennes versions de PowerDNS Recursor avant 2016, il était courant d'ignorer les paquets avec des drapeaux EDNS non pris en charge, sans renvoyer de réponse au format ancien, en rejetant les drapeaux EDNS comme l'exige la spécification. Un comportement non standard comme celui-ci était auparavant maintenu dans BIND sous la forme d'un contournement, mais dans le cadre de février , les développeurs de serveurs DNS ont décidé d'abandonner ce hack.
Dans PowerDNS, les principaux problèmes de traitement des paquets avec EDNS avaient déjà été résolus en 2017 avec la version 4.1, et dans la branche 4.0, sortie en 2016, certaines incompatibilités isolées surgissaient dans certaines circonstances, mais en général ne nuisait pas au bon fonctionnement. Dans PowerDNS Recursor 4.2, tout comme dans , les contournements pour le support des serveurs autoritatifs répondant incorrectement aux requêtes avec des drapeaux EDNS ont été supprimés. Jusqu'à présent, si après l'envoi d'une requête avec des drapeaux EDNS, aucune réponse n'était reçue après un certain laps de temps, le serveur DNS considérait que les drapeaux étendus n'étaient pas pris en charge et renvoyait une nouvelle requête sans les drapeaux EDNS. Ce comportement est désormais désactivé, car la présence d'un tel code provoquait des délais d'attente supplémentaires dus à la renvoie de paquets, une charge accrue sur le réseau et une ambiguïté lorsque aucune réponse n'était fournie en raison d'échecs réseau, ce qui entravait également l'implémentation de fonctionnalités basées sur EDNS, telles que l'utilisation de cookies DNS pour se protéger contre les attaques DDoS.
L'année prochaine, il a été décidé d'organiser un événement , destiné à mettre l'accent sur de la fragmentation IP lors du traitement de messages DNS de grande taille. Dans le cadre de cette initiative, il est recommandé de fixer les tailles de tampon pour EDNS à des valeurs ne dépassant pas 1200 octets, et également le traitement des requêtes TCP obligatoire sur les serveurs. Actuellement, le traitement des requêtes UDP est obligatoire, tandis que TCP est souhaitable mais pas obligatoire pour le fonctionnement (la norme prévoit la possibilité de désactiver TCP). Il est proposé de supprimer de la norme l'option de désactivation de TCP et de normaliser le passage de l'envoi de requêtes par UDP à l'utilisation de TCP dans les cas où la taille de tampon EDNS établie est insuffisante.
Les propositions dans le cadre de cette initiative de changement élimineront la confusion lors du choix de la taille du tampon EDNS et résoudront le problème de la fragmentation des gros messages UDP, dont le traitement entraîne souvent des pertes de paquets et des délais d'attente du côté client. Du côté client, la taille du tampon EDNS sera fixe, et les grandes réponses seront immédiatement envoyées au client via TCP. L'exception de l'envoi de gros messages via UDP permettra également de bloquer les attaques par empoisonnement du cache DNS, basées sur la manipulation de paquets UDP fragmentés (dans la fragmentation, le deuxième fragment n'inclut pas l'en-tête avec l'identifiant, ce qui permet de falsifier suffisament pour que la somme de contrôle soit valide).
Dans PowerDNS Recursor 4.2, les problèmes liés aux gros paquets UDP ont été pris en compte, avec un passage à l'utilisation d'une taille de tampon EDNS (edns-outgoing-bufsize) de 1232 octets, au lieu de la limite précédente de 1680 octets, ce qui devrait réduire considérablement la probabilité de perte de paquets UDP. La valeur de 1232 a été choisie car elle constitue le maximum pour lequel la taille de la réponse DNS, tenant compte de l'IPv6, est inférieure à la valeur minimale du MTU (1280). La valeur du paramètre truncation-threshold, responsable de la coupure des réponses au client, a également été réduite à 1232.
Autres modifications dans PowerDNS Recursor 4.2 :
- Ajout de la prise en charge du mécanisme (X-Proxied-For), qui constitue l'équivalent de l'en-tête HTTP X-Forwarded-For pour DNS, permettant de transmettre des informations sur l'adresse IP et le numéro de port de l'initiateur original de la requête, redirigée via des proxies intermédiaires et des équilibreurs de charge (par exemple dnsdist). Pour activer XPF, les options «» et ««;
- Amélioration de la prise en charge de l'extension EDNS (ECS), permettant de transmettre dans les requêtes DNS au serveur DNS autoritaire des informations sur le sous-réseau d'où la demande originale a été envoyée, transmise en chaîne (les données sur le sous-réseau d'origine du client sont nécessaires pour le bon fonctionnement des réseaux de diffusion de contenu). Dans cette nouvelle version, des paramètres ont été ajoutés pour un contrôle sélectif de l'application de l'EDNS Client Subnet : «» avec une liste de masques de réseau, pour lesquels l'IP sera utilisée dans l'ECS pour les requêtes sortantes. Pour les adresses qui ne correspondent pas aux masques spécifiés, l'adresse générique indiquée dans la directive «« sera utilisée. Via la directive «» il est possible de définir des sous-réseaux à partir des requêtes entrantes avec des valeurs ECS remplies qui ne seront pas remplacées;
- Pour les serveurs traitant un grand nombre de requêtes par seconde (plus de 100 000), la directive «« définit le nombre de threads pour recevoir les requêtes entrantes et les répartir entre les threads de travail (n'a de sens que si le mode ««).
- Ajout d'un paramètre pour définir son propre fichier contenant de domaines où les utilisateurs peuvent enregistrer leurs sous-domaines, au lieu de la liste intégrée dans PowerDNS Recursor.
Le projet PowerDNS a également annoncé un passage à un cycle de développement semestriel, selon lequel la prochaine version majeure de PowerDNS Recursor 4.3 est attendue en janvier 2020. Des mises à jour pour les versions majeures seront réalisées au cours de l'année, après quoi des corrections de vulnérabilités seront publiées encore pendant six mois. Ainsi, le support de la branche PowerDNS Recursor 4.2 durera jusqu'en janvier 2021. Des changements similaires dans le cycle de développement ont été adoptés pour le produit PowerDNS Authoritative Server, dont la version 4.2 est attendue prochainement.
Les principales caractéristiques de PowerDNS Recursor :
- Outils de collecte de statistiques à distance;
- Redémarrage instantané;
- Moteur intégré pour connecter des gestionnaires en Lua;
- Support complet de DNSSEC et ;
- Support de RPZ (Response Policy Zones) et possibilité de définir des listes noires;
- Mécanismes de lutte contre le spoofing;
- Possibilité d'enregistrer les résultats de résolution sous forme de fichiers de zones BIND.
- Pour garantir des performances élevées, des mécanismes modernes de multiplexage de connexions sont utilisés sous FreeBSD, Linux et Solaris (kqueue, epoll, /dev/poll), ainsi qu'un analyseur DNS haute performance capable de traiter des dizaines de milliers de requêtes parallèles.
Source : opennet.ru
