Tuto Virtualisation – Partie VII, Serveur Dns autoritaire complet avec gestion par vues

ARTICLE PERIME !

Retrouvez cette série de tuto dans une grosse mise à jour ici : Xen et OpenVswitch sont dans une Debian 9 – V.2018
La nouvelle version du DNS ici : Partie VIII, serveur DNS autoritaire complet avec gestion par vues

---

 

Septiè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, un 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 conseil 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’intallation de bind :

# apt-get install bind9 bind9utils 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 😉
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écursion, 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écursion 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
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

And 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 à modifier :

#!/bin/bash
# On 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
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
# Autoriser ping
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
# Autoriser la connexion ssh depuis le dom0
iptables -t filter -A INPUT -p tcp -s 10.99.1.1 --dport 22 -j ACCEPT
# Autoriser le routeur a faire des requetes DNS vers la vm dns, 9999 et 3128 vers la vm proxy et NTP vers le dom0
#iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
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
iptables -t filter -A OUTPUT -p udp -d 10.99.1.1 --dport 123 -j ACCEPT
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

# Autoriser les pings VM->EXT
iptables -t filter -A FORWARD -p icmp -s 10.2.1.3 -j ACCEPT
iptables -t filter -A FORWARD -p icmp -s 10.10.1.0/24 -j ACCEPT
# Autoriser les requetes DNS VM DNS->EXT
iptables -t filter -A FORWARD -p udp -s 10.10.1.254 --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -p tcp -s 10.10.1.254 --dport 53 -j ACCEPT
# Autoriser les requetes HTTP PROXY INTERNE->EXT
iptables -t filter -A FORWARD -p tcp -s 10.10.1.11 --dport 80 -j ACCEPT
# Transfert du port 80 vers 10.10.1.10 et autorisation
iptables -t nat -A PREROUTING -i eth0 -d IPFAILOVER -p tcp --dport 80 -j DNAT --to-destination 10.10.1.10
iptables -t filter -A FORWARD -p tcp -d 10.10.1.10 --dport 80 -j ACCEPT
# Transfert du port 53 vers 10.10.1.254 et autorisation
iptables -t nat -A PREROUTING -i eth0 -d IPFAILOVER -p tcp --dport 53 -j DNAT --to-destination 10.10.1.254
iptables -t nat -A PREROUTING -i eth0 -d IPFAILOVER -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
# Tout ce qui vient des VMS et est autorise est POSTROUTE pour sortir
iptables -t nat -A POSTROUTING -o eth0 -s 10.2.1.0/24 -j SNAT --to IPFAILOVER
iptables -t nat -A POSTROUTING -o eth0 -s 10.10.1.0/24 -j SNAT --to IPFAILOVER
echo - OK

Et on applique :

routeur# /etc/init.d/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, sachant que c’est assez simple, mais je n’explique pas forcement très bien. Au pire, dites moi si ce n’est pas clair, je tenterais d’éclaircir.
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

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. Enfin, ajoutez bien votre domaine hein 😉
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 regaire 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.

Petit rajout sur la zone recursive pour nous.
SI vous faites un ajout dans la zone autoritaire, vous allez constater que le modification ne sera pas visible de suite pour vous.
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 ?
Ajouter 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