Sortie du serveur DNS BIND 9.18.0 avec prise en charge de DNS-over-TLS et de DNS-over-HTTPS

Après deux ans de développement, le consortium ISC a présenté le premier relâchement stable de la nouvelle version majeure du serveur DNS BIND 9.18. Le support de la version 9.18 sera assuré pendant trois ans jusqu'au deuxième trimestre 2025 dans le cadre d'un cycle de maintenance prolongé. Le support de la version 9.11 prendra fin en mars, et celui de la version 9.16 au milieu de l'année 2023. Pour le développement des fonctionnalités de la prochaine version stable de BIND, une branche expérimentale BIND 9.19.0 a été formée.

La sortie de BIND 9.18.0 se distingue par la mise en œuvre du support des technologies « DNS over HTTPS » (DoH, DNS sur HTTPS) et DNS over TLS (DoT, DNS sur TLS), ainsi que du mécanisme XoT (XFR-over-TLS) pour le transfert sécurisé du contenu des zones DNS entre les serveurs (supporté à la fois pour l'envoi et la réception de zones via XoT). Avec les configurations appropriées, un processus nommé peut désormais traiter non seulement des requêtes DNS traditionnelles, mais aussi des requêtes envoyées via DNS-over-HTTPS et DNS-over-TLS. Le support client pour DNS-over-TLS est intégré dans l'utilitaire dig, qui peut être utilisé pour envoyer des requêtes via TLS en spécifiant le drapeau « +tls ».

L'implémentation du protocole HTTP/2, utilisé dans DoH, repose sur la bibliothèque nghttp2, qui fait partie des dépendances de construction facultatives. Les certificats pour DoH et DoT peuvent être fournis par l'utilisateur ou générés automatiquement au moment du démarrage.

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 le DNS sur HTTP non chiffré, il faut spécifier « tls none » dans les configurations. Les clés sont définies dans la section « tls ». Les ports réseau standards 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, il convient de noter la possibilité de déplacer les opérations de chiffrement pour TLS vers un autre serveur, ce qui peut être nécessaire lorsque le stockage des certificats TLS est effectué sur un autre système (par exemple, dans une infrastructure avec des serveurs web) et géré par un autre personnel. Le support DNS-over-HTTP non chiffré est mis en œuvre pour simplifier le débogage et comme niveau pour le transfert vers un autre serveur dans le réseau interne (pour décharger le chiffrement sur un serveur distinct). Un serveur externe, tel que nginx, peut être utilisé pour le trafic TLS, analogiquement à la manière dont le binding HTTPS pour les sites est organisé.

Une autre caractéristique est l'intégration de DoH en tant que transport commun, qui peut être appliqué non seulement pour le traitement des requêtes des clients vers le résolveur, mais aussi lors de l'échange de données entre serveurs, lors du transfert de zones par les serveurs DNS autorisés et lors du traitement de toute demande prise en charge par d'autres transports DNS.

Les inconvénients, qui peuvent être compensés par la désactivation de la compilation avec DoH/DoT ou le déplacement du chiffrement vers un autre serveur, comprennent la complexité générale du code — l'ajout d'un serveur HTTP intégré et d'une bibliothèque TLS, qui peuvent potentiellement contenir des vulnérabilités et devenir des vecteurs d'attaque supplémentaires. De plus, l'utilisation de DoH augmente le trafic.

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.

Quelques autres nouveautés :

• Des paramètres tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer et udp-send-buffer ont été ajoutés pour définir les tailles des tampons utilisés lors de l'envoi et de la réception de requêtes par TCP et UDP. Sur les serveurs chargés, l'augmentation des tampons entrants permettra d'éviter la perte de paquets pendant les pics de trafic, tandis que la réduction aidera à éviter l'encombrement de la mémoire par des requêtes anciennes.
• Une nouvelle catégorie de logs «rpz-passthru» a été ajoutée, permettant de journaliser séparément les actions de transfert des RPZ (Response Policy Zones).
• Dans la section response-policy, une option «nsdname-wait-recurse» a été ajoutée, qui, lorsqu'elle est définie sur «no», applique les règles RPZ NSDNAME uniquement si des serveurs de noms autorisés présents dans le cache sont trouvés pour la requête ; sinon, la règle RPZ NSDNAME est ignorée, mais les informations sont extraites en arrière-plan et appliquées aux requêtes suivantes.
• Pour les enregistrements de types HTTPS et SVCB, le traitement de la section «ADDITIONAL» a été mis en œuvre.
• Des types de règles update-policy personnalisées — krb5-subdomain-self-rhs et ms-subdomain-self-rhs — ont été ajoutés, permettant de restreindre la mise à jour des enregistrements SRV et PTR. Dans les blocs update-policy, il est désormais possible de définir des limites sur le nombre d'enregistrements, spécifiques à chaque type.
• La sortie de l'utilitaire dig a été enrichie d'informations sur le protocole de transport (UDP, TCP, TLS, HTTPS) et les préfixes DNS64. Pour les besoins de débogage, dig a été modifié pour permettre la spécification d'un identifiant de requête spécifique (dig +qid=).
• La prise en charge de la bibliothèque OpenSSL 3.0 a été ajoutée.
• Pour résoudre les problèmes de fragmentation IP lors du traitement des messages DNS de grande taille, comme indiqué par l'initiative DNS Flag Day 2020, le code responsable de l'ajustement de la taille du tampon EDNS a été supprimé du résolveur en l'absence de réponse à la requête. La taille du tampon EDNS est désormais fixée de manière constante (edns-udp-size) pour toutes les requêtes sortantes.
• Le système de construction a été mis à jour pour utiliser le trio autoconf, automake et libtool.
• La prise en charge des fichiers de zone au format « map » (masterfile-format map) a été abandonnée. Les utilisateurs de ce format sont invités à convertir leurs zones au format raw à l'aide de l'utilitaire named-compilezone.
• La prise en charge des anciens pilotes DLZ (Dynamically Loadable Zones) a été abandonnée, remplacée par des modules DLZ.
• La construction et l'exécution pour la plateforme Windows ont été abandonnées. La dernière version pouvant être installée sous Windows reste BIND 9.16.

Source : opennet.ru