DNS

Domaine Name Service (DNS)

Préambule

 

L'hébergement de services Internet nécessite que ces services puissent être joignable facilement à partir de la toile. Outre les fonctions 'publication' et 'recherche' qui relèvent plus particulièrement du référencement, nous aurons besoin de disposer d'un domaine de publication qui contiendra le nom de nos services disponibles. Un service étant par exemple un site Internet, un forum de discussion, une application...

Comme base de départ, nous disposons d'une BOX qui est référencée sur Internet par son adresse IP. L'objectif premier est donc d'associer un nom plutôt simple à mémoriser pour que cette adresse puisse être utilisable par les Internautes du monde entier.

Pour satisfaire ce premier objectif, la Box qui peut être atteignable par http://Adresse_IP_de_la_Box, le sera de façon plus lisible par http://Mon_Nom_de_Domaine.

Le deuxième objectif consistera à rendre joignable sur Internet certains services personnels installés derrière la Box, c'est à dire sur le réseau local de la maison. Pour celà, il faudra ouvrir quelques accès sur la Box pour rendre les services accessibles, les nommer en http://Nom_du_Service.Mon_Nom_de_Domaine et publier ces noms sur la toile.

Bienvenu dans l'univers du DNS

 

1°) Obtenir un nom de domaine

Le titre est suffisamment évocateur. Pour obtenir un nom de domaine, il va falloir se tourner sur un registraire. Le registraire est un bureau d'enregistrement qui va vous permettre d'acheter un nom de domaine. On se tournera par exemple sur Gandi.net ou Ovh.com pour rester français, Gandi ayant de loin ma préférence pour ses prestations de très haute qualité et son fairplay commercial.

Pour un nom de domaine en '.fr', compter environ entre 6€ et 15€ TTC.

Le choix d'un nom de domaine n'est pas anodin. Il doit être disponible, c'est à dire qu'il ne doit pas être déjà utilisé. Idéalement, il comportera très peu de caractères, il sera plutôt représentatif de l'activité envisagée et il sera facilement mémorisable.

Une fois le nom de domaine en poche, on peut passer à l'étape suivante.

 

2°) Paramètrer notre domaine

