Ajouter la ligne suivante dans la section « options » du named.conf :

listen-on-v6 {any;};

Un programme a été développé en interne pour répondre à la problématique suivante :

• utilisation de Bind 9.2,
• choix d'une gestion « autoritaire » des entrées DNS (pas de DDNS update à l'initiative des clients),
• la gestion manuelle des tables DNS, déjà très lourde et source d'erreurs en IPv4, devient impraticable en IPv6 (conversion MAC/EUI-64, AAAA/PTR, longueur des adresses),
• espace d'adressage IPv4 morcelé en de multiples « /24 », d'où un grand nombre de fichiers de zones à maintenir,
• souhait de conserver une bonne lisibilité aux fichiers de zones (tri des entrées),
• bijection tables DHCP (baux réservés sur adresses MAC) et tables DNS (adresse EUI-64 dépendant de l'adresse MAC).

Ce programme nommé « majdns », réalisé en Perl, prend en charge la gestion des fichiers de zones DNS spécifiques à Bind. Il offre une interface de saisie interactive de type terminal, et un mode batch pour l'importation d'une liste de noms d'hôtes associés à leurs paramètres IP (adresse IPv4, IPv6 ou adresse MAC). Un filtre permettant d'importer des déclarations d'hôtes extraites de dhcpd.conf (fichier de configuration du démon ISC DHCPD) a également été créé.

• gestion des tables au niveau du sous-réseau. Le fichier « subnets » contient la liste des sous-réseaux gérés avec pour chacun le nom, la plage IPv4 (en notation CIDR « /xx ») et/ou la plage IPv6. Pour chaque sous-réseau subnet disposant d'une plage IPv4, les fichiers zd.subnet et zi.subnet contiennent respectivement les enregistrements A et PTR v4 des hôtes membres, tandis que zd6.subnet et zi6.subnet (ce dernier décliné en -int et -arpa, ce qui n'est désormais plus nécessaire depuis l'abandon du domaine ip6.int par la RFC 4159) contiennent les AAAA et PTR v6 le cas échéant. Les fichiers de zones db.zone déclarés dans named.conf sont réduits aux enregistrements SOA et NS et à une série de $INCLUDE des fichiers zdxx et zixx,

Exemple de fichier “subnets”

pmf-adm         194.214.25.0/24         2001:660:3305:30::/64
srb-rech        194.214.32.0/24         -
ulm-pers        194.214.30.32/27        2001:660:3305:1230::/64

• automatisation de toutes les tâches « mécaniques » : mise à jour des SOA, tri des entrées, contrôle des collisions, conversions MAC/EUI-64 et AAAA/PTR, recherche d'adresses IPv4 libres, etc.,
• gestion des entrées au niveau hôte ou CNAME, un hôte étant caractérisé par son nom, son sous-réseau, son adresse IPv4 et/ou son adresse IPv6 et/ou son adresse MAC. Pour IPv6, la saisie d'une adresse MAC ou IPv6 détermine le choix entre une adresse EUI-64 ou explicite,
• gestion de deux « vues » DNS, interne et externe, cette dernière excluant les adresses IPv4 privées.

La structuration en hôtes et sous-réseaux et les automatismes du programme « majdns » permettent à un opérateur d'effectuer de façon simple les opérations courantes (ajout, suppression et modification d'hôtes, ajout et suppression de CNAMEs) en s'affranchissant de la « cuisine » nécessaire à la maintenance des fichiers de zones, mais en gardant le contrôle de tous les paramètres pertinents.

Ce document est également disponible au format PDF ddns_v6.pdf

Etant donné la longueur des adresses IPv6, l'administration du service DNS peut très vite devenir une tâche fastidieuse notamment pour ce qui concerne les enregistrements inverses. L’utilisation d’un service DNS avec “Dynamic Updates” [1] aussi appelé DDNS (Dynamic DNS) permet à un client de s’enregistrer automatiquement par l’envoi de messages spécifiques au serveur. Ce document va donc présenter le travail nécessaire pour la mise en oeuvre de tels mécanismes du côté serveur et client sans négliger l’aspect sécurité [2].

Les extraits de configuration qui suivent sont basés sur le serveur Bind dans sa version 9.3.1. Les versions antérieures (ex : Bind 8) supportent également les mises à jour dynamiques mais les configurations peuvent s’avérer différentes; c’est pourquoi il sera préférable de se reporter aux documentations adaptées [3].

La configuration du serveur ne nécessite que très peu de changements pour activer cette fonctionnalité intéressante. Il suffit pour cela de définir sa politique de mises à jour dynamiques pour la zone concernée dans le fichier named.conf :

zone "postes.ipv6.ciril.fr" IN {
  type master;
  file "postes.ipv6.ciril.fr.db";
  // On autorise les maj automatiques pour cette zone	
  update-policy { 
    // On autorise la modification des enregistrements AAAA
    grant <key> subdomain postes.ipv6.ciril.fr AAAA; 
  };
};

La politique de mise à jour définie ci-dessus permet à un poste possédant la clé <key> de modifier les enregistrements de type AAAA pour le sous-domaine postes.ipv6.ciril.fr. La section update policy peut définir ainsi plusieurs règles du type :

grant <key> <type> <zone> <record-types>;

La balise <key> fait référence à une clé explicitement définie dans le fichier named.conf. Il est également possible de définir les clés dans un fichier séparé (exemple : /var/named/keys.conf) puis d'inclure ce dernier dans le fichier de configuration du démon :

include "keys.conf";

La balise <type> représente la portée de la règle. En d'autres termes la règle peut s'appliquer à un sous-domaine (subdomain) dans son ensemble ou uniquement à un enregistrement simple (name).

grant host1.ipv6.ciril.fr.key. name host1.ipv6.ciril.fr. AAAA;
grant host1.ipv6.ciril.fr.key. name host1.ipv6.ciril.fr. AAAA;
grant ipv6.ciril.fr.key.  subdomain ipv6.ciril.fr. AAAA;

Finalement la balise <record-types> permet de définir les types d’enregistrements modifiables. Il ne serait pas très judicieux de permettre la modification d’enregistrements MX. De la même façon il sera préférable d’éviter d’activer les mises à jour dynamiques dans une zone contenant des enregistrements critiques (serveurs, …).

Génération des clés :

Afin de garantir l'authentification des différents acteurs, il est donc nécessaire de générer les clés qui permettront de signer les messages de mises à jour des enregistrements. La signature des transactions (TSIG : Trasaction SIGnature [4]) permettra ainsi d'éviter que n'importe quel poste puisse effectuer des modifications dans les enregistrements du serveur de noms.

La génération des clés publiques/privées est réalisée par l'intermédiaire de l'outil dnssec-keygen fournit avec BIND :

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST updates.postes.

Suite à l'exécution de cette commande deux fichiers contenant respectivement la clé publique et la clé privée sont créés. (Attention : positionner les droits de lecture) Il est donc maintenant nécessaire de déclarer cette clé privée dans le fichier de configuration named.conf (ou keys.conf). C'est le partage de cette clé entre le serveur et le poste client qui va permettre d'authentifier les deux acteurs lors des transactions.

key ipv6.ciril.fr.key. {
	algorithm "hmac-md5";
       	secret "wMkRFcweTFSBwlbWDaoF0w==";
};

La clé secrète définie dans la section key est celle qui a été généré dans le fichier Kupdate.postes.+157+56324.private.

# cat Kupdate.postes.+157+56324.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: wMkRFcweTFSBwlbWDaoF0w==