Les développeurs du serveur DNS BIND ont annoncé l'ajout de la prise en charge du serveur pour les technologies DNS sur HTTPS (DoH, DNS sur HTTPS) et DNS sur TLS (DoT, DNS sur TLS), ainsi que du mécanisme XFR-sur-TLS pour sécuriser transférer le contenu des zones DNS entre serveurs. DoH est disponible pour les tests dans la version 9.17 et la prise en charge de DoT est présente depuis la version 9.17.10. Après stabilisation, le support DoT et DoH sera rétroporté vers la branche stable 9.17.7.
L'implémentation du protocole HTTP/2 utilisé dans DoH repose sur l'utilisation de la bibliothèque nghttp2, qui fait partie des dépendances de l'assembly (à l'avenir, il est prévu que la bibliothèque soit transférée vers le nombre de dépendances facultatives). Les connexions HTTP/2 chiffrées (TLS) et non chiffrées sont prises en charge. Avec les paramètres appropriés, un processus nommé unique peut désormais répondre non seulement aux requêtes DNS traditionnelles, mais également aux requêtes envoyées via DoH (DNS-over-HTTPS) et DoT (DNS-over-TLS). La prise en charge HTTPS côté client (dig) n'est pas encore implémentée. La prise en charge XFR-over-TLS est disponible pour les requêtes entrantes et sortantes.
Le traitement des requêtes à l'aide de DoH et DoT est activé en ajoutant les options http et tls à la directive d'écoute. Pour prendre en charge le DNS sur HTTP non chiffré, vous devez spécifier « tls none » dans les paramètres. Les clés sont définies dans la section "tls". Les ports réseau par défaut 853 pour DoT, 443 pour DoH et 80 pour DNS-over-HTTP peuvent être remplacés via les paramètres tls-port, https-port et http-port. Par exemple : tls local-tls { fichier-clé "/path/to/priv_key.pem" ; fichier de certificat "/path/to/cert_chain.pem" ; } ; http local-http-server { points de terminaison { "/dns-query" ; } ; } ; options { port https 443 ; port d'écoute 443 tls local-tls http mon serveur {any;} ; }
Parmi les fonctionnalités de l'implémentation DoH dans BIND, l'intégration est notée comme un transport général, qui peut être utilisé non seulement pour traiter les requêtes des clients vers le résolveur, mais également lors de l'échange de données entre serveurs, lors du transfert de zones par un serveur DNS faisant autorité, et lors du traitement de toute demande prise en charge par d'autres transports DNS.
Une autre fonctionnalité est la possibilité de déplacer les opérations de chiffrement pour TLS vers un autre serveur, ce qui peut être nécessaire dans des conditions où les certificats TLS sont stockés sur un autre système (par exemple, dans une infrastructure avec des serveurs Web) et gérés par d'autres personnels. La prise en charge du DNS sur HTTP non chiffré est implémentée pour simplifier le débogage et comme couche de transfert dans le réseau interne, sur la base de laquelle le cryptage peut être organisé sur un autre serveur. Sur un serveur distant, nginx peut être utilisé pour générer du trafic TLS, de la même manière que la liaison HTTPS est organisée pour les sites Web.
Rappelons que DNS-over-HTTPS peut être utile pour empêcher les fuites d'informations sur les noms d'hôtes demandés via les serveurs DNS des fournisseurs, lutter contre les attaques MITM et l'usurpation du trafic DNS (par exemple, lors de la connexion au Wi-Fi public), contrer le blocage au niveau DNS (le DNS sur HTTPS ne peut pas remplacer un VPN pour contourner le blocage mis en œuvre au niveau DPI) ou pour organiser le travail lorsqu'il est impossible d'accéder directement aux serveurs DNS (par exemple, lorsque l'on travaille via un proxy). Si, dans une situation normale, les requêtes DNS sont directement envoyées aux serveurs DNS définis dans la configuration du système, alors dans le cas du DNS sur HTTPS, la requête visant à déterminer l'adresse IP de l'hôte est encapsulée dans le trafic HTTPS et envoyée au serveur HTTP, où le résolveur traite les requêtes via l'API Web.
« DNS sur TLS » diffère de « DNS sur HTTPS » par l'utilisation du protocole DNS standard (le port réseau 853 est généralement utilisé), enveloppé dans un canal de communication crypté organisé à l'aide du protocole TLS avec vérification de la validité de l'hôte via des certificats TLS/SSL certifiés. par une autorité de certification. La norme DNSSEC existante utilise le cryptage uniquement pour authentifier le client et le serveur, mais ne protège pas le trafic contre l'interception et ne garantit pas la confidentialité des demandes.
Source: opennet.ru