Le paramètrage du domaine consiste à définir notre serveur DNS interne comme serveur DNS externe vis-à-vis de la gestion DNS proposée par Gandi.net. En effet, Gandi propose au sein de son organisation une gestion DNS basée sur 'Gandi LiveDNS'. Or, cette solution présente deux inconvénients : d'une part, elle impose d'effectuer les opérations de création, modification et suppression de sous-domaines via l'interface Web de Gandi.net. D'autre part, la sécurisation SSL des différents sous-domaines (sites web) ne pourra s'effectuer qu'en achetant les certificats en mode individuel (12€ le certificat d'un sous-domaine), en mode multi-domaines (40 € pour 3 à 20 sous-domaines) ou encore en mode 'Wildcard' (120€ pour le domaine complet). Ces tarifs annuels, bien que n'étant pas très élevés, présentent néanmoins l'inconvénient d'augmenter la facture. Avec un peu d'huile de coude, il est possible de mieux faire gratuitement.

Définition des serveurs de noms externes

On prendra comme éléments, les données ci-après :

Domaine : pbr18.fr [fictif]
Nom du DNS principal : sdns0 (c'est le notre)
Nom du DNS secondaire : ns6.gandi.net (Gandi propose un DNS secondaire qui permettra de prendre le relai en cas de défaillance temporaire de notre DNS (sdns0)).

@IP de notre box : 10.15.20.25 [fictif]
@IP de ns6.gandi.net : 217.70.177.40

La déclaration des serveurs externes est simple puisqu'il suffit de saisir leurs nom dans l'interface Gandi.net prévue à cet effet (figure ci-dessous).

Gandi - Déclaration des serveurs externes

Les serveurs externes déclarés, il est maintenant possible d'associer notre serveur DNS interne (sdn0) en tant que Glue-record. Là aussi, l'association n'est pas compliquée. Il suffit de saisir le nom de notre DNS (sdns0) dans l'interface puis d'indiquer son ou ses adresses IP (IPV4 et/ou facultativement IPV6) comme dans la figure ci-dessous.

Gandi - Déclaration d'un Glue-record

Une fois validé, la déclaration prendra au maximum 72 heures pour être répliquée sur tous les DNS du monde.

L'objectif 1 étant atteint, nous pouvons passer à l'objectif numéro deux.

 

3) Ouvrir le port de communication DNS sur la Box

Le port n° 53 est nomalisé pour faire transiter les flux DNS. Pour mémoire, un port de communication peut être représenté par une porte verrouillée. Cette porte possède le numéro 53. On va donc ouvrir le verrou de la porte 53 pour faire en sorte que les flux DNS puissent entrer et sortir par la porte lorsqu'ils s'y présenteront.

Les flux DNS utilisent les protocoles de communication TCP et UDP.

Ouverture du port 53 sur une FreeBox Delta-S

Il faut se connecter à la FreeBox via l'adresse http://192.168.1.1. Sélectionner l'onglet 'Mode avancé' et dans la section 'Connexion Internet', double-cliquer sur l'icone 'Gestion des ports'.

Dans la fenêtre qui s'affiche, cliquer sur le bouton 'Ajouter une redirection'

L'IP Destination correspond à l'adresse IP de notre serveur Dns sur le réseau local. Cette adresse est différente de l'adresse IP publique de la Box qui va recevoir le flux TCP diffusé sur le port 53 et le rediriger sur le port 53 du serveur DNS interne. Toutes les adresses en provenance d'Internet pourront interroger notre serveur DNS.

On effectue une seconde redirection avec les mêmes caractéristiques mais cette fois ci pour le protocole UDP.

On obtient au final 2 redirections actives comme le montre la figure ci-dessous.

En récapitulant, on a positionné notre serveur DNS au niveau du registre via un glue-record. On a ensuite autorisé les internautes à interroger notre serveur DNS en redirigeant les flux DNS sur notre serveur DNS. Il ne nous reste plus qu'à intaller les services DNS sur notre serveur. Cette opération au demeurant plutôt simpliste comporte néanmoins quelques pièges plutôt déroutants.

 

4°) Choix du serveur DNS

Il existe plusieurs types de serveurs DNS. Dans le cadre de ce tutoriel, on optera pour une solution à base de DNS maître/subalterne (DNS maître : sdns0.pbr18.fr et DNS subalterne : ns6.gandi.net). Dans cette solution, le DNS maître reçoit et répond aux demandes de résolution d'adresses ; le DNS subalterne se contentant de prendre le relai en cas de défaillance du maître.

Un point très important : Le DNS maître fera autorité sur la zone pbr18.fr. C'est à dire qu'il se contentera, pour les internautes du monde entier, de résoudre uniquement le domaine pbr18.fr et tous les sous-domaines qui en découlent (exemple : compta.pbr18.fr, gestion.pbr18.fr, ...). Il rejettera tous les autres demandes qui ne concernent pas la zone pbr18.fr. Ceci impose que notre serveurs DNS sera connu du serveur DNS sur Internet qui gère la zone '.fr'. Il est important de signaler que notre DNS ne participera en aucun cas à la résolution de nom au profit des clients situés sur le réseau local. Ces derniers utiliseront la résolution DNS du FAI.

 

5°) Installation du serveur DNS - Bind-9.11

