Provision du Datacenter - Installation du DNS Bind9 - [Raspberry PI/Rock64]

Fin d’utilisation, j’ai remplacé les service DNS/DHCP (Bind9/isc-dhcp-server) par Technitium DNS qui implémente aussi le service DHCP et la mise à jour dynamique du DNS.

[ NIVEAU ] Débutant
Cette procédure permet l’installation du service Bind9, qui est l’implémentation d’un service DNS (Domain Name System).

[ INTEGRATION MYTINYDC-IM ] en cours… ( voir Gestionnaire de datacenter )

Pré-requis

Pour exécuter cette opération vous devez :

• avoir suivi la procédure : Initialisation du Datacenter
• savoir exécuter une commande dans une console Linux
• savoir utiliser l’éditeur “vi”
• être connecté “root” à la console, pour les utilisateur sudo : tapez sudo bash

A quoi sert un DNS (Domain Name System) ? Explications en une image

(source)

Traduction :

1. J’ai besoin de la destination pour joindre “www.howstuffworks.com”
2. Ce nom de domaine n’est pas dans mon cache, j’essaie un autre serveur DNS.
3. Ok l’adresse IP de ce domaine est 70.42.251.42.
4. Je cache cette information dans le cas où j’ai à répondre de nouveau à cette même requête.
5. Merci de m’avoir indiqué la destination. Fin

L’implémentation Mytinydc

Le Datacenter dispose de son propre réseau de communication. Chaque serveur intégré dans le Datacenter fait partie du domaine Internet attribué au Datacenter et interroge le service DNS du Datacenter. Comprenez que les serveurs n’interrogent pas directement les serveurs DNS disposés sur l’Internet.
Si vous souhaitez utiliser le service DNS de votre Datacenter à partir de votre réseau domestique, vous devrez paramétrer votre réseau domestique (Box Internet).
Ceci s’opère généralement au travers de la configuration du service DHCP de votre Box Internet. Dans la zone “adresse du serveur DNS”, indiquez l’adresse “externe” du Datacenter (interface réseau exposée sur votre réseau domestique). Ainsi les machines de votre réseau domestique utiliseront le service DNS du Datacenter et pourront ainsi joindre les services de ce dernier (nextcloud, matrix,…).

Installation des paquets nécessaires

Exécutez la commande :

apt-get -y install dnsutils bind9

Ouverture des ports de communication (Firewall)

Pour offrir ce service, le serveur devra répondre aux différentes requêtes des machines clientes et également demander la résolution auprès d’autres serveurs DNS dans le cas où le domaine demandé n’est pas géré par celui-ci. Ce tableau est fourni à titre indicatif, car votre unité ne dispose pas, pour l’instant, d’un système de Firewall actif :

Interactions entre le service DHCP et le service DNS.

Le service DNS est autonome et contient la description des associations :

• nom de serveur ou de service / adresse IP (forward)
• et l’inverse, adresse IP / nom de serveur ou de service (reverse)
• alias de noms (cname), qui une référence à un nom déjà existant.

Ce service est géré au travers de fichiers, que l’administrateur complète manuellement en décrivant les associations.
Un mécanisme permet, en partie, une gestion automatisée à partir des informations reçues du service DHCP.

DHCP (Dynamic Host Configuration Protocol)

Ce service est chargé de distribuer les adresses IP sur un réseau informatique. Sa fonction est de décrire les machines connectées au réseau, et les informations générales du réseau (passerelles inter-réseaux (gateway), adresse des DNS des serveurs BOOTP,…).
Une fois l’adresse IP distribuée à la machine connectée, le service DHCP se connecte au service DNS, après authentification, le service DHCP envoie le nom hôte et l’adresse IP distribuée au service DNS qui met à jour les fichiers d’associations “nom/adresse IP” et/ou l’inverse selon les choix de l’administrateur.

Authentification auprès du service DNS

Pour autoriser la communication entre ces deux services (DNS et DHCP), nous allons générer une clé d’authentification sur le serveur DNS en exécutant ces opérations :

# Connecté "root" au futur serveur DNS.
# Installer les paquets nécessaires (voir ci-avant).
# Création de la clé d'authentification :
rndc-confgen -a
Le fichier "/etc/bind/rndc.key" a été créé

Modifiez les autorisations du fichier avec les commandes :

chown root:bind /etc/bind/rndc.key
chmod 640 /etc/bind/rndc.key

Standardisation

