Traduit Par Jean Théry (France) URL originale : http://www.crt.se/dnssec/bind9/Bv9ARM.ch04.html#AEN974
SECTION 4.8
Résolution normale
L'enregistrement AAAA est milaire au A en IPv4. Il spécifie une
adresse entière en un seul enregistrement. Par exemple,
$ORIGIN example.com.
host 3600 IN AAAA 3ffe:8050:201:1860:42::1
Example:
; IPV6 (REVERSE) ADDRESS LOOKUPS
; VT RFC1897 prefix is 5F05:2000/32
secondary 0.0.0.2.5.0.f.5.IP6.INT dns/ipv6/r
primary 8.5.0.0.0.0.8.5.d.a.0.8.0.0.0.2.5.0.f.5.IP6.INT dns/ipv6/ee/r
primary 8.2.0.0.0.0.8.2.d.a.0.8.0.0.0.2.5.0.f.5.IP6.INT dns/ipv6/cs/r
; Provide address-to-hostname resolution for the loopback address
primary 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.INT dns/ipv6/loopback
forwarders 128.173.4.247 128.173.4.113
Exemple de configuration BIND :
fichier named.conf :
zone "F.E.4.8.8.2.0.3.0.0.2.1.e.f.f.3.ip6.int" {
type master;
file "/etc/namedb/3ffe_1200_3028_84EF___64.rev";
also-notify {
194.117.194.82;
};
};
fichier F.E.4.8.8.2.0.3.0.0.2.1.e.f.f.3.ip6.int :
; 3ffe:1200:3028:825d::/64
$TTL 1H
$ORIGIN b.5.2.8.8.2.0.3.0.0.2.1.e.f.f.3.ip6.int.
0 IN SOA ns0.teraii.dhs.org. admin.teraii.dhs.org. (
2001021024
43200
900
2419200
86400 )
IN NS ns0.teraii.dhs.org.
IN NS ns1.teraii.dhs.org.
$ORIGIN 0.b.5.2.8.8.2.0.3.0.0.2.1.e.f.f.3.ip6.int.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR routeur.ipv6.teraii.dhs.org.
7.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR stupid-host.ipv6.teraii.dhs.org.
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR station1.ipv6.teraii.dhs.org.
21.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ftp.ipv6.teraii.dhs.org.
80.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.ipv6.teraii.dhs.org.
6667.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR irc.ipv6.teraii.dhs.org.
BIND 9 implémente complètement toutes les
formes de résolution de type nom vers adresse IPv6 ou adresse IP vers nom. Il peut aussi utiliser
les adresses IPv6 pour faire des requêtes quand il s'exécute sur un
système d'exploitation supportant IPv6.
Pour la résolution, BIND 9 supporte aus
bien les enregistrements A6 que AAAA. L'utilisation des enregistrements AAAA
est obsolète, mais il est toujours utile pour les hôtes d'avoir des enregistrements des deux types AAAA et A6. Cela assure la compatibilité avec les réseaux où les enregistrements AAAA sont toujours utilisés.
En fait, la plupart des solveurs actuellement
fourni avec la plupart des systèmes d'exploitation supportent seulement les résolutions
de type AAAA, car suivre les chaînes A6 est plus difficile que résoudre
les A ou AAAA.
Pour la résolution IPv6 inverse, BIND 9
supporte le nouveau format "bitstring" utilisé pour le domaine ip6.arpa,
au lieu de l'ancien format "nibble" obsolète utilisé pour le
domaine ip6.int.
BIND 9 inclut une
nouvelle bibliothèque de résolution légère et un nouveau démon de résolution
que les nouvelles applications peuvent choir d'utiliser pour éviter la complexité du suivi des chaînes d'étiquettes A6 et bitstring, voyez le Chapitre
5.
Pour une vue complète du format et de la structure
des adresses IPv6, voyez la Section
A.3.1.
L'enregistrement AAAA est milaire au A en IPv4. Il spécifie une
adresse entière en un seul enregistrement. Par exemple,
$ORIGIN exemple.com.
host 3600 IN AAAA 3ffe:8050:201:1860:42::1
Une requête effectuée sur une machine retourne tous les enregistrements de
type AAAA qui se rapportent à cette machine. Certaines adresses n'ont pas
d'enregistrement : adresses de lien local, adresses IPv4 compatibles, adresses
IPv4 mappées.
Bien que cette utilisation
soit déconseillée,
cela peut être pratique pour les vieilles application IPv6. Les enregistrements AAAA
ne doivent plus être utilisés à moins que ce ne soit absolument nécessaire.
L'enregistrement A6 est plus souple que l'AAAA, et il est
en conséquence plus complexe. L'enregistrement A6 peut être utilisé pour former une chaîne
d'enregistrements A6, chacun étant une part de l'adresse IPv6. Il
peut aussi être utilisé pour spécifier un enregistrement entier. Par exemple, cet enregistrement fourni la même
information que celle de l'exemple précédent :
$ORIGIN exemple.com.
host 3600 IN A6 0 3ffe:8050:201:1860:42::1
Les enregistrements A6 ont été conçus pour
permettre la renumérotation de réseaux. L'idée est de ne spécifier que la partie de l'adresse que le possesseur du domaine contrôle. Par exemple,
imaginons un hôte dans une société appelée "compagnie."
Il y a 2 FAI fournissant un espace d'adresses pour la société. Ces
2 FAI spécifient le préfixe IPv6 qu'ils fournissent.
Dans l'espace d'adresse de la société:
$ORIGIN exemple.com.
host 3600 IN A6 64 0:0:0:0:42::1 compagnie.exemple1.net.
host 3600 IN A6 64 0:0:0:0:42::1 compagnie.exemple2.net.
FAI1 utilisera:
$ORIGIN exemple1.net.
compagnie 3600 IN A6 0 3ffe:8050:201:1860::
FAI2 utilisera:
$ORIGIN exemple2.net.
compagnie 3600 IN A6 0 1234:5678:90ab:fffa::
quand host.exemple.com
est résolu, le solveur (le démon de résolution ou le serveur
cache de noms ) trouvera 2 enregistrements A6 partiels, et utilisera le
nom additionnel pour trouver le reste des données.
Quand un enregistrement A6 spécifie l'adresse
d'un serveur de nom, il doit utiliser l'adresse complète plutôt que
l'adresse partielle. Par exemple:
$ORIGIN exemple.com.
@ 14400 IN NS ns0
14400 IN NS ns1
ns0 14400 IN A6 0 3ffe:8050:201:1860:42::1
ns1 14400 IN A 192.168.42.1
Il est recommandé de ne pas utiliser les adresses traduites IPv4-dans-IPv6. un
hôte a une adresse IPv4, utilisez
un enregistrement de type A, et non un de type A6, avec ::ffff:192.168.42.1
comme adresse.
L'utilisation du format nibble pour la résolution
d'adresses est déconseillé, il est seulement supporté pour la
compatibilité avec les applications IPv6 existantes.
Pendant la résolution d'adresse avec un format nibble,
Les composants d'adresse sont mplement inversés, comme en IPv4, et ip6.int.
est ajouté au nom résultant. L'exemple suivant montre une résolution
inverse pour un hôte dont l'adresse est 3ffe:8050:201:1860:42::1.
$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int.
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.exemple.com.
Les étiquettes de « Bitstring » peuvent commencer et
se finir sur n'importe quel bit, plutôt que sur un multiple de 4
bits comme dans le format de « nibble ». Elles utilisent également ip6.arpa au
lieu de ip6.int.
Pour reproduire l'exemple précédent en utilisant « bitstring »
:
$ORIGIN \[x3ffe805002011860/64].ip6.arpa.
\[x0042000000000001/64] 14400 IN PTR host.exemple.com.
En IPV6, le même hôte peut avoir beaucoup
d'adresses venant d'un nombre de FAI élevé. Puisque le préfixe de l'adresse demeure
habituellement constant , DNAME peut aider à réduire le nombre de fichiers
de zone utilisés pour la résolution inverse et la maintenance.
Par exemple, condérez un hôte ayant deux
fournisseurs (exemple.net et exemple2.net) et donc deux adresses IPv6.
Puisque l'hôte choit sa propre partie d'adresse de 64 bits, l'adresse de
fournisseur est la seule partie qui change:
$ORIGIN exemple.com.
host IN A6 64 ::1234:5678:1212:5675 cust1.exemple.net.
IN A6 64 ::1234:5678:1212:5675 subnet5.exemple2.net.
$ORIGIN exemple.net.
cust1 IN A6 48 0:0:0:dddd:: ipv6net.exemple.net.
ipv6net IN A6 0 aa:bb:cccc::
$ORIGIN exemple2.net.
subnet5 IN A6 48 0:0:0:1:: ipv6net2.exemple2.net.
ipv6net2 IN A6 0 6666:5555:4::
Ceci établi la résolution normale. Pour prendre en charge les enregistrements inverses, le fournisseur exemple.net aurait:
$ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
\[xdddd/16] IN DNAME ipv6-rev.exemple.com.
et exemple2.net aurait:
$ORIGIN \[x666655550004/48].ip6.arpa.
\[x0001/16] IN DNAME ipv6-rev.exemple.com.
exemple.com n'a besoin que d'un fichier de zone pour manipuler tout les enregistrement inversés:
$ORIGIN ipv6-rev.example.com.
\[x1234567812125675/64] IN PTR host.exemple.com.