Le service DNS sera installé sur une machine équipée d'un système d'exploitation Centos-8, version minimale. (voir la procédure d'installation). Le paramètrage réseau sera le suivant :

L'adressage IP sera manuel
@IPV4 : 192.168.1.20
Nom du serveur : sdns0.home
Gateway : 192.168.1.1 (IP interne de la Box)
DNS : 192.168.1.1 (le serveur utilisera les services DNS de la Box pour les mises à jour du système d'exploitation par exemple).

 

Sur cette base, on s'assure que le système d'exploitation est bien à jour. On en profite pour installer les outils SElinux et le service DNS géré par Bind.

# dnf update
# dnf install policycoreutils policycoreutils-python-utils selinux-policy selinux-policy-targeted libselinux-utils setroubleshoot-server setools setools-console mcstrans

# dnf install bind bind-utils
-> ...
Installé:
  bind-32:9.11.4-26.P2.el8.x86_64                 bind-utils-32:9.11.4-26.P2.el8.x86_64
  bind-libs-32:9.11.4-26.P2.el8.x86_64            bind-libs-lite-32:9.11.4-26.P2.el8.x86_64
  bind-license-32:9.11.4-26.P2.el8.noarch         python3-bind-32:9.11.4-26.P2.el8.noarch

Sous centOS, le DNS s'appelle named.

# named -v
-> BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el8 (Extended Support Version) <id:7107deb>

Le serveur DNS écoute sur le port 53. Rappelez-vous, la Box redirige les flux DNS en provenance d'Internet sur le port 53 de notre serveur DNS. Il faut donc déverouiller ce port pour que le serveur DNS puisse intercepter le flux qui s'y présente.

# firewall-cmd --permanent --add-service=dns
-> success
# firewall-cmd --reload
-> success
# firewall-cmd --list-all
-> public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens18
  sources:
  services: cockpit dhcpv6-client dns ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

 

6°) Configuration du serveur DNS

La configuration du service DNS repose sur trois fichiers :

  • un fichier de configuration générale
    • /etc/named.conf
  • un fichier de configuration des données de la zone DNS
    • /var/named/forward.conf
  • un fichier de configuration des données inversées de la zone DNS
    • /var/named/reverse.conf

Règles syntaxiques.

Named.conf :
// -> commentaire sur une ligne
/* ..... */ -> commentaire sur plusieurs lignes
; -> termine chaque directive.

Attention : l'oublie d'un ";" est une erreur fréquente surtout au début. Il est donc conseillé de vérifier la synthaxe des fichiers avec les outils fournis par Bind (named-checkconf et named-checkzone). Voir ci-après.

forward.conf/reverse.conf
; -> commentaire sur une ligne
 

a) Le fichier de configuration named.conf

