DNS (Domain Name System » ou système de nom de domaine) est un service qui fonctionne comme une sorte d’annuaire pour ordinateur. Le réseau internet ne connaît les machines que par un identifiant unique que l’on nomme
‘adresse IP’, et telle que: 125.51.220.85, Il est facile de comprendre alors que l’humain préfère identifier une machine par un nom propre facilement mémorisable, tels que: ovh.com, mail.ovh.net, domaine.tld par exemple.
Imaginons qu’un serveur recherche l’adresse ip correspondant à ‘domaine.tld’ ? L’illustration ci-contre, montre clairement le processus mis en œuvre.
La machine va commencer par interroger son propre serveur DNS, lequel se retournera alors vers le DNS secondaire qui fournira l’adresse. SI ce dernier ne la connaît pas, le processus de ‘résolution d’adresse’ va se dérouler comme suit :
1. Interroger l’un des 13 serveurs « root’ de la planète,
2. …lequel renverra vers le serveur du ‘top level’ concerné,
3. Interroger le serveur ‘TLD’ concerné
4. … lequel enfin, renverra l’adresse ip de ‘domaine.tld’.
5. Mais ce n’est pas fini, car il faut obtenir de ce dernier serveur, …
6. … l’éventuelle adresse ip ‘autre’ d’un service (nommé ici ‘mail’) qui pourrait ne pas être … logé sur la même machine frontale.
7. Cette machine conservera en mémoire cette adresse, pour ne plus avoir à la redeman- der par la suite.
Dans la hiérarchie des serveurs dns, le domaine racine « . » est géré par l13 serveurs DNS nom-més « <x>.root-servers.net », où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN et WIDE). Afin d’assurer le bon maintien du service, ces serveurs sont ‘redondés’, soit localement, soit de manière répartie
Les domaines du niveau suivant son appelés DNS de premier niveau ou TLD (Top Level Domain). Ce sont les » .com », » .net », » .org », etc Enfin, les domaines de second niveau (SLD) représentent des organisations plus précises, telles que » fnac.fr », » amazon.com », etc …
Au sein d’une même organisation, un troisième niveau permet de préciser des » hôtes » plus spécialisés, comme par exemple un serveur mail qui sera accessible à : mail.masociete.fr, ou un blog d’entreprise sur » blog.masociete.fr » .. etc..
Un nom de domaine, lors de sa définition auprès d’un « registrar » (bureau d’enregistrement officiel), doit désigner au moins deux serveurs DNS qui seront prioritairement interrogés : Le DNS primaire (Sur la machine l’hébergeant ou sur son propre serveur), et un DNS secondaire, » de secours », passif, et qui pourra suppléer à une panne du premier (en général, celui du FAI (fournisseur d’accès à l’Internet), ou un second serveur chargé de cette mission.
Enfin, les services DNS utilisent un système de « cache », pour ne pas avoir à redemander à chaque fois la même information à ses « confrères ». il mémorise donc les réponses précédente durant un certain temps.
2. OPÉRATIONS PRÉALABLES CHEZ L’HÉBERGEUR DU DOMAINE
Nous prendrons pour exemple une console d’administration OVH
- Web > Domaines > domainepme.tld > Zones DNS
Bouton : Supprimer la zone DNS Hébergée
+ Valider la demande reçue par email
=> Attendre un certain temps que » vous n’avez pas de zone DNS » soit affiché. - Web > Domaines > domainepme.tld > Serveurs DNS :
– Changer le DNS primaire : ns.domainepme.tld & 111.22.333.44
– Supprimer le DNS secondaire (pour l’instant) - Web > Domaines > domainepme.tld > Redirections
Supprimer toutes redirections - Web > Domaines > domainepme.tld > Glue
Ajouter un « glue record » en associant 111.22.333.44 avec le domaine domainepme.tld (Quand un domaine est délégué à un serveur de nom qui appartient lui-même au même domaine (Dans notre cas il s’agit de ns.domainepme.tld au sein de domainepme.tld), il est nécessaire de fournir également l’adresse IP pour éviter les «références circulaires».
3. INSTALLATION DES PAQUETS REQUIS, DROITS SUR RÉPERTOIRE
su
# Mise à niveau du système
apt-get update
apt-get upgrade
# Installation de Bind9
apt-get install bind9 bind9-doc dnsutils
4. CONFIGURATION GÉNÉRALE DU SERVICE DNS
On édite le fichier général de configuration locale
nano /etc/bind/named.conf.options
et on y place :
#
# Options générales applicables à toutes zones
#
options {
directory « /var/cache/bind » ;
# Transmettre requête à un DNS externe, si non résolution possible
# forwarders { 0.0.0.0 ; } ;
# dnssec
dnssec-validation auto ;
auth-nxdomain no ; # RFC1035
# Interfaces et protocoles d’écoute
listen-on { any ; } ;
listen-on-v6 { none; } ;
# Autoriser les requêtes récursives en local uniquement
allow-recursion { 127.0.0.0/8 ; } ;
# Aucune autre machine ne peut mettre à jour les zones maîtres
allow-update { 127.0.0.0/8 ; } ;
# Tout le monde peut interroger le serveur, sauf pour l’accès au cache
allow-query { any ; } ;
allow-query-cache { 127.0.0.0/8 ; } ;
# Masquage du serveur
version « not available » ;
hostname none ;
server-id none ;
};
5. DÉCLARATION DES ‘ZONES’ AUTORITAIRES DU DNS PRIMAIRE
On déclare les « zones » de domaines prises en charge:
nano /etc/bind/named.conf.local
5.1 Définition de la zone assurant la résolution de domaine domainepme.tld
zone « domainepme.tld » {
type master ;
file « /etc/bind/zones/domainepme.tld » ;
notify yes ;
update-policy {
grant letsencrypt name _acme-challenge.domainepme.tld. TXT;
};
};
Nous donnons les droits d’accès à Let’s encrypt concernant l’entrée DNS qui le concerne pour l’obtention de notre certificat. (voir cela plus loin)
5.2 Zone DNS reverse (assure l’opération inverse pour retrouver un domaine à partir d’une adresse IP. Le nom de la zone est constitué des trois premiers nombres inversés de l’adresse IP + » .in-addr.arpa ».) Le nombre 4 se retrouvera dans la zone inverse détaillée (voir plus loin).
zone « 333.22.111.in-addr.arpa » {
type master ;
file « /etc/bind/zones/rev.domainepme.tld » ;
notify yes ;
};
NB: L’adresse reverse arpa qualifiée étant: 44.33.22.11.in-addr.arpa.
6. CRÉATION DES FICHIERS DÉTAILLÉS DE CHAQUE » ZONE »
6.1 On crée le répertoire des fichiers de zones et l’on y crée les fichiers détaillant les deux zones déclarées précédemment.
mkdir /etc/bind/zones (sauf si existant)
6.2 On édite la zone du domaine:
nano /etc/bind/zones/domainepme.tld
NB : Certains sous-domaines sont définis par anticipation
$TTL 3600
domainepme.tld. IN SOA ns.domainepme.tld. debian.domainepme.tld. (
2019050516 ; No de série
14400 ; Refresh
3600 ; Retry
1209600 ; Expire
3600 ) ; Minimum
;
domainepme.tld. IN NS ns.domainepme.tld.
domainepme.tld. IN NS sdns2.ovh.net.
ns.domainepme.tld. IN A 111.22.333.44
domainepme.tld. IN A 111.22.333.44
www.domainepme.tld. IN A 111.22.333.44
ftp.domainepme.tld. IN A 111.22.333.44
phpmyadmin.domainepme.tld. IN A 111.22.333.44
blog.domainepme.tld. IN A 111.22.333.44
erp.domainepme.tld. IN A 111.22.333.44
Attention le ‘point terminal’ des noms de domaines mentionnés dans une zone DNS est ‘vital’. Ce point représente en effet la ‘racine absolue, soit l’internet lui-même’ ! En outre, différentes syntaxes sont possibles, notamment en utilisant l’alias ‘CNAME’, pour ne pas répéter l’adresse IP.
Certains sous-services (DNS secondaires, phpmyadmin, blog, erp, sont ici ‘anticipés’
- ‘IN’ Signifie une zone DNS à usage de ‘INTERNET’
- $TTL : (Time To Live) exprime la durée (sec) de validité des informations contenues dans votre fichier de zone. Une fois ce délai expiré, les autres serveurs DNS doivent vérifier à nouveau les enregistrements.
- SOA : permet de définir les informations relatives à la zone. En l’occurrence le nom du serveur DNS primaire et le mail du contact technique (hostmaster.domainepme.tld. le symbole @ est remplace par un point). Cet enregistrement est composé de plusieurs champs :
- Serial : est un entier non signé de 32 bits. C’est le numéro de série qui devra être incrémenté à chaque modification du fichier. Cela permet aux serveurs secondaires de savoir si une modification a été apportée au fichier de zone principal. Le « serial » est généralement formaté à partir de la date de modification de la zone, AAAAMMDDXX, par exemple pour le 20/10/2014 => 2014102001 (première modification), 2014102002 (deuxième modification), ou heure.
- Refresh : définit la période de rafraîchissement des données.
- Retry : si une erreur survient au cours du dernier rafraîchissement, celle-ci sera répétée au bout du délai Retry.
- Expire : le serveur sera considéré comme non disponible au bout du délai Expire.
- Negative cache TTL : durée de vie d’une réponse NXDOMAIN de notre part.
6.3 On édite la zone ‘’inversée’’
nano /etc/bind/zones/rev.domainepme.tld
et y placer:
$TTL 3600
@ IN SOA ns.domainepme.tld. debian.domainepme.tld. (
2019050516 ; No de série
14400 ; Refresh
3600 ; Retry
1209600 ; Expire
3600 ) ; Minimum
;
IN NS ns.domainepme.tld.
44 IN PTR ns.domainepme.tld.
44 IN PTR domainepme.tld.
44 IN PTR www.domainepme.tld.
44 IN PTR ftp.domainepme.tld.
44 IN PTR phpmyadmin.domainepme.tld.
44 IN PTR blog.domainepme.tld.
44 IN PTR erp.domainepme.tld.
Le nombre en début de ligne (44) représente le dernier nombre de l’adresse IPV4. Il représente le ‘host’ ou service final (souvent adossé au service générique ‘www’). Si un domaine gère une » classe ‘C’ » (aa.bb.cc.*),
il peut gérer un sous-réseau de 256 machines possibles. ce nombre (44) peut ainsi varier et être associé à différents services hébergés sur d’autres machines spécialisées, au sein dudit réseau adossé au domaine.
Le commentaire « No de série » ne doit pas être modifié, et les paramètres SOA doivent être sur des lignes distinctes. Nous verrons pourquoi plus loin, car ceci sera utilisé comme « repère » par un « hook » de Let’s Encrypt.
Rappel concernant les réseaux accessibles selon la classe d’adresse
Classe B : aa.bb.xxx.yyy = 256 x 256 = 65.536 machines
Classe A : aa.xxx.yyy.zzz = 256 x 256 x 256 = 16.777.216 machines
7. TESTS DE LA CONFIGURATION DNS
7.1 Test de named.conf
# Répertoire de Bind9
cd /etc/bind# Vérifier la cohérence de la configuration du DNS bind
named-checkconf /etc/bind/named.conf.local
Si aucun message d’erreur n’apparaît c’est que tout fonctionne.
7.2 Test des fichiers de zones (domaine et adresse inversée)
# Répertoire des ‘zones’ associées aux domaines
cd /etc/bind/zones
# Vérifier la syntaxe de la zone associée au domaine
named-checkzone domainepme.tld domainepme.tld
# Vérifier la syntaxe de la zone inverse associée au domaine
named-checkzone 333.22.111.in-addr.arpa rev.domainepme.tld
Si ces vérifications ne posent aucun problème, bind indiquera (pour chaque named-checkzone) que la zone concernée a été chargée et indiquera aussi le No de série
7.3 Forcer bind à prendre en compte notre configuration.
systemctl bind9 start (ou reload si correctif à chaud)
7.4 Relancer la procédure de demande de prise en charge du domaine sur le DNS secondaire d’OVH dans le manager. Les étapes seront les même que précédemment.
8. TEST DU SERVEUR DNS PRIMAIRE
On teste à présent si notre serveur DNS répond correctement aux demandes depuis l’extérieur. Grâce à la commande nslookup (disponible dans le paquet dnsutils) on commence par tester si la résolution de domaine fonctionne.
cd /etc/bind/zones
nslookup domainepme.tld. domainepme.tld
9. DÉFINITION ET PRISE EN CHARGE DU DNS SECONDAIRE PAR L’HÉBERGEUR
Nous nous rappelons que nous prenons pour exemple OVH. Chez d’autres hébergeurs, le principe général reste le même.
Concernant le nom de domaine, vu de OVH :
Web > Domaines > domainepme.tld > Serveurs DNS :
- Ajouter le DNS secondaire sdns2.ovh.net & 213.251.188.141
(ce serveur dns secondaire est en principe affecté aux serveurs dédiés et VPS)
Concernant le VPS, vu de OVH :
Servers > VPS > MONVPSWEB > DNS secondaire -> Ajouter un domaine
- On demande la prise en charge de domainepme.tld par les DNS secondaire d’Ovh. Le nom de domaine ne doit pas être précédé de « www » ou de tout autre préfixe.
- On valide la demande d’ajout, et OVH communique alors un code » ownercheker », (pour vérifier notre réelle autorité sur le domaine). Cette 1ère demande est ignorée apr OVH.
- Ajouter une entrée » TXT » à la zone DNS de, /etc/bind/zones/domainepme.tld sans oublier d’incrémenter le no de série de la zone, et tel que suit :
$TTL 3600
domainepme.tld. IN SOA ns.domainepme.tld. debian.domainepme.tld. (
2019050518 ; No de série
14400 ; Refresh
3600 ; Retry
1209600 ; Expire
3600 ) ; Minimum
;
domainepme.tld. IN NS ns.domainepme.tld.
domainepme.tld. IN NS sdns2.ovh.net. # par anticipation
ns.domainepme.tld. IN A 111.22.333.44
domainepme.tld. IN A 111.22.333.44
www.domainepme.tld. IN A 111.22.333.44
ftp.domainepme.tld. IN A 111.22.333.44
phpmyadmin.domainepme.tld. IN A 111.22.333.44
blog.domainepme.tld. IN A 111.22.333.44
erp.domainepme.tld. IN A 111.22.333.44
; code fourni par OVH pour s’assurer de notre contrôle légal de la machine
ownercheck.domainepme.tld. IN TXT « 17f4bb96 »
- Contrôler et recharger les zones,
- Relancer le serveur DNS BIND9,
Attendre un petit moment,…. - Réitérer la demande de prise en charge du domaine par les DNS secondaires d’OVH, (Cloud > Serveurs > MONVPSWEB > DNS secondaire -> Ajouter domaine )
- Vérifiez ensuite que le serveur de nom secondaire qui nous est attribué, est bien celui que nous avions anticipé.(sdns2.ovh.net)
10. TEST DU SERVEUR DNS SECONDAIRE
Afin de s’assurer qu’il a bien copié le fichier de résolution de domaine, on peut utiliser la première fonction nslookup en remplaçant le nom de domaine, par celui du serveur de nom secondaire (ici sdns2.ovh.net).
On peut aussi utiliser la commande dig qui fournit des informations très utiles, notamment concernant les DNS gérant le domaine domainepme.tld.
dig domainepme.tld +nssearch
=> SOA ns.domainepme.tld debian.domainepme.tld. 0123456789 3600 600 [. . .] 600 from . .
=> SOA ns.domainepme.tld. debian.domainepme.tld. 0123456789 3600 600 [. . .] 600 from . .
On voit ainsi que deux serveurs de noms, gèrent le domaine et possèdent le même no de version 0123456789 (no aléatoirement pris pour cet exemple). Important:
- Si le serveur secondaire ne répond pas, c’est qu’il n’a pas encore chargé vos fichiers de zone. Il faudra alors attendre que cela soit fait pour continuer (délai de propagation).
- S’il répond, on pourra alors s’assurer que la configuration définie est bien valide grâce au site https://www.zonemaster.fr/.
11. TEST DE SÉCURITÉ EXTERNE DU DNS
https://www.ovh.com/fr/cgi-bin/tools/dns_security.cgi
12. APRÈS 24h00, … MODIFICATION DU REVERSE DNS
Dans la console OVH, Sur le tableau de bord de votre « IP », Modifiez le reverse DNS fourni par OVH (ici : vps-e688999.vps.ovh.net.) : en associant: à l’adresse IP 111.22.333.44 le nom de domaine suivant : ns.domainepme.tld.
Après cela, attendre aussi 24h00 pour une propagation complète