Revision as of 00:45, 31 January 2006

Découverte de la liste de serveurs DNS récursifs

Table des matières

Supports de transmission

La résolution DNS classique est optimisée grâce à l'introduction, d'entités intermédiaires : les serveurs récursifs ou caches. En effet, lorsqu'un client DNS soumet une requête à un serveur récursif, ce dernier se charge de la relayer à une chaîne de serveurs mieux renseignés que lui et de rechercher, de proche en proche, la réponse à la requête en question.Cette chaîne commence généralement par un serveur racine et se termine par un serveur autoritaire (primaire ou secondaire) sur la zone contenant le nom de domaine objet de la requête en question.

Le serveur maintient alors cette réponse dans son cache, pendant une durée de vie donnée (TTL : Time To Live). Le TTL est configurable selon la fréquence de changement des informations dans la zone concernée et il est généralement compris entre quelques dizaines de minutes et quelques jours. Si un client envoie une requête pour laquelle la réponse est encore dans le cache avant l'expiration de sa durée de vie, le serveur cache restitue alors cette réponse au client sans avoir à refaire l'interrogation de toute la chaîne de serveurs qui l'y a conduit. Par conséquent, le client prend le risque que la ressource qu'il vient tout juste de récupérer soit, dans le même temps, déjà modifiée sur les serveurs autoritaires sur la zone DNS contenant la ressource en question. Autrement dit, le TTL est une source potentielle d'incohérence des ressources DNS entre les serveurs autoritaires et les serveurs cache.

Ce risque d'incohérence existe également entre les serveurs autoritaires eux-mêmes. En effet, pour une zone DNS donnée, chaque serveur secondaire se sert du paramètre refresh figurant dans l'enregistrement SOA de la zone en question. Il spécifie le délai entre deux synchronisations et vaut souvent plusieurs heures de cette zone.

En cas de mise à jour récente sur le serveur primaire, le rafraîchissement de la zone en question, sur les serveurs secondaires, s'impose. Par conséquent, un serveur récursif n'est en fait jamais sûr de la pertinence de l'information qu'il récupère car celle-ci risque de provenir d'un serveur secondaire mal synchronisé. Afin de pallier ce dernier problème d'incohérence entre serveurs autoritaires, deux extensions DNS ont été spécifiées :

• Notification (RFC 1996) (NOTIFY) et
• Transfert incrémental (RFC 1995) (IXFR).

Ces deux protocoles permettent de faciliter et d'accélérer la synchronisation des zones DNS hébergées par les serveurs secondaires. Le protocole de notification est utilisé par un serveur DNS primaire pour informer ses serveurs secondaires qu'une zone a été modifiée. Les serveurs secondaires peuvent alors récupérer la nouvelle zone immédiatement, sans attendre le délai normal de synchronisation (donné par le paramètre « refresh »). Le protocole de transfert incrémental est utilisé pour optimiser le volume de l'échange entre serveur primaire et secondaire : si les modifications d'une zone sont faibles, on transfère seulement ces modifications et non la zone complète.

En dépit des palliatifs NOTIFY et IXFR, le mécanisme classique de résolution DNS reste inadapté aux réseaux dans lesquels les équipements sont susceptibles de changer d'adresse(s) très fréquemment et s'attendent de surcroît à être immédiatement contactés sur leur(s) nouvelle(s) adresse(s). Ainsi, il est devenu nécessaire, il y a quelques années, d'étendre les fonctionnalités du DNS afin qu'il puisse suivre et restituer en temps réel l'évolution des adresses des équipements dans les environnements dynamiques. De telles fonctionnalités sont, bien entendu, indépendantes de la version d'IP même si l'autoconfiguration dans IPv6 ne fait qu'accentuer ce besoin.

L'IETF a proposé une solution au problème de mise à jour dynamique du DNS dans le (RFC 2136) (DNS Dynamic Update). Ce mécanisme permet à un client de soumettre aux serveurs DNS autoritaires sur un nom de domaine donné, une requête de mise à jour DNS concernant ce nom de domaine. Les seules opérations possibles de mise à jour sont celles de l'ajout d'enregistrements DNS (RRs) ou de suppressions de RRs ou de RRsets (ensemble de RRs de même nom, classe et type). Dans ces cas-là, le TTL est relativement très court (de 0 secondes à quelques minutes). Les requêtes les plus fréquentes sont celles de l'ajout ou de la suppression de l'adresse IP d'un équipement dans le DNS direct (correspondance du nom vers l'adresse) ou de son nom dans le DNS inverse (correspondance de l'adresse vers le nom).

Dans le cas de l'auto-configuration IPv6 sans état (RFC 2462) (cf. Configuration automatique), le client de mise à jour dynamique du DNS (nsupdate par exemple) peut s'exécuter sur l'équipement-même concerné par la mise à jour. Dans le cas de l'autoconfiguration avec état (DHCP) (cf. Configuration avec état :DHCPv6), le client de mise à jour peut soit s'exécuter sur l'équipement concerné soit être couplé au serveur DHCP.

Le protocole de mise à jour dynamique du DNS See (RFC 2136) n'a pas été sécurisé à la base, c'est-à-dire, il n'a pas prévu l'authentification des seuls clients autorisés à modifier des enregistrements DNS. Le RFC 3007 propose donc de sécuriser les transactions de mise à jour du DNS, notamment en utilisant les techniques TSIG (RFC 2845), TKEY (RFC 2930) ou SIG(0) (RFC 2931) :

• La première technique, TSIG (Secret Key Transaction Signatures for DNS) permet l'authentification des parties de la transaction et de signer les messages DNS à l'aide d'une clé secrète symétrique. Soulignons que TSIG ne décrit pas le mécansime par lequel la clé secrète est mise en place (cette clé est donc configurée par défaut manuellement).
• La deuxième technique, TKEY (Secret Key Establishment for DNS), vient compléter la première : elle permet d'automatiser la construction et la mise en place de la clé secrète à utiliser par TSIG.
• Enfin, la troisième technique, SIG(0) (DNS Request and Transaction Signatures), permet d'authentifier les parties de la transaction et de signer les messages DNS à l'aide d'une paire de clés (Clé publique/Clé privée) dont la partie publique est stockée dans le DNS grâce à des enregistrements de type KEY.

Malheureusement, la mise à jour dynamique sécurisée du DNS n'est toujours pas déployée à grande échelle. En effet, d'un côté, même si la technique TSIG est largement implémentée, elle n'est pas extensible (« scalable ») et de l'autre, la technique SIG(0) n'est que partiellement implémentée aujourd'hui. Ainsi SIG(0) est partiellement implémentée dans la distribution BIND 9.3.0 et supérieures.

En outre, la mise à jour dynamique du DNS devient problématique si celle-ci résulte de la configuration automatique d'un équipement IPv6 dans un réseau étranger (par exemple dans le cadre de la mobilité). En effet, si cet équipement peut théoriquement soumettre une requête de mise à jour de son (ou de ses) enregistrement(s) AAAA dans sa zone DNS direct, il n'est généralement pas autorisé à soumettre des requêtes de mise à jour de son (ou de ses) enregistrement(s) PTR dans la zone DNS inverse car celle-ci est sous l'autorité de serveurs DNS dans le réseau visité.

Découverte de la liste de serveurs DNS récursifs

Table des matières

Supports de transmission