# cp /etc/named.conf /etc/named.conf.sav
# vi /etc/named.conf
->//
// named.conf
//
options {
        version none;
        hostname none;
        server-id none;

        listen-on port 53 { 127.0.0.1; 192.168.1.20; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named.stats";
                zone-statistics yes;
        memstatistics-file "/var/named/data/named.memstats";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { any; };
        allow-query-on  { localhost; 192.168.1.20; };

        recursion no;

        dnssec-enable yes;
        dnssec-validation auto;

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.log";
                severity dynamic;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "pbr18.fr" IN {
        type master;
        file "forward";
        notify yes;
        allow-update { localhost; 217.70.177.40; };
};

zone "30.25.20.15.in-addr.arpa" IN {
        type master;
        file "reverse";
        notify yes;
        allow-update { localhost; 217.70.177.40; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

En résumé, le serveur écoutera sur le port 53 à partir de lui même et de son adresse IP (listen-on, listen-on-v6). Tous le monde pourra l'interroger (allow-query) mais les réponses ne proviendront que de lui même ou de son adresse IP (allow-query-on). Si le serveur ne connaît pas la réponse, il n'est pas autorisé à interroger un autre serveur (recursion).
Pour la zone pbr18.fr, le serveur sera maître. Il informera le serveur DNS secondaire en cas de modification des données de la zone (notify) et il autorise le serveur DNS secondaire à lui demander de lui transférer les modifications qui sont intervenues (allow-update).

La signification détaillée des différentes options est reportée dans le tableau ci-dessous.

Options Explication defaut
version none; Masque le numéro de version en réponse à une requête version.bind none
hostname Masque le nom du serveur en réponse à une requête hostname.bind  
server-id Masque le numéro de version en réponse à une requete NSID  
listen-on Ecoute les requêtes entrantes sur les adresses IPV4 et ports spécifiés port 53
listen-on-v6 Ecoute les requêtes entrantes sur les adresses IPV6 et ports spécifiés port 53
directory Répertoire de travail du serveur. /var/named
dump-file Localisation du fichier de dump produit par rndc dumpdb /var/named/data/cache_dump.db
statistics-file Localisation du fichier de statistique produit par rndc stats /var/named/data/named.stats
zone-statistics Spécifie le niveau de production des statistiques (full, terse, none) terse -> stats minimales
memstatistics-file Localisation du fichier d'utilisation de la mémoire produit à la sortie de bind. named.memstats
secroots-file Localisation du fichier de sécurité racine produit par rndc secroots /var/named/data/named.secroots
recursing-file Localisation du fichier des requêtes de recursion produit par rndc recursing /var/named/data/named.recursing
allow-query Précise qui est autorisé à interroger le serveur DNS. any
allow-query-on Précise au niveau local qui est autorisé à accepter les requêtes  
recursion Pas de récusion pour les serveurs faisant autorité sur une zone. yes
dnssec-enable Indique si les enregistrements DNSSEC doivent être retournées par named. yes
dnssec-validation Active la validation DNSSEC (auto, yes) si 'auto', une clé par défaut est utilisée. Si positionné à 'yes', la clé doit être produite manuellement. yes
managed-keys-directory Répertoire dans lequel named mémorise les clés DNSSEC qu'il gère. Le fichier porte ne nom 'managed-keys.bind'. managed-keys.bind
pid-file Fichier dans lequel named inscrit son ID de processus  
session-keyfile Fichier dans lequel named écrit la clé de session TSIG utilisée par nsupdate -l.  
notify Autorise la notification des changements apportés à une zone d'un serveur maître. yes
allow-update Spécifie les machines autorisées à soumettre les mises à jour des zones maîtres.  

 

b) Le fichier de zones

# touch /var/named/forward
# vi /var/named/forward
->
$ORIGIN .
$TTL 1209600     ; 2 week
pbr18.fr                IN SOA  sdns0.pbr18.fr. support.pbr18.fr. (
                                2020051312 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                10800      ; minimum (3 hours)
                                )

                        IN      NS      sdns0.pbr18.fr
                        IN      A       15.20.25.30
                        IN      NS      ns6.gandi.net

                10800   IN      MX 10 spool.mail.gandi.net.
                10800   IN      MX 50 fb.mail.gandi.net.
                10800   IN      TXT "v=spf1 include:_mailcust.gandi.net ?all"


$ORIGIN pbr18.fr.
sdns0                   A       15.20.25.30
ns6.gandi.net           A       217.70.177.40
test                    IN      CNAME pbr18.fr.

 

c) Le fichier de zones inversées

# touch /var/named/reverse
# vi /var/named/reverse
->
$TTL 1209600
@               IN      SOA     pbr18.fr.       support.pbr18.fr. (
                                2020051300      ; Serial
                                10800           ; refresh
                                3600            ; retry
                                604800          ; Expire
                                3840     )      ; cache TTL négatif

; Serveurs de Noms
                IN      NS      sdns0.pbr18.fr.
                IN      NS      ns6.pbr18.net.

; Enregistrements PTR
; sdns0
30.25.20.15             IN      PTR     sdns0.pbr18.fr. ; fibre

; gandi
40.177.70.217           IN      PTR     ns6.gandi.net.  ; gandi

En résumé, les fichiers de zone définissent dans le champ SOA le gestionnaire du domaine pbr18.fr (sdns0.pbr18.fr), son point de contact (support@pbr18.fr) - L'@ de l'adresse mail est remplacée par convention par un '.'.

Le domaine est caractérisé par un numéro de série qui devra être incémenté à chaque modification des données de la zone. Ce numéro de série permet de déclencher les transferts entre le maître et le subalterne. Le serveur subalterne rafraichira sa zone sur celle du maître toutes les 2 heures. Si la connexion avec le serveur principal échoue, le serveur subalterne tentera une nouvelle connexion au bout d'une heure. Si le serveur maître ne répond pas, le serveur subalterne prendra seul le relai pendant 7 jours. Passé 7 jours sans réponse du DNS maître, les demandes de résolution sur le domaine ne seront plus assurées.

 

Vérification syntaxique des fichiers de configuration

Bind fourni 2 outils de vérification qui sont bien utiles. Ces ne produisent aucune sortie si tout est syntaxiquement bien écrit. Dans le cas contraire, il précisent les directives en erreur et les lignes incorrectes.

# named-checkconf /etc/named.conf
# named-checkzone pbr18.fr /var/named/forward

 

Droits d'accès sur les fichiers de configuration

Named doit pouvoir lire les fichiers de zone.

# chown :named /var/named/forward /var/named/reverse
# chmod u=rwx,o= /var/named/forward /var/named/reverse

 

Paramètrage selinux

# restorecon -rv /var/named
# restorecon /etc/named.conf

 

Tout est ok. On peut démarrer le service.

# systemctl start named
# systemctl enable named
# systemctl status named
->● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-05-15 11:34:38 CEST; 8s ago
  Process: 1911 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/>
  Process: 1909 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbi>
 Main PID: 1913 (named)
    Tasks: 4 (limit: 11488)
   Memory: 54.3M
   CGroup: /system.slice/named.service
           └─1913 /usr/sbin/named -u named -c /etc/named.conf

mai 15 11:34:38 sdns0.home named[1913]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.>
mai 15 11:34:38 sdns0.home named[1913]: zone pbr18.fr/IN: loaded serial 2020051312
mai 15 11:34:38 sdns0.home named[1913]: zone localhost.localdomain/IN: loaded serial 0
mai 15 11:34:38 sdns0.home named[1913]: all zones loaded
mai 15 11:34:38 sdns0.home named[1913]: running
mai 15 11:34:38 sdns0.home systemd[1]: Started Berkeley Internet Name Domain (DNS).
mai 15 11:34:38 sdns0.home named[1913]: zone pbr18.fr/IN: sending notifies (serial 2020051312)
mai 15 11:34:38 sdns0.home named[1913]: zone 120.150.64.82.in-addr.arpa/IN: sending notifies (s>
mai 15 11:34:38 sdns0.home named[1913]: managed-keys-zone: Key 20326 for zone . acceptance time>
mai 15 11:34:38 sdns0.rpn.home named[1913]: resolver priming query complete

 

7°) Vérification de bon fonctionnement

Pour tester le service DNS, on utilisera l'outil 'dig'.

a) Test du domaine.

# dig pbr18.fr
->; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> pbr18.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55207
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pbr18.fr.                      IN      A

;; ANSWER SECTION:
pbr18.fr.               54065   IN      A       10.15.20.25

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: ven. mai 15 18:02:59 CEST 2020
;; MSG SIZE  rcvd: 53

A la question, quelle est l'adresse IP correspondant au domaine pbr18.fr (QUERY:1), dig a trouvé un enregistrement correspondant (ANSWERS:1). Il s'agit de l'adresse IP externe de la Box : 10.15.20.25. Le serveur DNS qui a reçu la réponse, c'est la Box via le port 53 de son interface interne (SERVER: 192.168.1.1#53), ce qui signifie que le domaine pbr18.fr est bien joingnable via le DNS de notre FAI. C'est donc tout bon.

b) Test d'un enregistrement

# dig test.pbr18.fr
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> test.pbr18.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14396
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.pbr18.fr.                 IN      A

;; ANSWER SECTION:
test.pbr18.fr.          77718   IN      CNAME   pbr18.fr.
pbr18.fr.               77718   IN      A       10.15.20.25

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: dim. mai 17 12:33:22 CEST 2020
;; MSG SIZE  rcvd: 80

Ici encore, la résolution a bien fonctionnée. A la question quel est l'adresse IP de test.pbr18.fr, le serveur trouve deux réponses ; la première pour indiquer que 'test' est bien un sous-domaine existant (CNAME) et que ce sous domaine est généré par le domaine pbr18.fr qui porte l'adresse IP 15.20.15.30

c) Test d'une adresse inexistante

 # dig test1.pbr18.fr
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> test1.pbr18.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2681
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;test1.pbr18.fr.                        IN      A

