Seb, quand tu nous dit que "c'est trivial", en mettant un tas de code de config incompréhensible pour le commun des mortels, c'est de la provoc?
Non, désolé, c'est sans doute une simple déformation professionnelle.
C'est trivial dans le sens où si tu sais déjà comment gérer des zones DNS avec BIND, c'est une simple formalité de les lui faire gérer sous forme de vues.
Je vais détailler ça, histoire d'étancher la soif de curiosité des ceusses que ça intéresse, mais thenico semble avoir une solution (unbound) qui a l'air bien plus simple d'emploi.
Dans mon exemple de configuration de BIND, il y a deux vues (voyons ça comme des directives de configuration particulières) :
- Le bloc view "lan" { ... }; correspond aux zones DNS qui seront servies aux machines de mon réseau local.
- Le bloc view "wan" { ... }; correspond aux zones DNS qui seront servies aux machines en provenance d'Internet.
Le serveur va décider quelle vue utiliser en fonction de l'adresse IP du client qui frappe à la porte (directive
match-clients { ... }; dans chaque vue) :
- La vue "lan" va être utilisée pour les machines qui se présentent avec l'adresse 127.0.0.1 ou une adresse en 192.168.1.x
- La vue "wan" sera utilisée pour tous les autres clients (donc les machines en provenance de l'Internet)
Dans le second cas, le plus simple, qui est celui de la résolution publique :
- On n'autorise pas la résolution des zones non gérées localement : recursion no;
- On définit la zone "le-seb.net" (zone "le-seb.net" { ... };) :
- pour laquelle le serveur est maître (type master;)
- qui autorise le serveur de backup à récupérer les mises à jour (allow-transfer { 217.70.177.40; };)
- qui s'appuie sur le fichier de définition de zone /etc/bind/db.wan.le-seb.net (file "/etc/bind/db.wan.le-seb.net";)
- Lequel fichier indique que l'entrée "www" dans la zone (le-seb.net) est un alias (CNAME) vers l'entrée "9box.le-seb.net" :
www CNAME 9box.le-seb.net. - Laquelle entrée sera résolue avec l'adresse IP publique de ma box :
9box IN A 93.31.136.109
Dans le premier cas, un brin plus compliqué, qui est celui de la résolution privée :
- On autorise la résolution des zones non gérées localement (interrogation des serveurs racine) : recursion yes;
- On inclut les directives de configuration supplèmentaires pour gérer les zones par défaut (qui intègrent entre autres les références aux serveurs racine) : include "/etc/bind/named.conf.default-zones";
- On définit la zone "le-seb.net" (zone "le-seb.net" { ... };) :
- pour laquelle le serveur est maître (type master;)
- qui s'appuie sur le fichier de définition de zone /etc/bind/db.lan.le-seb.net (file "/etc/bind/db.lan.le-seb.net";)
- Lequel fichier de zone indique que l'entrée "www" dans la zone (le-seb.net) est un alias (CNAME) vers l'entrée "master.le-seb.net" :
www CNAME master.le-seb.net. - Laquelle entrée sera résolue avec l'adresse IP privée du nœud maître de mon petit cluster :
master IN A 192.168.1.2
- On définit également une zone pour faire la résolution inverse (zone "1.168.192.in-addr.arpa" { ... };) ...
Si j'avais voulu faire suivre les requêtes non gérées localement par mon serveur DNS aux serveurs de mon FAI, plutôt que d'interroger moi-même les serveurs racine, j'aurais intégré une directive
forwarders { ... }; dans la vue "lan".
Au final, cette configuration fait que si tu réclames l'adresse de
www.le-seb.net, mon serveur DNS va te répondre 93.31.136.109, alors que si c'est moi qui la réclame, depuis mon PC connecté au LAN, il va me répondre 192.168.1.2.
Ça me permet de passer outre certaines limitations de la neufbox, qui ne gère pas le loopback depuis le LAN (je ne peux pas accéder à 93.31.136.109 depuis mon LAN), et aussi de gérer localement tout un tas d'enregistrements DNS qui ne sont pas visibles (et de toute façon non routables) depuis Internet, sans avoir à utiliser un autre domaine DNS.
Bref, ça ressemble pas mal à ce que tu cherches à faire.
TCP/IP / Fonctionnement des réseaux