{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Publication de PowerDNS Recursor 4.2 et initiative DNS flag day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Apr\u00e8s un an et demi de d\u00e9veloppement pr\u00e9sent\u00e9<\/a><\/noindex> lancement d'un serveur DNS en cache PowerDNS Recursor 4.2<\/a><\/noindex>, responsable de la transformation r\u00e9cursive des noms. PowerDNS Recursor est bas\u00e9 sur la m\u00eame base de code que PowerDNS Authoritative Server, mais les serveurs DNS r\u00e9cursifs et autoritatifs de PowerDNS \u00e9voluent dans des cycles de d\u00e9veloppement diff\u00e9rents et sont publi\u00e9s sous forme de produits distincts. Le code du projet est distribu\u00e9<\/a><\/noindex> sous licence GPLv2. <\/p>\n

Dans la nouvelle version, toutes les remarques concernant le traitement des paquets DNS avec des drapeaux EDNS ont \u00e9t\u00e9 corrig\u00e9es. Dans les anciennes versions de PowerDNS Recursor avant 2016, il \u00e9tait courant d'ignorer les paquets avec des drapeaux EDNS non pris en charge, sans renvoyer de r\u00e9ponse au format ancien, en rejetant les drapeaux EDNS comme l'exige la sp\u00e9cification. Un comportement non standard comme celui-ci \u00e9tait auparavant maintenu dans BIND sous la forme d'un contournement, mais dans le cadre de l'initiative<\/a><\/noindex> de f\u00e9vrier DNS flag day<\/a><\/noindex>, les d\u00e9veloppeurs de serveurs DNS ont d\u00e9cid\u00e9 d'abandonner ce hack. <\/p>\n

Dans PowerDNS, les principaux probl\u00e8mes de traitement des paquets avec EDNS avaient d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9solus en 2017 avec la version 4.1, et dans la branche 4.0, sortie en 2016, certaines incompatibilit\u00e9s isol\u00e9es surgissaient dans certaines circonstances, mais en g\u00e9n\u00e9ral ne nuisait pas au bon fonctionnement. Dans PowerDNS Recursor 4.2, tout comme dans BIND 9.14<\/a><\/noindex>, les contournements pour le support des serveurs autoritatifs r\u00e9pondant incorrectement aux requ\u00eates avec des drapeaux EDNS ont \u00e9t\u00e9 supprim\u00e9s. Jusqu'\u00e0 pr\u00e9sent, si apr\u00e8s l'envoi d'une requ\u00eate avec des drapeaux EDNS, aucune r\u00e9ponse n'\u00e9tait re\u00e7ue apr\u00e8s un certain laps de temps, le serveur DNS consid\u00e9rait que les drapeaux \u00e9tendus n'\u00e9taient pas pris en charge et renvoyait une nouvelle requ\u00eate sans les drapeaux EDNS. Ce comportement est d\u00e9sormais d\u00e9sactiv\u00e9, car la pr\u00e9sence d'un tel code provoquait des d\u00e9lais d'attente suppl\u00e9mentaires dus \u00e0 la renvoie de paquets, une charge accrue sur le r\u00e9seau et une ambigu\u00eft\u00e9 lorsque aucune r\u00e9ponse n'\u00e9tait fournie en raison d'\u00e9checs r\u00e9seau, ce qui entravait \u00e9galement l'impl\u00e9mentation de fonctionnalit\u00e9s bas\u00e9es sur EDNS, telles que l'utilisation de cookies DNS pour se prot\u00e9ger contre les attaques DDoS. <\/p>\n

L'ann\u00e9e prochaine, il a \u00e9t\u00e9 d\u00e9cid\u00e9 d'organiser un \u00e9v\u00e9nement DNS flag day 2020<\/a><\/noindex>, destin\u00e9 \u00e0 mettre l'accent sur la r\u00e9solution<\/a><\/noindex> des probl\u00e8mes<\/a><\/noindex> de la fragmentation IP lors du traitement de messages DNS de grande taille. Dans le cadre de cette initiative, pr\u00e9vu<\/a><\/noindex> il est recommand\u00e9 de fixer les tailles de tampon pour EDNS \u00e0 des valeurs ne d\u00e9passant pas 1200 octets, et \u00e9galement de rendre<\/a><\/noindex> le traitement des requ\u00eates TCP obligatoire sur les serveurs. Actuellement, le traitement des requ\u00eates UDP est obligatoire, tandis que TCP est souhaitable mais pas obligatoire pour le fonctionnement (la norme pr\u00e9voit la possibilit\u00e9 de d\u00e9sactiver TCP). Il est propos\u00e9 de supprimer de la norme l'option de d\u00e9sactivation de TCP et de normaliser le passage de l'envoi de requ\u00eates par UDP \u00e0 l'utilisation de TCP dans les cas o\u00f9 la taille de tampon EDNS \u00e9tablie est insuffisante.<\/p>\n

Les propositions dans le cadre de cette initiative de changement \u00e9limineront la confusion lors du choix de la taille du tampon EDNS et r\u00e9soudront le probl\u00e8me de la fragmentation des gros messages UDP, dont le traitement entra\u00eene souvent des pertes de paquets et des d\u00e9lais d'attente du c\u00f4t\u00e9 client. Du c\u00f4t\u00e9 client, la taille du tampon EDNS sera fixe, et les grandes r\u00e9ponses seront imm\u00e9diatement envoy\u00e9es au client via TCP. L'exception de l'envoi de gros messages via UDP permettra \u00e9galement de bloquer les attaques<\/a><\/noindex> les attaques par empoisonnement du cache DNS, bas\u00e9es sur la manipulation de paquets UDP fragment\u00e9s (dans la fragmentation, le deuxi\u00e8me fragment n'inclut pas l'en-t\u00eate avec l'identifiant, ce qui permet de falsifier suffisament pour que la somme de contr\u00f4le soit valide).<\/p>\n

Dans PowerDNS Recursor 4.2, les probl\u00e8mes li\u00e9s aux gros paquets UDP ont \u00e9t\u00e9 pris en compte, avec un passage \u00e0 l'utilisation d'une taille de tampon EDNS (edns-outgoing-bufsize) de 1232 octets, au lieu de la limite pr\u00e9c\u00e9dente de 1680 octets, ce qui devrait r\u00e9duire consid\u00e9rablement la probabilit\u00e9 de perte de paquets UDP. La valeur de 1232 a \u00e9t\u00e9 choisie car elle constitue le maximum pour lequel la taille de la r\u00e9ponse DNS, tenant compte de l'IPv6, est inf\u00e9rieure \u00e0 la valeur minimale du MTU (1280). La valeur du param\u00e8tre truncation-threshold, responsable de la coupure des r\u00e9ponses au client, a \u00e9galement \u00e9t\u00e9 r\u00e9duite \u00e0 1232.<\/p>\n

Autres modifications dans PowerDNS Recursor 4.2 :<\/p>\n