Généralement, les services DHCP et DNS sont disposés sur un seul serveur et vous ne voyez donc pas l’utilité du mécanisme d’authentification. Ce dernier deviendra nécessaire si vous souhaitez déplacer un de ces services vers un autre serveur. En standardisant l’authentificatioin dès l’installation, le déplacement d’un de ces services vers une autre machine ne sera qu’une simple formalité.

Création du domaine

Dans cette documentation, le domaine à gérer est nommé “mondc”, le réseau utilisé est : 172.21.0.0/24, l’adresse email de l’administrateur est “root@mondc”, le nom du serveur DNS est raspi1.

Les DNS gèrent les zones de type “forward” et “reverse”. Les zones “forward” permettent la résolution : Nom de domaine vers adresse IP. Les zones “reverse” permettent la résolution : Adresse IP vers Nom de domaine. Vous pouvez disposer de plusieurs noms pour une seule adresse IP (forward), mais un seul nom pour une adresse IP (reverse).

Toutes les configurations qui suivent devront être adaptées à votre infrastructure.

Le fichier de zones

Les fichiers de zones sont les bases de données contenant les associations pour chacune des zones gérées par le DNS. Ces zones sont décrites dans le fichier "/etc/bind/named.conf.local".

//
// Do any local configuration here
//

include "/etc/bind/rndc.key";

zone "mondc" {
        type master;
        allow-update { key rndc-key;};
        allow-query {any;};
        file "/var/cache/bind/db.mondc";
        };

zone "0.21.172.in-addr.arpa"{
        type master;
        allow-update { key rndc-key;};
        allow-query {any;};
        file "/var/cache/bind/db.172.21.0.0";
};

Dans ce cas, la configuration du service DNS décrit deux zones :

• “mondc”
• “0.21.172.in-addr.arpa”

Une zone peut être de type “forward” ou “reverse”.

Explications concernant le fichier de zones

Le fichier de zones est constitué de plusieurs blocs qui décrivent la zone :

• Le bloc commence par le mot clé “zone” suivi du nom de la zone. Pour les zones inversées (in-addr.arpa), l’adresse du réseau géré est inversé, toujours sans les digits variables du réseau (sous-réseau), et toujours suivi du mot clé “.in-addr.arpa”
• type défini le type de DNS, sa valeur peut être “master” ou “slave”. Nous aborderons pour l’instant que le cas “master”, “slave” est utilisé dans le cadre d’une réplication
• allow-update est une option, il s’agit de la clé utilisée pour autoriser les mises à jour automatique par des services tiers, en l’occurrence, le service DHCP
• allow-query défini les hôtes autorisés à interroger votre serveur DNS. Par défaut, bind autorise tout le monde. J’indique cette ligne pour des raisons de compréhension bien qu’elle ne soit pas nécessaire dans mon cas. Sa valeur peut être une adresse IP (192.168.1.20), un réseau (192.168.1.0/24) , ou tout le monde représenté par “any”. Il est possible de gérer des “listes d’accès (access-lists)”, non abordé ici (mot clé acl).
• file indique le nom du fichier de la base de donnée des hôtes gérés. Par défaut et sur les distributions DEBIAN, ces fichiers sont situés dans le répertoire "/var/cache/bind/"

Attention à bien respecter cette syntaxe.

Le fichier des hôtes d’une zone de type “forward”

Le nom du fichier sera “/var/cache/bind/db.mondc”, comme indiqué dans le fichier de description de zones “/etc/bind/named.conf.local” :

$ORIGIN .
$TTL 3600       ; 1 hour
mondc  IN   SOA   raspi1. root.mondc. (
                    1505024492
                    10800
                    3600
                    604800
                    38400
                    )
        NS          raspi1.mondc.
        MX          0 raspi1.mondc.
$ORIGIN mondc.
$TTL 3600       ; 1 hour
raspi1                  A       172.21.0.1

Le fichier des hôtes d’une zone de type “reverse”

Le nom du fichier sera “/var/cache/bind/db.172.21.0.0” , comme indiqué dans le fichier de description de zones “/etc/bind/named.conf.local” :

$ORIGIN .
$TTL 3600       ; 1 hour
0.21.172.in-addr.arpa   IN      SOA    raspi1. root.mondc. (
                                        1505024492 ;serial
                                        10800 ;refresh
                                        3600 ;retry
                                        604800;expire
                                        38400;minimum
                                        )
                        NS      raspi1.mondc.
$ORIGIN 0.21.172.in-addr.arpa.
$TTL 3600       ; 1 hour
1	PTR   	raspi1.mondc.

