Après un an et demi de développement sortie du serveur DNS de mise en cache , responsable de la conversion récursive des noms. PowerDNS Recursor est construit sur la même base de code que PowerDNS Authoritative Server, mais les serveurs DNS récursifs et faisant autorité PowerDNS sont développés selon différents cycles de développement et sont publiés en tant que produits distincts. Code de projet sous licence GPLv2.
La nouvelle version élimine tous les problèmes liés au traitement des paquets DNS avec les indicateurs EDNS. Les anciennes versions de PowerDNS Recursor antérieures à 2016 avaient pour pratique d'ignorer les paquets avec des indicateurs EDNS non pris en charge sans envoyer de réponse dans l'ancien format, éliminant ainsi les indicateurs EDNS comme l'exige la spécification. Auparavant, ce comportement non standard était pris en charge dans BIND sous la forme d'une solution de contournement, mais dans le cadre de en février les initiatives , 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 ont été éliminés en 2017 dans la version 4.1, et dans la branche 2016 publiée en 4.0, des incompatibilités individuelles sont apparues qui surviennent dans un certain ensemble de circonstances et, en général, n'interfèrent pas avec le fonctionnement normal. opération. Dans PowerDNS Recursor 4.2, comme dans , Suppression de solutions de contournement pour prendre en charge les serveurs faisant autorité qui répondent de manière incorrecte aux requêtes avec des indicateurs EDNS. Jusqu'à présent, si après l'envoi d'une requête avec des indicateurs EDNS, il n'y avait pas de réponse après un certain temps, le serveur DNS supposait que les indicateurs étendus n'étaient pas pris en charge et envoyait une deuxième requête sans indicateurs EDNS. Ce comportement a maintenant été désactivé car ce code entraînait une latence accrue en raison des retransmissions de paquets, une charge réseau accrue et une ambiguïté en cas de non-réponse en raison de pannes réseau, et empêchait la mise en œuvre de fonctionnalités basées sur EDNS telles que les cookies DNS pour se protéger contre les attaques DDoS.
Il a été décidé d'organiser l'événement l'année prochaine conçu pour attirer l'attention sur avec fragmentation IP lors du traitement de messages DNS volumineux. Dans le cadre de l'initiative fixer les tailles de tampon recommandées pour EDNS à 1200 XNUMX octets, et le traitement des requêtes via TCP est une fonctionnalité incontournable sur les serveurs. Désormais, la prise en charge du traitement des requêtes via UDP est requise et TCP est souhaitable, mais pas requis pour le fonctionnement (la norme nécessite la possibilité de désactiver TCP). Il est proposé de supprimer l'option permettant de désactiver TCP de la norme et de normaliser la transition de l'envoi de requêtes via UDP à l'utilisation de TCP dans les cas où la taille du tampon EDNS établie n'est pas suffisante.
Les changements proposés dans le cadre de l'initiative élimineront toute confusion dans le choix de la taille du tampon EDNS et résoudront le problème de la fragmentation des messages UDP volumineux, dont le traitement entraîne souvent des pertes de paquets et des délais d'attente du côté client. Côté client, la taille du tampon EDNS sera constante et les réponses volumineuses seront immédiatement envoyées au client via TCP. Éviter d'envoyer des messages volumineux via UDP vous permettra également de bloquer pour empoisonner le cache DNS, basé sur la manipulation de paquets UDP fragmentés (lorsqu'il est divisé en fragments, le deuxième fragment n'inclut pas d'en-tête avec un identifiant, il peut donc être falsifié, pour lequel il suffit que la somme de contrôle corresponde) .
PowerDNS Recursor 4.2 prend en compte les problèmes liés aux gros paquets UDP et passe à l'utilisation de la taille de tampon EDNS (edns-outgoing-bufsize) de 1232 1680 octets, au lieu de la limite précédemment utilisée de 1232 6 octets, ce qui devrait réduire considérablement le risque de perte de paquets UDP. . La valeur 1280 a été choisie car il s'agit du maximum auquel la taille de la réponse DNS, en tenant compte d'IPv1232, rentre dans la valeur MTU minimale (XNUMX). La valeur du paramètre troncature-threshold, responsable du découpage des réponses au client, a également été réduite à XNUMX XNUMX.
Autres changements dans PowerDNS Recursor 4.2 :
- Ajout de la prise en charge du mécanisme (X-Proxied-For), qui est l'équivalent DNS de l'en-tête HTTP X-Forwarded-For, permettant aux informations sur l'adresse IP et le numéro de port du demandeur d'origine d'être transmises via des proxys intermédiaires et des équilibreurs de charge (tels que dnsdist) . Pour activer XPF, il existe des options ""Et"«;
- Prise en charge améliorée de l'extension EDNS (ECS), qui vous permet de transmettre dans des requêtes DNS à un serveur DNS faisant autorité des informations sur le sous-réseau à partir duquel la requête initiale transmise le long de la chaîne a été empoisonnée (les données sur le sous-réseau source du client sont nécessaires au fonctionnement efficace des réseaux de diffusion de contenu) . La nouvelle version ajoute des paramètres pour un contrôle sélectif sur l'utilisation du sous-réseau client EDNS : "» avec une liste de masques réseau pour lesquels l'IP sera utilisée dans ECS dans les requêtes sortantes. Pour les adresses qui ne rentrent pas dans les masques spécifiés, l'adresse générale spécifiée dans la directive "". Grâce à la directive "» vous pouvez définir des sous-réseaux à partir desquels les requêtes entrantes avec des valeurs ECS remplies ne seront pas remplacées ;
- Pour les serveurs traitant un grand nombre de requêtes par seconde (plus de 100 mille), la directive «", qui détermine le nombre de threads pour recevoir les requêtes entrantes et les répartir entre les threads de travail (n'a de sens que lors de l'utilisation du "").
- Paramètre ajouté pour définir votre propre fichier avec domaines dans lesquels les utilisateurs peuvent enregistrer leurs sous-domaines, au lieu de la liste intégrée à PowerDNS Recursor.
Le projet PowerDNS a également annoncé le passage à un cycle de développement de six mois, la prochaine version majeure de PowerDNS Recursor 4.3 étant attendue pour janvier 2020. Des mises à jour pour les versions importantes seront développées tout au long de l'année, après quoi des correctifs de vulnérabilités seront publiés pendant six mois supplémentaires. Ainsi, le support de la branche PowerDNS Recursor 4.2 durera jusqu'en janvier 2021. Des modifications similaires au cycle de développement ont été apportées à PowerDNS Authoritative Server, dont la version 4.2 est attendue dans un avenir proche.
Principales fonctionnalités du récurseur PowerDNS :
- Outils de collecte de statistiques à distance ;
- Redémarrage instantané ;
- Moteur intégré pour connecter les gestionnaires en langage Lua ;
- Prise en charge complète de DNSSEC et ;
- Prise en charge des RPZ (Response Policy Zones) et possibilité de définir des listes noires ;
- Mécanismes anti-usurpation d'identité ;
- Possibilité d'enregistrer les résultats de résolution sous forme de fichiers de zone BIND.
- Pour garantir des performances élevées, des mécanismes modernes de multiplexage de connexion sont utilisés dans FreeBSD, Linux et Solaris (kqueue, epoll, /dev/poll), ainsi qu'un analyseur de paquets DNS haute performance capable de traiter des dizaines de milliers de requêtes parallèles.
Source: opennet.ru