12. Security Considerations (Considérations de sécurité)
Ce document présente les extensions de sécurité DNS et décrit l'ensemble de documents qui contient les nouveaux enregistrements de sécurité et les modifications du protocole DNS. Les extensions fournissent l'authentification de l'origine des données et l'intégrité des données en utilisant des signatures numériques sur des ensembles d'enregistrements de ressources. Cette section discute des limitations de ces extensions.
Pour qu'un résolveur conscient de la sécurité valide une réponse DNS, toutes les zones le long du chemin depuis le point de départ de confiance jusqu'à la zone contenant les zones de réponse doivent être signées, et tous les serveurs de noms et résolveurs impliqués dans le processus de résolution doivent être conscients de la sécurité, comme défini dans cet ensemble de documents. Un résolveur conscient de la sécurité ne peut pas vérifier les réponses provenant d'une zone non signée, d'une zone non servie par un serveur de noms conscient de la sécurité, ou pour toute donnée DNS que le résolveur ne peut obtenir que via un serveur de noms récursif qui n'est pas conscient de la sécurité. S'il y a une rupture dans la chaîne d'authentification telle qu'un résolveur conscient de la sécurité ne peut pas obtenir et valider les clés d'authentification dont il a besoin, alors le résolveur conscient de la sécurité ne peut pas valider les données DNS affectées.
Ce document discute brièvement d'autres méthodes pour ajouter de la sécurité à une requête DNS, telles que l'utilisation d'un canal sécurisé par IPsec ou l'utilisation d'un mécanisme d'authentification de transaction DNS tel que TSIG ([RFC2845]) ou SIG(0) ([RFC2931]), mais la sécurité des transactions ne fait pas partie de DNSSEC en soi.
Un résolveur stub conscient de la sécurité non validant, par définition, n'effectue pas lui-même de validation de signature DNSSEC et est donc vulnérable à la fois aux attaques sur (et par) les serveurs de noms récursifs conscients de la sécurité qui effectuent ces vérifications en son nom et aux attaques sur sa communication avec ces serveurs de noms récursifs conscients de la sécurité. Les résolveurs stub conscients de la sécurité non validants doivent utiliser une forme de sécurité de canal pour se défendre contre cette dernière menace. La seule défense connue contre la première menace serait que le résolveur stub conscient de la sécurité effectue sa propre validation de signature, auquel cas, encore une fois par définition, il ne serait plus un résolveur stub conscient de la sécurité non validant.
DNSSEC ne protège pas contre les attaques par déni de service. DNSSEC rend DNS vulnérable à une nouvelle classe d'attaques par déni de service basées sur des opérations cryptographiques contre les résolveurs conscients de la sécurité et les serveurs de noms conscients de la sécurité, car un attaquant peut tenter d'utiliser les mécanismes DNSSEC pour consommer les ressources d'une victime. Cette classe d'attaques prend au moins deux formes. Un attaquant peut être capable de consommer des ressources dans le code de validation de signature d'un résolveur conscient de la sécurité en altérant les RR RRSIG dans les messages de réponse ou en construisant des chaînes de signature inutilement complexes. Un attaquant peut également être capable de consommer des ressources dans un serveur de noms conscient de la sécurité qui prend en charge la mise à jour dynamique DNS, en envoyant un flux de messages de mise à jour qui forcent le serveur de noms conscient de la sécurité à re-signer certains RRset dans la zone plus fréquemment que cela ne serait autrement nécessaire.
En raison d'un choix de conception délibéré, DNSSEC ne fournit pas de confidentialité.
DNSSEC introduit la capacité pour une partie hostile d'énumérer tous les noms dans une zone en suivant la chaîne NSEC. Les RR NSEC affirment quels noms n'existent pas dans une zone en reliant de nom existant à nom existant le long d'un ordre canonique de tous les noms dans une zone. Ainsi, un attaquant peut interroger ces RR NSEC en séquence pour obtenir tous les noms dans une zone. Bien que ce ne soit pas une attaque sur le DNS lui-même, cela pourrait permettre à un attaquant de cartographier les hôtes réseau ou d'autres ressources en énumérant le contenu d'une zone.
DNSSEC introduit une complexité supplémentaire significative au DNS et introduit donc de nombreuses nouvelles opportunités pour les bugs d'implémentation et les zones mal configurées. En particulier, activer la validation de signature DNSSEC dans un résolveur peut rendre des zones légitimes entières effectivement inaccessibles en raison d'erreurs de configuration DNSSEC ou de bugs.
DNSSEC ne protège pas contre l'altération des données de zone non signées. Les données non autoritaires aux coupures de zone (enregistrements glue et NS dans la zone parent) ne sont pas signées. Cela ne pose pas de problème lors de la validation de la chaîne d'authentification, mais cela signifie que les données non autoritaires elles-mêmes sont vulnérables à l'altération pendant les opérations de transfert de zone. Ainsi, bien que DNSSEC puisse fournir l'authentification de l'origine des données et l'intégrité des données pour les RRset, il ne peut pas le faire pour les zones, et d'autres mécanismes (tels que TSIG, SIG(0) ou IPsec) doivent être utilisés pour protéger les opérations de transfert de zone.
Veuillez consulter [RFC4034] et [RFC4035] pour des considérations de sécurité supplémentaires.