Les d\u00e9veloppeurs du serveur DNS BIND ont annonc\u00e9 l'ajout dans la branche exp\u00e9rimentale 9.17 de la prise en charge de technologies telles que \u00ab DNS sur HTTPS \u00bb (DoH, DNS over HTTPS) et DNS sur TLS (DoT, DNS over TLS), ainsi que du m\u00e9canisme XFR-over-TLS pour le transfert s\u00e9curis\u00e9 du contenu des zones DNS entre serveurs. DoH est disponible pour des tests dans la version 9.17.10, tandis que la prise en charge de DoT est pr\u00e9sente depuis la version 9.17.7. Apr\u00e8s stabilisation, la prise en charge de DoT et DoH sera r\u00e9troport\u00e9e dans la branche stable 9.16. <\/p>\n
L'impl\u00e9mentation du protocole HTTP\/2, utilis\u00e9 dans DoH, est bas\u00e9e sur l'utilisation de la biblioth\u00e8que nghttp2, qui fait partie des d\u00e9pendances de construction (\u00e0 l'avenir, la biblioth\u00e8que devrait devenir l'une des d\u00e9pendances facultatives). Des connexions \u00e0 la fois chiffr\u00e9es (TLS) et non chiffr\u00e9es via HTTP\/2 sont prises en charge. Avec les param\u00e8tres appropri\u00e9s, un processus named peut d\u00e9sormais traiter non seulement les requ\u00eates DNS traditionnelles, mais aussi les requ\u00eates envoy\u00e9es \u00e0 l'aide de DoH (DNS-over-HTTPS) et DoT (DNS-over-TLS). Le support HTTPS du c\u00f4t\u00e9 client (dig) n'est pas encore impl\u00e9ment\u00e9. Le support de XFR-over-TLS est disponible pour les requ\u00eates entrantes et sortantes. <\/p>\n
Le traitement des requ\u00eates utilisant DoH et DoT est activ\u00e9 en ajoutant les options http et tls dans la directive listen-on. Pour prendre en charge le DNS non chiffr\u00e9 sur HTTP, les param\u00e8tres doivent sp\u00e9cifier \u00ab tls none \u00bb. 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 via les options tls-port, https-port et http-port. Par exemple : tls local-tls { key-file \u00ab \/path\/to\/priv_key.pem \u00bb; cert-file \u00ab \/path\/to\/cert_chain.pem \u00bb; }; http local-http-server { endpoints { \u00ab \/dns-query \u00bb; }; }; 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, on note l'int\u00e9gration en tant que transport commun, pouvant \u00eatre utilis\u00e9 non seulement pour traiter les requ\u00eates des clients vers un r\u00e9solveur, mais aussi pour l'\u00e9change de donn\u00e9es entre serveurs, lors du transfert de zones par le serveur DNS autoritaire et pour le traitement de toutes les requ\u00eates prises en charge par d'autres transports DNS. <\/p>\n
Une autre caract\u00e9ristique est la possibilit\u00e9 de transf\u00e9rer les op\u00e9rations de chiffrement pour TLS vers un autre serveur, ce qui peut \u00eatre n\u00e9cessaire dans des situations o\u00f9 le stockage des certificats TLS est effectu\u00e9 sur un autre syst\u00e8me (par exemple, dans une infrastructure de serveurs web) et g\u00e9r\u00e9 par un autre personnel. La prise en charge de DNS-over-HTTP non chiffr\u00e9 est mise en \u0153uvre pour faciliter le d\u00e9bogage et servir de niveau pour le transfert dans un r\u00e9seau interne, sur lequel le chiffrement peut \u00eatre organis\u00e9 sur un autre serveur. Nginx peut \u00eatre utilis\u00e9 sur le serveur externe pour g\u00e9n\u00e9rer le trafic TLS, analogiquement \u00e0 la fa\u00e7on dont le HTTPS est encadr\u00e9 pour les sites. <\/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