Explications concernant les fichiers des hôtes

Cette documentation explique clairement et simplement une configuration DNS. Le site web de cette personne ne présente pas d’adresse email, je n’ai par conséquent pas pu la contacter en vue de lui demander son autorisation pour le citer. En cas de litige, je m’engage à supprimer ses citations de ce document.
Description de la zone :

• le @ à peine visible au début de l’enregistrement est une manière simplifiée de définir la zone, ici “mondc”.
  Cette définition est conforme à la description contenue dans le fichier de description de zones “/etc/bind/named.conf.local”

• ensuite, le TTL. Comme elle ne diffère pas de celle qui a été définie dans $TTL, il est inutile de spécifier une valeur

• puis apparaît la classe, IN. On pourra parfaitement, dans la suite du fichier, se dispenser de la préciser

• après, le type d’information. Sur un serveur maître, il existe nécessairement un et un seul enregistrement SOA (Start of Authority), et c’est toujours le premier enregistrement hôte du fichier de zone.

• pour finir, les données. En l’espèce, elles sont particulièrement fournies puisqu’on trouve :

  • raspi1., le nom pleinement qualifié du serveur de nom (FQDN). On ne manquera pas de noter le . si discret à droite du “fr” et caractéristique de ces noms absolus. Il permet à “bind” de remonter au sommet de l’arborescence des noms. Ce champs est aussi nommé «hostmaster» (source - en anglais) :

• root.mondc. est la manière particulière dont “bind” prend en compte l’adresse électronique de l’administrateur du serveur, avec un . à la place de @, le point de la fin est important.

• ensuite, entre (), un certain nombre de paramètres suivis de commentaires introduits par un ;, à savoir :

  • d’abord un numéro de série que l’on ne doit pas oublier d’incrémenter à chaque modification du fichier. Ce numéro permet aux serveurs esclaves d’être informés d’opérations de modifications sur les fichiers hôtes. Il est d’usage de choisir un numéro du type “yyyymmdd”, suivi d’un numéro d’ordre, mais cela n’est nullement obligatoire, l’important étant que ces numéros soient toujours croissants.
  • “refresh”, “retry”, et “expire” sont des délais, exprimés en secondes, qui vont piloter le comportement des serveurs esclaves. A l’expiration du délai refresh, l’esclave va entrer en contact avec le maître ; s’il ne le trouve pas, il essaiera de nouveau à la fin du délai retry. Et si, au bout du délai expire, il n’est pas parvenu à ses fins, il considérera que le serveur maître a été retiré du service.
  • “minimum” détermine, toujours en secondes, la durée de vie minimum du cache. On remarque la disposition des parenthèses, obligatoire pour disposer les informations sur plusieurs lignes.

Les enregistrements NS et MX

La configuration de la zone est suivie des enregistrements NS et MX. Ces enregistrements doivent mentionner le nom du domaine auquel ils appartiennent (ex : raspi1.mondc.).

NS décrit le serveur DNS de la zone, vous pouvez disposer de plusieurs enregistrements de ce type

MX décrit le serveur d’email de la zone, vous pouvez disposer de plusieurs enregistrements de ce type. MX est toujours suivi d’un chiffre qui représente sa priorité par rapport aux autres enregistrements MX de la zone (ex : MX 10 raspi1.mondc.).

@ORIGIN indique le nom de domaine à ajouter à tous les enregistrements qui suivent cette ligne. Ceci permet à l’administrateur de limiter la saisie des enregistrements. Exemple :

@ORIGIN mondc.
raspi1                  A       172.21.0.1

Le nom de domaine complet de cet enregistrement sera bien “raspi1.mondc.”

Les enregistrements de type “hôte”

Chaque enregistrement de type “hôte” contient normalement cinq champs, séparés par un espace ; on verra pourquoi il existe quelques exceptions. Ces cinq champs sont :

• d’abord, le nom du domaine.
• ensuite, la durée de validité de l’enregistrement appelée TTL (Time To Live).
• la classe, c’est à dire le protocole utilisé ; aujourd’hui, seul subsiste IN pour Internet
• puis le type d’information contenu dans l’enregistrement.
• et enfin les données elle-mêmes ; en fonction du type de données, ce champ contiendra des informations de nature différente. (source)

Alias de nom de domaine

