Après deux ans de développement, le consortium ISC a publié la première version stable d'une nouvelle branche majeure du serveur DNS BIND 9.18. Le support de la branche 9.18 sera fourni pendant trois ans jusqu'au 2ème trimestre 2025 dans le cadre d'un cycle de support étendu. Le support de la branche 9.11 prendra fin en mars et celui de la branche 9.16 à la mi-2023. Pour développer les fonctionnalités de la prochaine version stable de BIND, une branche expérimentale BIND 9.19.0 a été créée.
La version BIND 9.18.0 se distingue par la mise en œuvre de la prise en charge du DNS sur HTTPS (DoH, DNS sur HTTPS) et du DNS sur TLS (DoT, DNS sur TLS), ainsi que du mécanisme XoT (XFR-over-TLS). pour le transfert sécurisé du contenu DNS.zones entre serveurs (les zones d'envoi et de réception via XoT 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 DNS-over-HTTPS et DNS-over-TLS. La prise en charge client pour DNS-over-TLS est intégrée à l'utilitaire dig, qui peut être utilisé pour envoyer des requêtes via TLS lorsque l'indicateur « +tls » est spécifié.
L'implémentation du protocole HTTP/2 utilisé dans DoH est basée sur l'utilisation de la bibliothèque nghttp2, qui est incluse en tant que dépendance d'assembly facultative. 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 à 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;} ; }
L'une des fonctionnalités de l'implémentation DoH dans BIND 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 maintenus. 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 vers un autre serveur du réseau interne (pour déplacer le chiffrement vers un serveur distinct). 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.
Une autre fonctionnalité est l'intégration de DoH en tant que transport général qui peut être utilisé non seulement pour gérer les requêtes des clients vers le résolveur, mais également lors de la communication entre serveurs, lors du transfert de zones par un serveur DNS faisant autorité et lors du traitement de requêtes prises en charge par d'autres DNS. les transports.
Parmi les défauts qui peuvent être compensés en désactivant la construction avec DoH/DoT ou en déplaçant le cryptage vers un autre serveur, la complication générale de la base de code se démarque - un serveur HTTP intégré et une bibliothèque TLS sont ajoutés, qui pourraient potentiellement contenir vulnérabilités et agissent comme des vecteurs supplémentaires d’attaques. De plus, lors de l’utilisation de DoH, le trafic augmente.
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.
Quelques autres nouveautés :
- Ajout des paramètres tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer et udp-send-buffer pour définir la taille des tampons utilisés lors de l'envoi et de la réception de requêtes via TCP et UDP. Sur les serveurs occupés, l'augmentation des tampons entrants aidera à éviter l'abandon de paquets lors des pics de trafic, et leur diminution aidera à éliminer l'encombrement de la mémoire avec les anciennes requêtes.
- Une nouvelle catégorie de journal « rpz-passthru » a été ajoutée, qui vous permet de consigner séparément les actions de transfert RPZ (Response Policy Zones).
- Dans la section réponse-politique, l'option "nsdname-wait-recurse" a été ajoutée, lorsqu'elle est définie sur "no", les règles RPZ NSDNAME ne sont appliquées que si des serveurs de noms faisant autorité présents dans le cache sont trouvés pour la requête, sinon le La règle RPZ NSDNAME est ignorée, mais les informations sont récupérées en arrière-plan et s'appliquent aux requêtes ultérieures.
- Pour les enregistrements de type HTTPS et SVCB, le traitement de la section « ADDITIONAL » a été implémenté.
- Ajout de types de règles de stratégie de mise à jour personnalisées - krb5-subdomain-self-rhs et ms-subdomain-self-rhs, qui vous permettent de limiter la mise à jour des enregistrements SRV et PTR. Les blocs de stratégie de mise à jour ajoutent également la possibilité de définir des limites sur le nombre d'enregistrements, individuelles pour chaque type.
- Ajout d'informations sur le protocole de transport (UDP, TCP, TLS, HTTPS) et les préfixes DNS64 à la sortie de l'utilitaire dig. À des fins de débogage, dig a ajouté la possibilité de spécifier un identifiant de requête spécifique (dig +qid= ).
- Ajout de la prise en charge de la bibliothèque OpenSSL 3.0.
- Pour résoudre les problèmes de fragmentation IP lors du traitement de messages DNS volumineux identifiés par le DNS Flag Day 2020, le code qui ajuste la taille du tampon EDNS lorsqu'il n'y a pas de réponse à une requête a été supprimé du résolveur. La taille du tampon EDNS est désormais définie sur constante (edns-udp-size) pour toutes les requêtes sortantes.
- Le système de construction a été basculé vers une combinaison d'autoconf, automake et libtool.
- La prise en charge des fichiers de zone au format « map » (carte au format masterfile) a été interrompue. Il est recommandé aux utilisateurs de ce format de convertir les zones au format brut à l'aide de l'utilitaire nommé-compilezone.
- La prise en charge des anciens pilotes DLZ (Dynamically Loadable Zones) a été interrompue et remplacée par des modules DLZ.
- La prise en charge de la génération et de l'exécution pour la plate-forme Windows a été interrompue. La dernière branche pouvant être installée sur Windows est BIND 9.16.
Source: opennet.ru