;; AUTHORITY SECTION:
pbr18.               900     IN      SOA     sdns0.pbr18.fr. support.pbr18.fr. 2020051500 10800 3600 604800 10800

;; Query time: 41 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: dim. mai 17 15:19:46 CEST 2020
;; MSG SIZE  rcvd: 93

Ici, le serveur n'a pas réussi à résoudre l'adresse demandée auprès du serveur DNS qui gère le domaine pbr18.fr, ce qui est normal vue qu'elle n'existe pas. On notera le status qui passe de 'NOERROR' lorsque tout est bon à 'NXDOMAIN' lorsque le sous-domaine demandé n'a pas été trouvé.

d) Test via un DNS externe (Google)

# dig @8.8.8.8 test.pbr18.fr
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> @8.8.8.8 test.pbr18.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24395
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test.pbr18.fr.                 IN      A

;; ANSWER SECTION:
test.pbr18.fr.          21599   IN      CNAME   pbr18.fr.
pbr18.fr.               21599   IN      A       82.64.150.120

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: dim. mai 17 15:27:01 CEST 2020
;; MSG SIZE  rcvd: 72

Ici encore c'est tout bon. Le serveur DNS de Google est capable de résoudre l'adresse test.pbr18.fr.

e) Test du transfert de zone

Pour ce test, on va ajouter à notre DNS interne un nouvel enregistrement pour vérifier qu'il est bien pris en compte sur Internet.