Ce type d’enregistrement est défini par le mot clé “CNAME” et permet de créer un alias de nom de domaine sans devoir répéter l’adresse IP. Ce type d’enregistrement n’est utilisé que dans les zone de type “forward”. Les serveurs de type Apache, nginx peuvent héberger de manière mutualisée plusieurs sites web ayant un nom de domaine différent (Virtual hosts). Ainsi plusieurs noms de domaine disposeront de la même adresse IP. L’utilisation d’alias permet de faciliter la gestion des DNS, un exemple : vous disposez d’un serveur mutualisé, pour une raison quelconque, ce serveur doit changer d’adresse IP, au lieu de modifier chacun des noms de domaine impactés, vous n’aurez qu’une seule ligne à changer.

#Exemple :
monsiteweb1	A 172.21.0.20
monsiteweb2 CNAME monsiteweb1
monsiteweb3 CNAME monsiteweb1
[..]

Fichier complémentaire “/etc/bind/rndc.conf”

Le paquet “Bind9” est livré avec un utilitaire appelé “rndc”, qui permet d’utiliser des lignes de commande pour administrer le service DNS.

Afin d’empêcher l’accès non-autorisé au démon “named”, “bind” utilise une méthode d’authentification à clé secrète partagée pour accorder des privilèges aux hôtes. Ainsi, une clé identique doit être présente aussi bien dans “/etc/bind/named.conf” que dans le fichier de configuration de rndc, à savoir “/etc/bind/rndc.conf” (source)

Ce service est installé et configuré par défaut sur DEBIAN lors de l’installation du paquet “Bind9”, vous n’avez par conséquent rien à paramétrer.

Si vous souhaitez re-configurer ce dernier, voir ici.

Exemple de fichier /etc/bind/rndc.conf :

# Start of rndc.conf
key "rndc-key" {
        algorithm hmac-md5;
        secret "clé secrete";
};

options {
        default-key "bind.keys";
        default-server 127.0.0.1;
        default-port 953;
};
# End of rndc.conf

Résolution des autres domaines

Bind9 peut résoudre les domaines qu’il ne gère pas auprès d’autres serveurs DNS. Ceux-ci peuvent être les DNS primaires de l’Internet ou bien les DNS de votre choix.

En interrogeant les DNS primaires

Dans sa configuration d’origine, Bind9 pour DEBIAN inclus la recherche auprès des DNS internationaux, la fonction “Forward” n’est donc pas activée. Le serveur DNS se charge lui même de résoudre les noms qui ne font pas partie des domaines qu’il gère, auprès des DNS primaires de l’Internet. Pour retrouver cette liste, consulter le fichier mentionné dans la zone “.” du fichier de configuration "/etc/bind/named.conf.default-zones".

En interrogeant un autre DNS

Celui-ci peut-être celui de votre fournisseur d’accès à Internet, ou bien celui fournis par OPENDNS, etc…

La configuration de ce type se nomme “forwarders” et se configure au travers du fichier /etc/bind/named.conf.options. Pour activer ce type de configuration, dé-commentez les lignes :

// forwarders {
//      0.0.0.0;
// };

comme suit, et indiquer la ou les adresses de DNS de votre choix, exemple avec OPENDNS :

options {
[...]
forwarders {
   //serveur primaire
   208.67.222.222;
   //serveur secondaire
   208.67.220.220;
};
//ajoutez cette règle
forward only;
[...]
}

Puis redémarrez le service :

systemctl restart Bind9

Activation dnssec

Le protocole dnssec permet d’assurer la réponse d’un requête DNS (Voir cet article fournit par Wikipédia).
Pour activer dnssec, modifiez le fichier /etc/bind/named.conf.options comme suit :

options {
        directory "/var/cache/bind";

[...]
        dnssec-enable yes;
        dnssec-validation yes;
[...]
};

Puis redémarrez le service :

systemctl restart Bind9

Desactivation IPV6

Mon Datacenter n’utilise pas IPV6, j’ai désactivé cette fonctionnalité pour éviter les erreurs dans le logs (/var/log/syslog).
Toujours dans le fichier /etc/bind/named.conf.options, commentez la ligne : “listen-on-v6 { any; };” comme suit :

options {
        directory "/var/cache/bind";
...
        //listen-on-v6 { any; };
};

Puis redémarrez le service :

systemctl restart Bind9

Modification du paramétrage de résolution

Une fois le service DNS installé et démarré, modifiez le fichier /etc/resolv.conf comme suit et en adaptant le contenu à votre configuration :

domain [votre domaine]
nameserver [Adresse IP de votre serveur DNS]

