Le serveur DNS BIND a ajouté le support expérimental de DNS-over-HTTPS

Les développeurs du serveur DNS BIND ont annoncé l'ajout dans la branche expérimentale 9.17 de la prise en charge serveur des technologies « DNS sur HTTPS » (DoH, DNS over HTTPS) et DNS sur TLS (DoT, DNS over TLS), ainsi qu'un mécanisme XFR-over-TLS pour le transfert sécurisé du contenu des zones DNS entre serveurs. DoH est disponible pour test dans la version 9.17.10, et le support de DoT est présent depuis la version 9.17.7. Une fois stabilisé, le support de DoT et DoH sera rétro-porté dans la branche stable 9.16.

L'implémentation du protocole HTTP/2, utilisé dans DoH, est basée sur l'utilisation de la bibliothèque nghttp2, qui fait partie des dépendances de construction (à l'avenir, la bibliothèque devrait devenir l'une des dépendances facultatives). Des connexions à la fois chiffrées (TLS) et non chiffrées via HTTP/2 sont prises en charge. Avec les paramètres appropriés, un processus named peut désormais traiter non seulement les requêtes DNS traditionnelles, mais aussi les requêtes envoyées à l'aide de DoH (DNS-over-HTTPS) et DoT (DNS-over-TLS). Le support HTTPS du côté client (dig) n'est pas encore implémenté. Le support de XFR-over-TLS est disponible pour les requêtes entrantes et sortantes.

Le traitement des requêtes utilisant DoH et DoT s'active en ajoutant les options http et tls dans la directive listen-on. Pour prendre en charge DNS-over-HTTP non chiffré, il faut spécifier « tls none » dans les paramètres. Les clés sont définies dans la section « tls ». Les ports réseau standard 853 pour DoT, 443 pour DoH et 80 pour DNS-over-HTTP peuvent être redéfinis via les paramètres tls-port, https-port et http-port. Par exemple : 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;}; }

Parmi les caractéristiques de l'implémentation de DoH dans BIND, on note l'intégration en tant que transport commun, pouvant être utilisé non seulement pour traiter les requêtes des clients vers un résolveur, mais aussi pour l'échange de données entre serveurs, lors du transfert de zones par le serveur DNS autoritaire et pour le traitement de toutes les requêtes prises en charge par d'autres transports DNS.

Une autre caractéristique est la possibilité de transférer les opérations de chiffrement pour TLS vers un autre serveur, ce qui peut être nécessaire dans des situations où le stockage des certificats TLS est effectué sur un autre système (par exemple, dans une infrastructure de serveurs web) et géré par un autre personnel. La prise en charge de DNS-over-HTTP non chiffré est mise en œuvre pour faciliter le débogage et servir de niveau pour le transfert dans un réseau interne, sur lequel le chiffrement peut être organisé sur un autre serveur. Nginx peut être utilisé sur le serveur externe pour générer le trafic TLS, analogiquement à la façon dont le HTTPS est encadré pour les sites.

Rappelons que DNS-over-HTTPS peut être utile pour éviter les fuites d'informations concernant les noms d'hôtes demandés par les serveurs DNS des fournisseurs, lutter contre les attaques MITM et la substitution de trafic DNS (par exemple, lorsque vous vous connectez à un Wi-Fi public), et contrer les blocages au niveau DNS (DNS-over-HTTPS ne peut pas remplacer VPN les méthodes de contournement des blocages mises en œuvre au niveau DPI) ou pour organiser le travail en cas d'incapacité à se connecter directement aux serveurs DNS (par exemple, lors d'un travail via un proxy). Dans une situation normale, les requêtes DNS sont envoyées directement aux serveurs DNS spécifiés dans la configuration du système, mais dans le cas de DNS-over-HTTPS, la requête pour la détermination adresses IP de l'hôte est encapsulée dans le trafic HTTPS et envoyée à un serveur HTTP, sur lequel le résolveur traite les requêtes via une API Web.

"DNS over TLS" se distingue de "DNS over HTTPS" par l'utilisation du protocole DNS standard (utilisant généralement le port réseau 853), encapsulé dans un canal de communication chiffré organisé par le protocole TLS, avec vérification de la validité de l'hôte à travers des certificats TLS/SSL signés par une autorité de certification. La norme DNSSEC existante utilise le chiffrement uniquement pour l'authentification du client et du serveur, mais ne protège pas le trafic contre l'interception et ne garantit pas la confidentialité des requêtes.

Source : opennet.ru