par Huitième partie du tutoriel sur la virtualisation « Xen et OpenVswitch sont dans une Debian« .
Précédemment, nous avons mis en place un proxy interne pour nos VMS avec Squid et Apt-cacher-ng.
Nous allons mettre un place un DNS. Et même un DNS très complet :
Il va servir pour nos VMs afin qu’elles puissent se parler avec des noms plutôt que par les IPs. De plus, il servira à la résolution des noms externes.
Ce DNS servira aussi à « héberger » notre propre zone (au lieu de laisser cela à Gandi, Online, OVH) : ce qu’on appelle DNS autoritaire.
Et pour terminer, nous nous servirons de ce DNS pour notre pomme, car vous le savez peut être, ces derniers temps, les DNS de nos FAI français se trouve être de plus en plus menteur, ce sera le serveur récursif.
Et pour tout faire en un seul serveur, nous allons utiliser les views que propose bind.
I – Présentation
Si le terme DNS ne vous parle pas, pour expliquer brièvement : ce sont les serveurs qui vous donne l’adresse IP correspondante quand vous demandez une adresse de type blog.debugo.fr. Le fonctionnement est transparent pour l’utilisateur mais c’est un service indispensable pour utiliser le web.
On pourrait s’amuser à se souvenir des IPs pour accéder aux sites, mais ce n’est pas l’idéal car retenir des nombres, c’est compliqué, et avec les vhosts, ça ne suffirait pas : de nombreux sites utilisent une même IP pour plusieurs noms de domaines. Bref, le DNS est vital et pour plus d’explications : Wikipédia
Il faut retenir deux types de configurations possibles pour les serveurs DNS :
- Les serveurs récursif-cache qui servent pour résoudre les adresses (typiquement ceux que vous fournit votre FAI, etc…)
- Les serveurs d’autorité qui servent eux à définir une zone dans un intranet ou sur internet et à faire la correspondance IP-NOM au sein de cette zone.
On conseille généralement de ne pas faire les deux sur un même serveur. En effet, une attaque peut être menée sur un serveur récursif et il serait dommage que le serveur d’autorité en pâtisse.
Avec le principe des vues que j’utilise, pas de problèmes, chacune est indépendante.
J’ai donc besoin de faire du récursif pour chez moi (Pour mon récursif perso, j’aurais plutôt du le faire sur un serveur de mon réseau local à domicile, mais c’était l’occasion de tester la mise en place d’une sous zone pour chez moi…)
Cette partie me permettra de me passer des dns de Free qui ont tendance ces derniers temps à oublier des adresses…. 😉
Pour la partie autorité, je veux faire à la fois ma zone interne, typiquement debugo.lan et ma zone externe debugo.fr (et ainsi se passer des dns de mon registar (Online).
Alors, j’en profite de suite par rapport au choix du tld (Le TLD, c’est le .fr dans debugo.fr par exemple, ou le .fr de google.fr).
On voit souvent pour de l’interne .lan ou .cequejeveuxquinexistepas. J’ai longtemps fait comme ça jusqu’au jour ou un bon ami m’a dit : « Un tld à la c**, c’est inutile voir risqué. »
Dubitatif, je lui répondis alors : « Et, je prend quoi alors ? »
Sa réponse fut rapide et cinglante : « T’as ton domaine debugo.fr ? Bah prend ça… »
Intrigué, je commençais à y réfléchir, et c’est loin d’être idiot. Si c’est bien pensé, c’est même génial et règle par la même occasion quelques problèmes que j’avais au sein de la messagerie.
Bref, c’est ce que je vous propose ici.
Pour la partie gestion de votre zone externe, je donnerais aussi la marche à suivre coté Online ou Gandi pour se déclarer comme étant notre propre NS.
Allez, on se lance !
II – Prérequis, installation et préparation
Côté hyperviseur, on va créer une nouvelle vm :
dom0# xen-create-image --hostname dns --role debugo --size 5G --memory 512M --swap 1G --vcpus=1 --ip=99.99.99.99
Puis on modifie le fichier /etc/xen/dns.cfg :
vif = [ 'vifname=dns.0,ip=10.10.1.254 ,mac=00:16:3E:A2:54:10,bridge=brint.10', 'vifname=dns.1,ip=10.20.1.254 ,mac=00:16:3E:A2:54:20,bridge=brint.20', 'vifname=dns.2,ip=10.99.1.254 ,mac=00:16:3E:A2:54:99,bridge=brint.99']
puis l’interface :
dom0# mount /dev/vg0/dns-disk /mnt/vm/ dom0# nano /mnt/vm/etc/network/interfaces
Ou vous mettez cela :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.10.1.254 netmask 255.255.255.0 gateway 10.10.1.3 auto eth1 iface eth1 inet static address 10.20.1.254 netmask 255.255.255.0 auto eth2 iface eth2 inet static address 10.99.1.254 netmask 255.255.255.0
On démonte, on démarre la vm et on se connecte :
dom0# umount /mnt/vm dom0# xen create /etc/xen/dns.cfg dom0# ssh 10.99.1.254
Passons à l’installation de bind :
# apt-get install bind9 dnsutils
On va de suite créer quelques répertoires :
# mkdir /var/log/dns/ # touch /var/log/dns/query.log # touch /var/log/dns/error.log # chown bind:bind /var/log/dns/ -R # mkdir /etc/bind/zones
Pour monitorer les erreurs, je vous conseille d’avoir d’autres consoles et de faire dans chacune (une commande par console)
Log de base :
# tail -f /var/log/syslog
Log des requêtes :
# tail -f /var/log/dns/query.log
La gestion des logs peut être bien plus poussée que ce que je vous propose, mais ce n’est pas utile dans mon cas d’aller plus loin, et d’ailleurs, en prod, je ne log rien. A l’occasion, je compléterais avec un article détaillé sur ce point.
Au niveau réseau, les DNS utilise le port 53 en UDP et TCP.
Bind9 se configure dans /etc/bind/ et nous allons voir ça de suite.
III – Configuration des options
On édite le fichier /etc/bind/named.conf.options, on supprime ce qui s’y trouve et on colle ce qui suit :
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on { any;};
version "genre je donne ma version...";
};
logging {
channel query_log {
file "/var/log/dns/query.log";
severity debug 10;
print-category yes;
print-time yes;
print-severity yes;
};
channel error_log {
file "/var/log/dns/error.log";
severity error;
print-category yes;
print-time yes;
print-severity yes;
};
category queries { query_log;};
category security { error_log;};
};
Rien de compliqué, j’active juste l’écoute sur toutes les interfaces ipv4 et active les logs des requêtes. La directive version sert à masque la version de votre bind.
# dig @IPDNS -c CH -t txt version.bind
On édite ensuite le fichier /etc/bind/named.conf, et on enlève ce qui s’y trouve pour ne laisser au début que :
include "/etc/bind/named.conf.options";
IV – Les ACLS
Pour utiliser les vues, on doit définir au préalable des ACL afin de dire qui utilise quelle vue.
On édite le fichier /etc/bind/named.conf et on ajoute :
acl intra20 {
127.0.0.1;
10.20.1.0/24;
};
acl intra99 {
10.99.1.1;
};
acl extra {
IP.DE.VOTRE.DOMICILE;
};
Rien de sorcier la aussi. On définit deux acl intra, une pour le vlan20, une pour le vlan99 (qui servira pour l’hyperviseur) et une acl extra (qui servira pour le récursif) avec notre IP personnelle (ou celles que vous voulez autoriser à utiliser votre dns.)
V – Première vue : le serveur récursif
On va commencer par le plus simple : le serveur dns pour nous, qui nous permettra d’avoir un dns qui ne ment pas sur certaines adresses (contrairement à ceux des FAI…)
Toujours dans le fichier named.conf, on ajoute à la suite :
view "recur" {
recursion yes;
match-clients {extra;};
allow-query {extra;};
allow-recursion {extra; };
allow-query-cache {extra; };
};
C’est tout simple. On active la récursivité, la vue n’est autorisé que pour les requêtes venant de l’acl extra (match-clients) et pour eux, on autorise, les requêtes, la récursivité et le cache.
On peut tester depuis chez soi (a faire depuis une machine sur l’acl extra)
# nslookup google.fr IP.SERVEUR
Vous devriez avoir une réponse et voir au passage la requête dans les logs.
Reste plus qu’à coller votre dns dans la config de vos PCs, box, etc..
De plus, cela peut être très pratique pour bloquer des domaines : il suffit de rajouter cela dans la vue par exemple :
zone "media.admob.com" {
notify no;
type master;
file "null.zone.file";
};
Cela fait en sorte que ce domaine ne pointe sur rien, idéal pour bloquer la pub par exemple. C’est cette technique qu’utilisent nos FAI pour bloquer certains sites…
Je ferais un tutoriel plus tard la dessus (j’ai eu ce besoin en voyant ma fille s’agacer du trop de publicités sur la tablette 😉 )
VI – Seconde et troisième vues : le serveur d’autorité pour notre zone interne
Nous allons avoir deux cas à gérer : les demandes venant du vlan 20 des VMS, ou une question du genre « donne moi l’ip de web » devra donner 10.20.1.30.
Les demandes venant de l’hyperviseur quand je fais : ssh routeur par ex… Ou la, la réponse devra être 10.99.1.1
Alors oui, j’aurais pu rajouter les hosts dans le fichier adéquat de mon hyperviseur pour faire simple, mais je préfère passer par le dns vu que par la suite, j’ai l’intention d’automatiser pas mal de choses au niveau DNS.
A – Named.conf
Toujours à la suite dans le named.conf, on ajoute ce qui suit :
view "internal20" {
recursion yes;
match-clients {intra20;};
allow-query {intra20;};
allow-recursion {intra20;};
allow-query-cache {intra20;};
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "debugo.fr" {
notify no;
type master;
file "/etc/bind/zones/db.debugo.fr.intra20";
};
zone "1.20.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.debugo.fr.intra.rev";
};
};
view "internal99" {
recursion yes;
match-clients {intra99;};
allow-query {intra99;};
allow-recursion {intra99;};
allow-query-cache {intra99;};
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "debugo.fr" {
notify no;
type master;
file "/etc/bind/zones/db.debugo.fr.intra99";
};
zone "1.99.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.debugo.fr.intra.rev";
};
};
Techniquement, la vue interne fait de la récursion et de l’autorité pour nos VMS, mais a priori, peu de risques qu’une VM tente d’attaquer le serveur DNS.
B – Fichier de zone
On va maintenant créer les fichiers de zone :
# cd /etc/bind/zones # touch db.debugo.fr.intra20 # touch db.debugo.fr.intra99 # touch db.debugo.fr.intra.rev
Aucune obligation dans le nommage, mais en faisant ainsi, on sait facilement ce que c’est.
1 – Fichier db.debugo.fr.intra20
$TTL 10800 @ IN SOA dns.debugo.fr. dnsmaster.debugo.fr. ( 2015010101 ; Serial 5400 ; Refresh 2700 ; Retry 2419200 ; Expire 300 ) ; Negative TTL IN NS dns.debugo.fr. ;Nom du serveur debugo.fr. IN A 10.20.1.100 (futur serveur de messagerie, cette ligne sera utile pour postfixadmin) dns IN A 10.20.1.254 routeur IN A 10.20.1.2 ids IN A 10.20.1.3 proxy IN A 10.20.1.10 proxyint IN A 10.20.1.11 web IN A 10.20.1.30
2 – Fichier db.debugo.fr.intra99
$TTL 10800 @ IN SOA dns.debugo.fr. dnsmaster.debugo.fr. ( 2015010101 ; Serial 5400 ; Refresh 2700 ; Retry 2419200 ; Expire 300 ) ; Negative TTL IN NS dns.debugo.fr. ;Nom du serveur dns IN A 10.99.1.254 routeur IN A 10.99.1.2 ids IN A 10.99.1.3 proxy IN A 10.99.1.10 proxyint IN A 10.99.1.11 web IN A 10.99.1.30
3 – Fichier db.debugo.fr.intra.rev
$TTL 10800 @ IN SOA dns.debugo.fr. dnsmaster.debugo.fr. ( 2015021102 ; Serial 5400 ; Refresh 2700 ; Retry 2419200 ; Expire 300 ) ; Negative TTL @ IN NS dns.debugo.fr. 254 IN PTR dns.debugo.fr. 2 IN PTR routeur.debugo.fr. 3 IN PTR ids.debugo.fr. 10 IN PTR proxy.debugo.fr. 11 IN PTR proxyint.debugo.fr. 30 IN PTR web.debugo.fr.
On peut relancer bind :
dns# service bind restart
On va modifier également le fichier /etc/resolv.conf pour indiquer quel dns utiliser :
domain debugo.fr. search debugo.fr. nameserver 10.20.1.254
Et voila !
VII – Configuration des VMs
Pour chaque VM (Routeur, IDS,Proxy, Proxyint et Web), on va modifier le fichier /etc/resolv.conf de la sorte :
domain debugo.fr. search debugo.fr. nameserver 10.20.1.254
Pour l’hyperviseur, ça sera ainsi :
domain debugo.fr. search debugo.fr. nameserver 10.99.1.254
Ne reste plus qu’à tester avec nslookup (apt-get install dnsutils pour l’installer)
De n’importe quelle VM :
# nslookup web # nslookup google.fr
doivent vous retourner un résultat.
VIII – Modification du squelette Xen
Dans l’hyperviseur, on va rajouter un fichier /etc/xen-tools/skel2/etc/resolv.conf avec :
domain debugo.fr. search debugo.fr. nameserver 10.20.1.254
IX – Troisième Vue : Serveur d’autorité pour notre zone externe
A – Named.conf
Rajoutez cela à votre named.conf
view "external" {
recursion no;
match-clients {any;};
allow-query {any; };
allow-recursion {none; };
allow-query-cache {none; };
zone "debugo.fr" {
notify yes;
type master;
allow-transfer { 62.210.16.8;}; //mettez ici l'ip du dns secondaire de votre registar
file "/etc/bind/zones/db.debugo.fr.extra";
};
};
B – Fichier de zone
Créez un fichier /etc/bind/zones/db.debugo.fr.extra et mettez quelque chose de similaire à :
$TTL 10800 @ IN SOA a.debugo.fr. dnsmaster.debugo.fr. ( 2015080403 ; Serial 5400 ; Refresh 2700 ; Retry 2419200 ; Expire 300 ) ; Negative TTL IN NS a.debugo.fr. IN NS nssec.online.net. @ IN A IPFAILOVER debugo.fr. IN A IPFAILOVER root IN A IPFAILOVER a IN A IPFAILOVER
Ici a.debugo.fr est le nom que j’ai choisi pour nommer mon dns. J’explique plus bas ce que c’est exactement.
Ce fichier sera amené à évoluer avec le serveur mail entre autres.
C – Configuration routeur
On va devoir retoucher à la config du firewall pour autoriser les requetes dns a etre acheminée vers la bonne vm et d’autre part, n’autoriser que la vm dns a faire des requetes dns.
Voila le fichier /etc/init.d/firewall de la vm routeur, une fois modifié :
#!/bin/bash # PURGE iptables -t filter -F iptables -t filter -X iptables -t nat -F iptables -t nat -X # Interdire toute connexion entrante, sortante ou forwardee iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT DROP # Autoriser les connexions deja effectuees et les retours. iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # LOOPBACK OK iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT # PING INPUT ET OUTPUT OK iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT # SSH // DOM0 -> ROUTEUR iptables -t filter -A INPUT -p tcp -s 10.99.1.1 --dport 22 -j ACCEPT # DNS // ROUTEUR -> EXT iptables -t filter -A OUTPUT -p tcp -d 10.20.1.254 --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp -d 10.20.1.254 --dport 53 -j ACCEPT # Proxy // ROUTEUR -> PROXY iptables -t filter -A OUTPUT -p tcp -d 10.20.1.11 --dport 9999 -j ACCEPT iptables -t filter -A OUTPUT -p tcp -d 10.20.1.11 --dport 3128 -j ACCEPT # NTP // ROUTEUR -> DOM0 iptables -t filter -A OUTPUT -p udp -d 10.99.1.1 --dport 123 -j ACCEPT ################################################################################ # EXTERIEUR VERS VMS ################################################################################ # -> VM PROXY : HTTP ET HTTPS iptables -t nat -A PREROUTING -i eth0 -d IP_FAILOVER -p tcp --dport 80 -j DNAT --to-destination 10.10.1.10 iptables -t nat -A PREROUTING -i eth0 -d IP_FAILOVER -p tcp --dport 443 -j DNAT --to-destination 10.10.1.10 iptables -t filter -A FORWARD -p tcp -d 10.10.1.10 --dport 80 -j ACCEPT iptables -t filter -A FORWARD -p tcp -d 10.10.1.10 --dport 443 -j ACCEPT # -> VM DNS : DNS iptables -t nat -A PREROUTING -i eth0 -d IP_FAILOVER -p tcp --dport 53 -j DNAT --to-destination 10.10.1.254 iptables -t nat -A PREROUTING -i eth0 -d IP_FAILOVER -p udp --dport 53 -j DNAT --to-destination 10.10.1.254 iptables -t filter -A FORWARD -p tcp -d 10.10.1.254 --dport 53 -j ACCEPT iptables -t filter -A FORWARD -p udp -d 10.10.1.254 --dport 53 -j ACCEPT ################################################################################ # VMS VERS EXTERIEUR ################################################################################ #################### # IDS # PING, DNS iptables -t filter -A FORWARD -p icmp -s 10.2.1.3 -j ACCEPT iptables -t filter -A FORWARD -p udp -s 10.2.1.3 --dport 53 -j ACCEPT #################### # PROXY # PING iptables -t filter -A FORWARD -p icmp -s 10.10.1.10 -j ACCEPT #################### # PROXY INT # PING, HTTP(S) iptables -t filter -A FORWARD -p icmp -s 10.10.1.11 -j ACCEPT iptables -t filter -A FORWARD -p tcp -s 10.10.1.11 --dport 80 -j ACCEPT iptables -t filter -A FORWARD -p tcp -s 10.10.1.11 --dport 443 -j ACCEPT #################### # DNS # PING, DNS iptables -t filter -A FORWARD -p icmp -s 10.10.1.254 -j ACCEPT iptables -t filter -A FORWARD -p tcp -s 10.10.1.254 --dport 53 -j ACCEPT iptables -t filter -A FORWARD -p udp -s 10.10.1.254 --dport 53 -j ACCEPT ######################################## # POSTROUTING DES IPS 10.2.1.3, 10.10.1.0/24POUR LES PAQUETS SORTANT PAR ETH0 iptables -t nat -A POSTROUTING -o eth0 -s 10.2.1.3 -j SNAT --to 212.83.179.33 iptables -t nat -A POSTROUTING -o eth0 -s 10.10.1.0/24 -j SNAT --to 212.83.179.33
Et on applique :
routeur# /root/scripts/firewall
D – Mise en place
Plusieurs cas sont possibles : serveur chez tel hébergeur, domaine au même endroit, serveur chez tel hébergeur, domaine ailleurs.
Dans mon cas, j’ai mon domaine debugo.fr chez Online aussi (j’aurais du le prendre chez Gandi, Online ne gérant pas le dnssec…) et d’autres domaine chez gandi justement.
Je vais essayer d’expliquer clairement tous les cas de figures.
Chez n’importe quel registar, quand vous prenez un domaine, par défaut, ce sont les dns du registar qui sont utilisés.
C’est la que nous allons intervenir, un de ses serveurs ne sera plus celui du registar mais votre propre dns. L’intérêt ? Pour faire des modifications, vous allez directement éditer votre fichier de zone, plus besoin de passer par l’interface de votre registar. De plus, certains registar ne supportent pas certains types d’enregistrement DNS (de plus en plus rare ceci dit).
Donc, on va devoir dire que le premier NS (name server) pour votre domaine, c’est telle machine (ciblé par son FQDN) par exemple, j’utilise a.debugo.fr en NS primaire et nssec.online.net en secondaire
Le problème, c’est que l’on va se retrouver dans cette situation :
Client à son dns : Quelle est l’ip de www.debugo.fr ?
Le dns répond : je ne sais pas, mais tu peux le savoir chez a.debugo.fr
Et la, paf, comment savoir qui est a.debugo.fr ? A part demander à debugo.fr ?
Deux cas de figures :
1 – Dédié et domaine chez Online
La, on va jouer avec le reverse de la machine. (enfin, le reverse de l’IP Failover !)
On va dire que pour cette ip, le reverse c’est a.debugo.fr. Oui, sauf qu’avant, il faut que cette entrée existe dans le dns.
Donc, direction l’interface du dns Online de votre domaine pour rajouter une entrée de type A :
a.debugo.fr. IN A IPFAILOVER
On attend ensuite que le dns se propage et on retourne dans l’interface du dédié pour mettre a.debugo.fr en reverse de l’ip failover.
Ensuite, dans l’interface du dédié, cliquez sur Dns secondaires, et renseignez le domaine et l’ip (toujours celle du Failover).
De l’extérieur un nslookup sur cette ip nous retourne bien le bon reverse.
On peut alors mettre a.debugo.fr en NS principal dans l’interface de gestion du domaine.
2 – Dédié chez Online, domaine ailleurs (gandi par exemple)
On va utilise les gluerecords (ce qu’on a fait aussi avec Online, mais le terme n’apparait nul part).
Dans l’interface de votre domaine, trouvez la ligne Gérer les gluerecords (à droite) et ajoutez a.debugo.fr et l’ip failover de votre box.
Et ensuite, on change le dns dans l’interface.
Pour ma part, je suis dans le premier cas, mais avec des domaines en plus chez gandi. Côté Gandi, je dis simplement que le NS principal est a.debugo.fr (qui fonctionne deja et est deja trouvable, nul besoin de refaire un gluerecord.
Dans la partie Liens, je vous donne des liens pour tester vos dns et voir ou en est la propagation.
X – Gestion d’une sous zone pour chez soi.
Si vous faites un ajout dans la zone autoritaire, vous allez constater que le modification ne sera pas visible de suite pour vous (dans la vue récursive que vous utilisez).
Pourquoi ? Car vous utilisez une vue et que la modification est dans l’autre. Il faut que votre serveur récursif se synchronise comme n’importe quelle autre sur votre serveur autoritaire. Et oui, les vues sont distinctes jusqu’au bout.
Solution ?
Ajoutez votre zone externe dans votre vue récursive. Vous aurez les résultats en direct.
On peut aussi gérer ses machines locales :
Fichier /etc/bind/zones/db.intra.debugo.fr.extra :
$TTL 10800
@ IN SOA ns.intra.debugo.fr. dnsmaster.debugo.fr. (
2015021202 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
IN NS ns.intra.debugo.fr.
ns IN A 10.20.1.254
pc IN A 192.168.1.41
imprimante IN A 192.168.1.32
Ce qui donne cela au final dans le fichier named.conf :
view "recur" {
recursion yes;
match-clients {extra;};
allow-query {extra;};
allow-recursion {extra; };
allow-query-cache {extra; };
zone "debugo.fr" {
notify no;
type master;
file "/etc/bind/zones/db.debugo.fr.extra";
};
zone "intra.debugo.fr" {
notify no;
type master;
file "/etc/bind/zones/db.intra.debugo.fr.extra";
};
zone "media.admob.com" {
notify no;
type master;
file "null.zone.file";
};
};
Dans un futur tutoriel, j’expliquerais comment déléguer cette sous zone a un dns situé sur un Raspberry par exemple.
XI – Liens utiles
Quelques liens utiles pour tester son dns :
https://www.zonemaster.fr
http://www.intodns.com/
https://www.whatsmydns.net/
http://www.webdnstools.com/
http://www.dnswatch.info/
http://mxtoolbox.com/
http://migrationdns.com/
XII – Conclusion
Pensez toujours à bien incrémenter vos serials lorsque vous modifiez une zone.
Apres une modification de configuration, vous pouvez tapez :
dns# rndc reconfig
Apres une modification de zone :
dns# rndc reload
Et pour terminer, je ne traite pas le DNSsec, ce sera pour plus tard.
Maintenant, nous allons pouvoir passer au stockage de fichier avec notre futur nouvel ami, GlusterFS.