La ligne commençant par domain indique que votre machine appartient au domaine spécifié, chaque tentative de résolution d’un nom, sans suffixe de domaine, obligera le client DNS à rechercher dans la zone définie par domain. Exemple : avec domain défini avec “mondc”, tentez de resoudre “raspi.mondc” ou “raspi” est équivalent. Ceci évite de devoir tapez le domaine quand vous êtes situé dans le domaine.

La ligne nameserver, il peut y en avoir plusieurs indique, dans l’ordre de priorité, les adresses IP des DNS chargés de répondre aux différentes requêtes de résolutions de noms par cette machine.

Important : Empêcher l’altération de ce fichier par le service DHCP client :

chattr +i /etc/resolv.conf

Avant de modifier à nouveau ce fichier exécutez la commande :

chattr -i /etc/resolv.conf

Remarques importantes

Les fichiers de configuration du service DNS de mon Mytinydc définissent seulement le serveur DNS de la zone. Toutes les unités de mon Datacenter sont paramétrées pour obtenir une adresse IP sur le réseau. La mise à jour du service DNS est automatisée au travers de l’interaction service DHCP/service DNS (voir le chapitre service DHCP).

Test de fonctionnement

Exécutez la commande host suivi du nom de votre dns, comme indiqué dans votre configuration vous devez obtenir l’adresse IP associée. Exemple :

host raspi1
## réponse
raspi1.mondc has address 172.21.0.1

host raspi1.mondc
## réponse
raspi1.mondc has address 172.21.0.1

Pour une utilisation plus avancée, utilisez la commande dig.

Duplication de domaine Internet sur un réseau local

Ceci permet une économie de la bande passante Internet et une simplification des configurations de services. Prenons l’exemple du site web “mytinydc.com”. Il est hébergé sur mon datacenter. Quand je le consulte en “local”, je n’ai pas besoin de sortir vers l’Internet. Pour réaliser cet exercice, j’ai déclaré sur le DNS du datacenter la zone “mytinydc.com”, et modifié les adresses IP finales vers des adresse IP locales. Si le datacenter est isolé de l’Internet j’ai toujours accès en local à mon site sans changer les paramètres. J’ai donc deux zones à gérer mais ceci reste bien moins compliqué que de devoir gérer deux domaines différents, et qui m’obligerait en “local” à utiliser un autre domaine pour joindre ce même service.

Pour réaliser complètement cette configuration vous devez indiquer dans le le fichier /etc/resolv.conf le nom du DNS de votre Datacenter en premier de la liste des DNS supportés. Exemple :

# DNS votre daacenter
nameserver 192.168.1.15
# DNS OPENDNS
nameserver 208.67.222.222

Si vous tapez l’inverse, le DNS renverra l’adresse du serveur situé sur l’Internet.

Erreurs rencontrées

Le service Bind9 prend beaucoup de temps pour s’arrêter ou redémarrer

Il s’agit d’un problème situé au niveau du Firewall.

Source […] The named listens on two ports — port 53 on all network interfaces, and port 953 on the loopback interface (the latter being DNS RNDC Service). Both port numbers are mentioned in your log snippet.When it is being stopped/restarted, named waits for something on the port 953, and it hangs for a long time if the port is blocked by the firewall. So the solution is to allow incoming connections to the port 953 on the loopback interface:

Ajoutez ces règles :

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -p tcp --dport 953 -j ACCEPT
iptables -A OUTPUT -o lo -p tcp -m tcp --sport 953  -m state --state RELATED,ESTABLISHED

Erreur failed: journal out of sync with zone

Exemple dans le fichier /var/log/syslog :

Oct 18 19:54:35 raspi1 named[29551]: zone mondc/IN: journal rollforward failed: journal out of sync with zone

Cette erreur apparaît quand le “serial” de la zone est inférieur au dernier enregistré par bind. La solution est de supprimer le fichier journal (extention jnl) dans le répertoire /var/cache/bind.

rm /var/cache/bind/mondc.db.jnl
# Redémarrer le service DNS
systemclt restart Bind9

FAILED: Has an address record but no DHCID, not mine.

Exécuter :

# refuser les demandes d'update de zones
rndc freeze
# ouvrir le fichier de zone DNS impacté /etc/bind/[nom du fichier de zone]
# supprimer toutes les entrées suivi de TXT, (y compris la ligne TXT)
# autorise les demandes d'update de zone et relecture complète de la configuration DNS
rndc thaw

(Source)

zone …./IN: journal rollforward failed: jo

service bind stop
rm /var/cache/bind/*,jnl
service bind start

Résumé