10. Considérations opérationnelles (Operational Considerations)
Les considérations opérationnelles de DoH concernent à la fois les clients et les serveurs.
Considérations pour les opérateurs de serveurs :
Les serveurs DoH doivent généralement gérer une surcharge de connexion plus importante que les serveurs DNS traditionnels, car chaque connexion HTTPS nécessite une négociation TLS (TLS handshake). Les opérateurs de serveurs devraient être prêts à gérer cette surcharge accrue et devraient envisager d'utiliser la reprise de session TLS (TLS session resumption) et d'autres techniques d'optimisation pour réduire la surcharge.
Les serveurs DoH peuvent observer des modèles de trafic différents de la part des clients, en particulier si les clients utilisent le multiplexage de connexion HTTP/2. Les serveurs devraient être conçus pour gérer efficacement ces modèles.
Les opérateurs de serveurs DoH doivent être conscients que l'exploitation d'un serveur DoH peut les exposer à la censure ou à la surveillance. Dans certaines juridictions, il peut être nécessaire de se conformer aux exigences de conservation des données ou de surveillance. Les opérateurs de serveurs devraient connaître les exigences légales qui leur sont applicables.
Les serveurs DoH devraient implémenter une surveillance et une journalisation appropriées pour pouvoir diagnostiquer les problèmes et identifier les attaques. Cependant, comme indiqué à la section 8, la journalisation devrait être effectuée dans le respect de la vie privée des utilisateurs.
Les serveurs DoH peuvent souhaiter implémenter une limitation de débit ou d'autres formes de prévention des abus. Cela peut être plus complexe dans un environnement DoH que dans le DNS traditionnel, car les clients peuvent partager des adresses IP (par exemple, derrière un NAT) ou utiliser plusieurs connexions.
Considérations pour les opérateurs de clients :
Les clients DoH doivent être configurés avec un ou plusieurs serveurs DoH. Cette configuration peut être manuelle ou automatique. Les mécanismes de configuration automatique (par exemple via DHCP) sont encore en cours de développement et peuvent ne pas être disponibles dans tous les environnements.
Les clients DoH devraient réfléchir à la manière de gérer les situations où le serveur DoH est indisponible. Les options incluent le repli vers le DNS traditionnel, l'essai d'un serveur DoH alternatif ou l'échec complet. Le choix correct dépend de l'application et de l'environnement.
Les clients DoH peuvent avoir besoin de gérer les environnements « DNS divisé » (split DNS), où certains noms de domaine doivent être résolus via le serveur DNS local, tandis que d'autres doivent être résolus via DoH. Cela nécessite une configuration et une gestion des politiques appropriées.
L'utilisation de DoH peut augmenter la latence des requêtes DNS, en particulier pour la première requête nécessitant l'établissement d'une nouvelle connexion HTTPS. Les clients devraient envisager d'utiliser des connexions persistantes et des techniques de pré-établissement de connexion pour réduire cette latence.
Les clients DoH devraient être prêts à gérer les redirections HTTP et autres fonctionnalités HTTP. Bien que les redirections soient autorisées dans DoH, les clients devraient faire attention à éviter les boucles de redirection et autres problèmes potentiels.
Considérations pour les opérateurs réseau :
Les opérateurs réseau doivent être conscients que le trafic DoH ressemble au trafic HTTPS ordinaire et peut être difficile à identifier et à distinguer. Cela peut affecter la surveillance du réseau et le dépannage.
Certains réseaux peuvent s'appuyer sur le DNS pour l'application des politiques, tels que le contrôle parental ou le filtrage des logiciels malveillants. L'utilisation de DoH peut contourner ces contrôles. Les opérateurs réseau peuvent souhaiter déployer leurs propres serveurs DoH ou utiliser d'autres méthodes pour appliquer les politiques.
Les réseaux d'entreprise peuvent souhaiter contrôler quels serveurs DoH leurs utilisateurs peuvent utiliser. Cela peut être réalisé via des politiques réseau, des configurations de périphériques ou d'autres mécanismes.
DoH peut affecter certaines techniques d'optimisation réseau, telles que les proxys de cache DNS. Les opérateurs réseau devraient tenir compte de ces implications et peuvent avoir besoin d'ajuster leur infrastructure.
Considérations pour les réseaux de distribution de contenu (CDN) :
De nombreux CDN s'appuient sur la géolocalisation basée sur le DNS pour diriger les utilisateurs vers le serveur le plus proche. Lors de l'utilisation de DoH, les requêtes DNS peuvent provenir du serveur DoH plutôt que de l'utilisateur final, ce qui peut affecter la précision de la géolocalisation.
EDNS Client Subnet (ECS) [RFC7871] peut être utilisé avec DoH pour atténuer ce problème, mais cela introduit des compromis en matière de vie privée. Les serveurs et clients DoH devraient soigneusement réfléchir à l'opportunité d'utiliser ECS et à la manière de l'utiliser.
Considérations d'interopérabilité :
Les clients et serveurs DoH devraient prendre en charge la négociation de contenu pour permettre la définition future de nouveaux formats de transport DNS. Bien que « application/dns-message » soit le format actuellement défini, d'autres formats pourront être définis à l'avenir.
Les implémentations DoH devraient interopérer avec l'infrastructure DNS existante. En particulier, les serveurs DoH transmettent généralement les requêtes aux résolveurs DNS traditionnels et devraient être capables de traiter correctement les réponses de ces résolveurs.
DoH n'exige pas l'utilisation de DNSSEC, mais les implémentations DoH devraient être capables de traiter les réponses signées DNSSEC et devraient transmettre correctement l'état de validation DNSSEC.
Considérations de transition et de déploiement :
Le déploiement de DoH peut être progressif. Les clients et serveurs devraient être conçus pour fonctionner dans des environnements mixtes DoH et DNS traditionnel.
Certaines applications peuvent souhaiter utiliser DoH, tandis que d'autres peuvent préférer le DNS traditionnel. Les systèmes d'exploitation et les bibliothèques réseau devraient fournir des mécanismes permettant cette flexibilité.
Le déploiement généralisé de DoH peut nécessiter des modifications importantes de l'infrastructure DNS existante. Les opérateurs devraient planifier ces modifications et devraient réfléchir à la manière de gérer la transition.