Difference between revisions of "Logiciels DNS supportant IPv6 et configurations"
From Livre IPv6
(→Clients et outils de vérification de configurations DNS) |
(→Clients et outils de vérification de configurations DNS) |
||
Line 7: | Line 7: | ||
== Clients et outils de vérification de configurations DNS == | == Clients et outils de vérification de configurations DNS == | ||
− | Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils dig, host et nslookup qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après. | + | Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après. |
− | Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant | + | Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix : |
search nic.fr # domaine de recherche par défaut | search nic.fr # domaine de recherche par défaut | ||
Line 115: | Line 115: | ||
===Fichier de configuration d'un serveur BIND9=== | ===Fichier de configuration d'un serveur BIND9=== | ||
− | Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie options par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory). | + | Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory). |
− | Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique masters ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> : | + | Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> : |
options { | options { | ||
Line 215: | Line 215: | ||
L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles : | L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles : | ||
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ; | * <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ; | ||
− | * une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport | + | * une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ; |
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut). | * <tt>none</tt> : pas de support d'IPv6 (valeur par défaut). | ||
Line 222: | Line 222: | ||
===Fichier de zone DNS direct=== | ===Fichier de zone DNS direct=== | ||
− | Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par | + | Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dépendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291). |
$TTL 172800 | $TTL 172800 |
Latest revision as of 15:09, 4 July 2008
|
Nommage inverse : de l'adresse vers les noms | Table des matières | Les solutions expérimentales A6 et bitstring labels | |
Il existe aujourd'hui de nombreux logiciels DNS mais la présente section ne les liste pas de manière exhaustive. La plupart de ces logiciels DNS supportent IPv6 dans leurs versions récentes. Ce support peut être soit complet (enregistrements AAAA, enregistrements PTR sous l'arborescence ip6.arpa et transport IPv6 des messages DNS) soit partiel (uniquement les enregistrements AAAA et PTR) selon le logiciel.
En outre, certaines distributions logicielles comportent l'implémentation du client et du serveur, d'autres n'incluent que l'implémentation du client ou celle du serveur. Par exemple, la distribution BIND 9 développée par l'ISC (Internet Systems Consortium) représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC, ...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows *, ...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.
Contents
Clients et outils de vérification de configurations DNS
Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « libresolv », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils dig, host et nslookup qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.
Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier /etc/resolv.conf pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier resolv.conf sous Unix :
search nic.fr # domaine de recherche par défaut nameserver ::1 # prefer localhost-v6 nameserver 192.134.4.162 # backup v4
Exemples d'interrogation
Les six exemples suivants illustrent l'utilisation des outils dig, host et nslookup pour la même requête de résolution du nom `ns3.nic.fr' en adresse(s) IPv6 :
>dig ns3.nic.fr aaaa ; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7
;; QUESTION SECTION: ;ns3.nic.fr. IN AAAA
;; ANSWER SECTION: ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1
;; AUTHORITY SECTION: nic.fr. 78032 IN NS ns1.nic.fr. nic.fr. 78032 IN NS ns2.nic.fr. nic.fr. 78032 IN NS ns3.nic.fr. nic.fr. 78032 IN NS ns-sec.ripe.net. [...]
;; ADDITIONAL SECTION: ns1.nic.fr. 78032 IN A 192.93.0.1 ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1 ns2.nic.fr. 25737 IN A 192.93.0.4 ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2 ns-sec.ripe.net. 96368 IN A 193.0.0.196 ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4
;; Query time: 2 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Oct 25 19:13:54 2007 ;; MSG SIZE rcvd: 350
>dig ns3.nic.fr aaaa @ns-sec.ripe.net ; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5 ;; QUESTION SECTION: ;ns3.nic.fr. IN AAAA ;; ANSWER SECTION: ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1 ;; AUTHORITY SECTION: [...] ;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)
>host -t aaaa ns3.nic.fr ns3.nic.fr has AAAA address 2001:660:3006:1::1:1
>host -t aaaa ns3.nic.fr ns-sec.ripe.net Using domain server: Name: ns-sec.ripe.net Address: 2001:610:240:0:53::4#53 Aliases: ns3.nic.fr has AAAA address 2001:660:3006:1::1:1
>nslookup -type=aaaa ns3.nic.fr Server: 2001:660:3003:2::1:1 Address: 2001:660:3003:2::1:1#53 Non-authoritative answer: ns3.nic.fr has AAAA address 2001:660:3006:1::1:1 [...]
>nslookup -type=aaaa ns3.nic.fr -secripe.net Server: ns-sec.ripe.net Address: 2001:610:240:0:53::4#53 ns3.nic.fr has AAAA address 2001:660:3006:1::1:1
Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (2001:660:3003:2::1:1). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur ns-sec.ripe.net (qui est secondaire pour la zone nic.fr).
Notons que l'outil nslookup n'est plus maintenu par l'ISC et qu'il est amené à disparaître. L'usage de l'outil dig ou de host pour toutes sortes de requêtes est en revanche recommandé.
La deuxième version de ZoneCheck, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, ZoneCheck permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).
Fichier de configuration d'un serveur BIND9
Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie options par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).
Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique masters ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier named.conf du serveur DNS ns3.nic.fr :
options { directory "/usr/local/bind"; recursion no; listen-on { any;}; listen-on-v6 {any; }; [...] }; [...] zone "." { type hint; file "named.root"; }; zone "localhost" { type master; file "localhost"; }; // Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4 zone "0.0.127.in-addr.arpa" { type master; file "localhost.rev"; }; // Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour // l'adresse loopback en IPv6 zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { type master; file "localhost.rev"; };
[...] zone "nic.fr" { type slave; file "zone/nic.fr"; masters { 2001:660:3005:1::1:1; 192.93.0.1; 2001:660:3005:1::1:2; 192.93.0.4; }; }; [...] // Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24 zone "0.134.192.in-addr.arpa" { type slave; file "rev/nic.fr.192.134.0"; masters { 2001:660:3005:1::1:1; 192.93.0.1; 2001:660:3005:1::1:2; 192.93.0.4; }; }; [...] // Blocs Ripe sous ip6.arpa. zone "6.0.1.0.0.2.ip6.arpa" { type slave; file "rev/6.0.1.0.0.2.ip6.arpa"; masters { 2001:610:240:0:53::3; 193.0.0.195; }; }; [...] // Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48 zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" { type slave; file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa"; masters { 2001:660:3005:1::1:1; 192.93.0.1; 2001:660:3005:1::1:2; 192.93.0.4; }; }; [...]
L'option « listen-on » peut avoir comme valeurs possibles :
- any : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
- une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
- none : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).
L'option « listen-on-v6 » peut avoir comme valeurs possibles :
- any : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
- une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
- none : pas de support d'IPv6 (valeur par défaut).
Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur ns3.nic.fr fait autorité.
Fichier de zone DNS direct
Voici à titre d'exemple, un extrait du fichier de zone DNS direct `nic.fr', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dépendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).
$TTL 172800 $ORIGIN nic.fr. @ IN SOA maya.nic.fr. hostmaster.nic.fr. ( 2007102200 ;serial 21600 ;refresh (6 h) 3600 ;retry (1 h) 3600000 ;expire 86400 ) ;minimum (2 j) IN NS ns1.nic.fr. IN NS ns2.nic.fr. IN NS ns3.nic.fr. [...] IN MX 10 mx1.nic.fr. IN MX 20 mx2.nic.fr. [...]
ns1 IN A 192.93.0.1 IN AAAA 2001:660:3005:1::1:1 ns2 IN A 192.93.0.4 IN AAAA 2001:660:3005:1::1:2 ns3 IN A 192.134.0.49 IN AAAA 2001:660:3006:1::1:1 [...] www IN CNAME rigolo rigolo IN A 192.134.4.20 IN AAAA 2001:660:3003:2::4:20
kerkenna IN A 192.134.4.98 IN AAAA 2001:660:3003:8::4:98 [...]
Fichier de zone DNS inverse en IPv6
Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 2001:660:3003::/48 (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :
$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. $TTL 172800 @ IN SOA maya.nic.fr. hostmaster.nic.fr. ( 2007031200 ;serial 43200 ;refresh (12 h) 14400 ;retry (4 h) 3600000 ;expire 3600 ); IN NS ns1.nic.fr. IN NS ns2.nic.fr. IN NS ns3.nic.fr. [...] 0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr. 7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr. 1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr. 8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr. [...]
|
Nommage inverse : de l'adresse vers les noms | Table des matières | Les solutions expérimentales A6 et bitstring labels | |