Apr\u00e8s deux ans de d\u00e9veloppement, le consortium ISC a pr\u00e9sent\u00e9 le premier rel\u00e2chement stable de la nouvelle version majeure du serveur DNS BIND 9.18. Le support de la version 9.18 sera assur\u00e9 pendant trois ans jusqu'au deuxi\u00e8me trimestre 2025 dans le cadre d'un cycle de maintenance prolong\u00e9. Le support de la version 9.11 prendra fin en mars, et celui de la version 9.16 au milieu de l'ann\u00e9e 2023. Pour le d\u00e9veloppement des fonctionnalit\u00e9s de la prochaine version stable de BIND, une branche exp\u00e9rimentale BIND 9.19.0 a \u00e9t\u00e9 form\u00e9e. <\/p>\n
La version BIND 9.18.0 est remarquable pour la mise en \u0153uvre du support des technologies \u00ab DNS sur HTTPS \u00bb (DoH, DNS over HTTPS) et DNS sur TLS (DoT, DNS over TLS), ainsi que du m\u00e9canisme XoT (XFR-over-TLS) pour le transfert s\u00e9curis\u00e9 du contenu des zones DNS entre les serveurs (prenant en charge \u00e0 la fois l'\u00e9mission et la r\u00e9ception des zones par XoT). Avec les configurations appropri\u00e9es, un processus named peut d\u00e9sormais traiter non seulement les requ\u00eates DNS traditionnelles, mais \u00e9galement celles envoy\u00e9es via DNS-over-HTTPS et DNS-over-TLS. Le support client pour DNS-over-TLS est int\u00e9gr\u00e9 dans l'outil dig, qui peut \u00eatre utilis\u00e9 pour envoyer des requ\u00eates sur TLS en sp\u00e9cifiant le flag \u00ab +tls \u00bb. <\/p>\n
L'impl\u00e9mentation du protocole HTTP\/2, utilis\u00e9 dans DoH, repose sur la biblioth\u00e8que nghttp2, qui fait partie des d\u00e9pendances de construction facultatives. Les certificats pour DoH et DoT peuvent \u00eatre fournis par l'utilisateur ou g\u00e9n\u00e9r\u00e9s automatiquement au moment du d\u00e9marrage. <\/p>\n
Le traitement des requ\u00eates en utilisant DoH et DoT s'active en ajoutant les options \u00ab http \u00bb et \u00ab tls \u00bb dans la directive listen-on. Pour prendre en charge le DNS-over-HTTP non chiffr\u00e9, il faut sp\u00e9cifier \u00ab tls none \u00bb dans les param\u00e8tres. Les cl\u00e9s sont d\u00e9finies dans la section \u00ab tls \u00bb. Les ports r\u00e9seau standard 853 pour DoT, 443 pour DoH et 80 pour DNS-over-HTTP peuvent \u00eatre red\u00e9finis par les param\u00e8tres tls-port, https-port et http-port. Par exemple : <\/p>\n
tls local-tls { key-file '\/path\/to\/priv_key.pem'; cert-file '\/path\/to\/cert_chain.pem'; }; http local-http-server { endpoints { '\/dns-query'; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
Parmi les caract\u00e9ristiques de l'impl\u00e9mentation de DoH dans BIND, il convient de noter la possibilit\u00e9 de d\u00e9placer les op\u00e9rations de chiffrement pour TLS vers un autre serveur, ce qui peut \u00eatre n\u00e9cessaire lorsque le stockage des certificats TLS est effectu\u00e9 sur un autre syst\u00e8me (par exemple, dans une infrastructure avec des serveurs web) et g\u00e9r\u00e9 par un autre personnel. Le support DNS-over-HTTP non chiffr\u00e9 est mis en \u0153uvre pour simplifier le d\u00e9bogage et comme niveau pour le transfert vers un autre serveur dans le r\u00e9seau interne (pour d\u00e9charger le chiffrement sur un serveur distinct). Un serveur externe, tel que nginx, peut \u00eatre utilis\u00e9 pour le trafic TLS, analogiquement \u00e0 la mani\u00e8re dont le binding HTTPS pour les sites est organis\u00e9. <\/p>\n
Une autre caract\u00e9ristique est l'int\u00e9gration de DoH en tant que transport commun, qui peut \u00eatre appliqu\u00e9 non seulement pour le traitement des requ\u00eates des clients vers le r\u00e9solveur, mais aussi lors de l'\u00e9change de donn\u00e9es entre serveurs, lors du transfert de zones par les serveurs DNS autoris\u00e9s et lors du traitement de toute demande prise en charge par d'autres transports DNS. <\/p>\n
Parmi les inconv\u00e9nients, qui pourraient \u00eatre compens\u00e9s en d\u00e9sactivant la compilation avec DoH\/DoT ou en d\u00e9pla\u00e7ant le chiffrement sur un autre serveur, se distingue la complexit\u00e9 g\u00e9n\u00e9rale du code - un serveur HTTP int\u00e9gr\u00e9 et une biblioth\u00e8que TLS sont ajout\u00e9s, qui peuvent potentiellement contenir des vuln\u00e9rabilit\u00e9s et agir comme des vecteurs suppl\u00e9mentaires pour les attaques. De plus, l'utilisation de DoH augmente le trafic. <\/p>\n
Rappelons que DNS-over-HTTPS peut \u00eatre utile pour \u00e9viter les fuites d'informations concernant les noms d'h\u00f4tes demand\u00e9s par les serveurs DNS des fournisseurs, lutter contre les attaques MITM et la substitution de trafic DNS (par exemple, lorsque vous vous connectez \u00e0 un Wi-Fi public), et contrer les blocages au niveau DNS (DNS-over-HTTPS ne peut pas remplacer VPN<\/a> les m\u00e9thodes de contournement des blocages mises en \u0153uvre au niveau DPI) ou pour organiser le travail en cas d'incapacit\u00e9 \u00e0 se connecter directement aux serveurs DNS (par exemple, lors d'un travail via un proxy). Dans une situation normale, les requ\u00eates DNS sont envoy\u00e9es directement aux serveurs DNS sp\u00e9cifi\u00e9s dans la configuration du syst\u00e8me, mais dans le cas de DNS-over-HTTPS, la requ\u00eate pour la d\u00e9termination adresses IP<\/a> de l'h\u00f4te est encapsul\u00e9e dans le trafic HTTPS et envoy\u00e9e \u00e0 un serveur HTTP, sur lequel le r\u00e9solveur traite les requ\u00eates via une API Web. <\/p>\n \u00ab DNS over TLS \u00bb se distingue de \u00ab DNS over HTTPS \u00bb par l'utilisation du protocole DNS standard (g\u00e9n\u00e9ralement le port r\u00e9seau 853), encapsul\u00e9 dans un canal de communication chiffr\u00e9 \u00e9tabli par le protocole TLS avec v\u00e9rification de la validit\u00e9 de l'h\u00f4te \u00e0 travers des certificats TLS\/SSL sign\u00e9s par une autorit\u00e9 de certification. Le standard DNSSEC existant utilise le chiffrement uniquement pour l'authentification du client et du serveur, mais ne prot\u00e8ge pas le trafic contre l'interception et ne garantit pas la confidentialit\u00e9 des requ\u00eates. <\/p>\n Quelques autres nouveaut\u00e9s : <\/p>\n\n