9. Considérations de sécurité (Security Considerations)

Lors de l'exécution de requêtes DNS via DoH, les considérations de sécurité s'appliquent à la fois au DNS et à HTTPS.

L'utilisation de HTTPS offre une protection contre les attaquants passifs qui pourraient tenter d'observer les requêtes et réponses DNS. Elle offre également une protection contre certains types d'attaques actives, telles que les attaquants tentant de falsifier les réponses DNS.

Cependant, DoH ne peut pas prévenir tous les types d'attaques. En particulier, il ne peut pas prévenir les attaques contre le serveur DoH lui-même. Si le serveur DoH est contrôlé par un attaquant ou influencé par celui-ci, l'attaquant peut fournir de fausses réponses DNS. Par conséquent, le choix d'un serveur DoH de confiance est crucial.

Les clients DoH DOIVENT (MUST) utiliser les mécanismes décrits dans [RFC2818] et [RFC6125] pour valider le certificat TLS du serveur DoH. Si la validation du certificat échoue, le client NE DOIT PAS (MUST NOT) utiliser ce serveur pour les requêtes DNS.

DoH utilise HTTPS, ce qui signifie qu'il utilise TLS pour la sécurité du transport. Les considérations de sécurité de [RFC8446] s'appliquent à DoH. En particulier, les implémentations DoH devraient utiliser TLS 1.3 ou une version ultérieure, et devraient suivre les recommandations de sécurité de [RFC8446].

Les serveurs DoH DEVRAIENT (SHOULD) utiliser HTTP/2 [RFC7540] ou une version ultérieure, car ces versions offrent de meilleures performances et des fonctionnalités de sécurité améliorées. Si HTTP/2 est utilisé, les considérations de sécurité de [RFC7540] s'appliquent.

Les extensions de sécurité DNS (DNSSEC) [RFC4033] peuvent être utilisées avec DoH pour fournir une protection de sécurité supplémentaire. DNSSEC fournit l'authentification de la source des données et l'intégrité des données, ce qui peut prévenir certains types d'attaques, même si le serveur DoH lui-même est compromis. Cependant, DNSSEC ne peut pas empêcher un serveur DoH de simplement refuser de fournir des signatures DNSSEC valides ou de fournir des réponses non signées.

Les clients et serveurs DoH devraient tous deux implémenter une limitation de débit (rate limiting) appropriée pour prévenir les attaques par déni de service (DoS). Parce que DoH utilise HTTPS, il peut être plus difficile à attaquer par DDoS que le DNS traditionnel, mais il reste vulnérable à certains types d'attaques, en particulier celles ciblant l'infrastructure HTTP.

Les serveurs DoH peuvent choisir d'exiger une authentification du client. Dans ce cas, le serveur devrait utiliser des mécanismes d'authentification appropriés, tels que les certificats TLS côté client ou l'authentification HTTP. Cependant, l'exigence d'authentification peut affecter la vie privée du client (voir section 8).

DoH ne modifie pas la sémantique des réponses DNS. En particulier, les réponses DoH devraient avoir la même signification que les réponses reçues via le transport DNS traditionnel. Les serveurs DoH NE DEVRAIENT PAS (SHOULD NOT) modifier le contenu des réponses DNS, sauf s'il existe une raison explicite de le faire (par exemple, filtrer les noms de domaine malveillants selon une politique locale).

Certains réseaux peuvent déployer des proxys DNS transparents ou des intercepteurs. Ces dispositifs peuvent tenter d'intercepter ou de modifier le trafic DNS. L'utilisation de DoH peut contourner ces dispositifs, ce qui peut être considéré comme une fonctionnalité ou un défaut selon le point de vue. Les opérateurs réseau doivent être conscients que DoH peut affecter leur capacité à surveiller et contrôler le trafic DNS.

DoH peut affecter l'efficacité de certains dispositifs et services de sécurité, tels que les filtres anti-malware basés sur DNS. Les organisations devraient tenir compte de ces implications et peuvent avoir besoin de déployer leurs propres serveurs DoH ou d'utiliser des dispositifs de sécurité capables d'inspecter le trafic DoH.

Parce que les requêtes et réponses DoH sont transmises sur le même port (443) que le trafic HTTPS ordinaire, elles peuvent être plus difficiles à distinguer et à filtrer. Cela peut rendre plus difficile pour les opérateurs réseau l'application de politiques basées sur le DNS.

Les clients DoH DEVRAIENT (SHOULD) implémenter des mécanismes de délai d'attente (timeout) pour éviter d'attendre trop longtemps une réponse. Cela peut aider à prévenir certains types d'attaques DoS où un attaquant tente de faire attendre le client pendant une longue période.

Les serveurs DoH DEVRAIENT (SHOULD) valider la bonne formation des requêtes DNS reçues et devraient rejeter les requêtes mal formées. Cela peut aider à prévenir certains types d'attaques, telles que les tentatives d'exploitation de vulnérabilités dans les résolveurs DNS.

Enfin, il convient de noter que DoH n'est qu'une méthode parmi d'autres pour sécuriser le DNS. D'autres méthodes incluent DNS over TLS (DoT) [RFC7858] et DNS over QUIC (DoQ) [RFC9250]. Chaque méthode a ses propres avantages et inconvénients, et les organisations devraient choisir la méthode la plus appropriée en fonction de leurs besoins spécifiques. Dans certains cas, il peut être nécessaire de prendre en charge plusieurs méthodes pour offrir un maximum de flexibilité et de compatibilité.