# vi /var/named/forward
-> ...
$ORIGIN .
$TTL 1209600 ; 2 semaines
pbr18.fr IN SOA sdns0.pbr18.fr. support.pbr18.fr. ( 2020051312 10800 3600 604800 10800 )
     IN NS sdns0.pbr18.fr
     IN A 15.20.25.30
     IN NS ns6.gandi.net

$ORIGIN pbr18.fr.
sdns0         A 15.20.25.30
ns6.gandi.net A 217.70.177.40
test          IN CNAME pbr18.fr.
test1         IN CNAME pbr18.fr.

Rappelez-vous, il faut incrémenter le numéro de série à chaque modification puis on ajoute le nouvel enregistrement 'test1' comme ci-dessus. On enregistre ensuite le fichier modifié puis on relance le processus named.

# systemctl restart named
# systemctl status named

# dig +short @8.8.8.8 test1.pbr18.fr
pbr18.fr.
10.15.20.25

C'est tout bon. Notre nouveau sous-domaine 'test1.pbr18.fr' a bien été pris en compte par le DNS de Google quelques secondes après avoir été ajouté. On remarquera que le DNS secondaire lui n'est pas encore capable de résoudre test1.pbr18.fr. La commande dig ne produit pas réponse.

# dig +short @217.70.177.40 test1.pbr18.fr

Il faut attendre le transfert de zone (AXFR) entre maître et subalterne. Celui-ci ne tarde pas à se déclencher automatiquement. Après quelques minutes, on peut le constater dans le fichier /var/named/data/named.log.

17-May-2020 xfer-out: info: client 217.70.177.40#36879 (pbr18.fr): transfer of 'pbr18.fr/IN': AXFR started (serial 2020051700)
17-May-2020 xfer-out: info: client 217.70.177.40#36879 (pbr18.fr): transfer of 'pbr18.fr/IN': AXFR ended

Une fois le transfert achevé, on relance la commande dig pour vérifier que le nouveau sous-domaine est maintenant bien pris en compte en résolution par le DNS subalterne.

# dig +short @217.70.177.40 test1.pbr18.fr
pbr18.fr.
10.15.20.25

Passées toutes ces vérifications, on peut en déduire que notre serveur DNS fonctionne correctement.

 

8°) Le fichier de log

Il est situé dans le répertoire /var/named/data/named.log

Les champs de ce fichier sont :

une @hexadécimal qui représente l'identification du client, son adresse IP et le numéro de port utilisé, le nom de la requête, sa classe et son type.
Le caractère  :
'+' indique si la récursion est demandée dans la requête et '-' dans le cas contraire.
'S' précise si la requête est signée.
'E(#)) indique si EDNS était utilisé, suivi du n° de version.
'T' pour spécifier que TCP a été utilisé.
'D' pour mentionner si DNSSEC était activé
'C' si les vérifications sont désactivées
'V' si un cookie du serveur DNS a été reçu
'K' si le cookie n'est pas validé.

 

9°) Outils de test externe

Voir les paramètres DNS fournis par l'IANA.

Tester votre DNS sur

Vérifier la propagation mondiale de mon DNS

 

Comprendre le DNS

Vaste tâche. J'ai décidé d'écrire cet article suite aux multiples rebondissments dans l'installation d'un serveur DNS. Un coup ça marche et puis d'un seul coup ça ne marche plus. Il suffit parfois d'un rien pour s'attirer les disgraces de bind. Le problème étant qu'une modification peut ne pas affecter de suite le fonctionnement de l'ensemble et qu'il est facile de s'y perdre vu le peu de documentation haut niveau du produit, mis à part la documentation de référence du produit.

Différents serveurs DNS

Le serveur de cache,

Le serveur maître (master) fait autorité sur une zone c'est à dire qu'il est capable de répondre sur sa zone aux demandes qui lui seront présentées compte tenu qu'il possède les enregistrements de la zone.

Le serveur subalterne (slave) dispose d'une copie des enregistrements de la zone gérée par un maître.

Les outils

dig, host, nslookup

named-checkconf, named-checkzone, named-compilezone, rndc

Notification (notify) (RFC 1996)

C'est un mécanisme utilisé par un serveur maître pour notifier que les enregistrements d'une zone ont été modifiées sur le serveur maître et doivent donc être actualisées par un serveur subalterne. Le serveur subalterne compare le n° de version de la zone et si elle est supérieure, il invite le serveur maître à lui tranférer les enregistrements de la zone.

Mise à jour dynamique (dynamic update) (RFC 2136)

La mise à jour dynamique est une méthode qui permet d'ajouter, de supprimer ou de remplacer des enregistrements gérés par un serveur maître en lui envoyant un message spécifique (présiser qui envoie le message). La fonction est activée pour les zones où les clauses allow-update et update-policy.sont spécifiées.

Les changements effectués sont mémorisés dans un fichier journal (*.jnl). La commande rndc stop permet de s'assurer que la zone dynamique est bien à jour.

rndc stop : Arrête la mise à jour dynamique
rndc freeze zone : Désactive la mise à jour dynamique
rndc thaw zone : Réactive la mise à jour dynamique

rndc sync zone : Actualise la zone dynamique sans arrêter la mise à jour dynamique
rndc sync -clean : Supprime le fichier journal après actualisation de la zone.

Transfert incrémental des enregistrements d'une zone (IXFR) (RFC 1995)

Ce protocole permet de transférer aux DNS subalternes les seuls enregistrements modifiés d'une zone en opposition au protocole AXFR qui lui transmet tous les enregistrements de la zone.

Sur des zones dynamiques, le protocole IXFR est utilisé par défaut par le DNS maître et subalterne.
Au niveau du maître, Il est possible de désactiver manuellement IXFR via la directive 'provide-ixfr no' au niveau des options globales du serveur maître.
Au niveau du subalterne, il est possible de forcer le transfert de zone via AXFR via la directive 'request-ixfr no'.

Sur les zones manuelles (non dynamiques), la clause ixfr-from-differences doit être activée (positionnée à 'yes').

ixfr-from-differences yes

Dig : signification des flags

# dig jitsi.pbr.xyz
->
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> jitsi.pbr.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62098
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jitsi.pbr.xyz                 IN      A

;; ANSWER SECTION:
jitsi.pbr.xyz          604788  IN      CNAME   pbr.xyz
pbr.xyz.               590362  IN      A       84.64.154.124

qr : spécifie si la requête est une question (0) ou une réponse (1)
rd : spécifie si la récursion est demandée. Le bit positionné par défault dans la question est recopié dans la réponse pour demander au serveur de nom de poursuivre la recherche de façon récursive.
ra : spécifie si la récursion est autorisée.

Quelques exemples

# dig mx pbr18.xyz +short

Afficher la résolution inversée

# dig -x 8.8.8.8 +short

Tester  la résolution de nom à partir d'un autre DNS (ici celui de Free)

# dig @212.27.40.240 pbr18.xyz +short

Les enregistrement DNS.
A : Renvoie une adresse IPv4 pour un nom de host donné.

  • AAAA : Renvoie une adresse IPv6 pour un nom de host donné.
  • NS : Délègue la gestion d’une zone à un serveur de nom faisant autorité.
  • CNAME : Permet de réaliser un alias d’un host vers un autre.
  • SOA : Définit le Serveur Maitre du domaine.
  • PTR : Réalise l’inverse de l’enregistrement A ou AAAA, donne un nom de host (FQDN) pour une adresse IP.
  • MX : Nom du serveur de courrier du domaine.
  • TXT : Chaîne de caractères libres.

 

-  °°  -