Résumé de l’article précédent

Dans l’article précédent, nous avons préparé l’annuaire LDAP pour héberger les zones DNS de bind. Cela se traduit par la création d’une branche et d’un utilisateur ayant les droits sur cette branche.

Bind possède un module utilisant la RFC 4533, plus connu par SyncRepl décrivant les mécanismes de synchronisation et de réplication de tout ou partie d’un annuaire LDAP. Ce module a été développé par l’équipe FreeIPA pour son propre moteur 389 DS. Ils ont eu la gentillesse de porter cela aussi pour des annuaires tel OpenLDAP.

Configuration de BIND

L’architecture de la configuration de Bind repose historiquement sur des fichiers plats avec d’un côté la configuration globale et d’un autre côté la configuration spécifique à un domain.

Nous utiliserons la configuration globale par défaut. Celui-ci gère dans les grandes lignes la configuration des serveurs racines de l’internet. Rappel, le protocole DNS est un protocol hiérarchisé c’est à dire le niveau suppérieur connait l’ensemble de ses fils directs. Le niveau fils n’a pas forcément besoin de connaître la niveau suppérieur direct pour rechercher un domain particulier, il peut partir du root racine est faire des demandes récursives jusqu’à trouver l’autorité gérant le domain.

Ceci étant, l’article n’a pas à vocation de rentrer dans la philosophie du DNS, je vous propose de passer à la suite. La configuration locale se divise en deux parties:

– named.conf.options : c’est l’endroit ou l’on décrit le périmètre du domaine et les ACL applicable aux domaines que nous gérons.

– named.conf.local : c’est l’endroit ou est déclaré les domaines et ce qui est possible de faire dans ce domaine.

named.conf.options

Ce fichier se trouve sur les systèmes à base de Debian dans le répertoire /etc/bind. Nous allons implémenté trois choses importantes :

– les ACLs applicables et les cibles

– la règle de transitivité des requêtes des domaines que nous ne gérons pas

– les logs

ACL et cible

Les ACL sont importants pour d’une part autorisé qui peut faire des requêtes sur notre serveur et d’autre restreindre les fonctionnalités (types de requêtes).

Pour l’instant, notre objectif est que l’ensemble des machines de la plateforme puissent faire des requêtes DNS de l’internet et de connaitre les FQDN du domaine lab.ezydata.fr.

De plus, nous souhaitons qu’un applicatif tiers puisse faire des demandes ajout, suppression d’enregistrement.

 

Règle de transitivité

La règle est simple, tout demande dont le serveur n’est pas autoritaire ni ne possède d’information sont relayé à des serveurs autre. Ces serveurs DNS sont fournis soit par le fournisseur réseau, soit par le fournisseur d’hébergement.

LOG

La configuration par defaut de bind sur les environnements Debian utilise syslog pour gérer les logs avec un niveau de verbosité info. En cas de problème, il est toujours opportun d’en connaitre la syntaxe pour pouvoir le changer. Aussi, dans notre article nous allons explécitement le déclarer afin de pouvoir le changer en cas de besoin.

 

Donc voici le contenu du fichier en question /etc/bind/named.conf.options

acl "cloudpf" {
        localnets;
        192.168.200.0/24;
};

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

        forwarders {
            ipdnsserveur1ISP;
            ipdnsserveur2ISP;
        };

        dnssec-validation auto;
        listen-on-v6 { any; };
        allow-update { key felicien.hoang.fr; };
        allow-query {"cloudpf";};
        allow-query-cache {"cloudpf";};
        allow-recursion {"cloudpf";};
};
logging {
     channel default_syslog {
          print-time yes;
          print-category yes;
          print-severity yes;
          syslog daemon;
          severity info;
     };
};

named.conf.local

Ce fichier contient les éléments permettant la déclaration d’un domain dns qu’il soit master, slave, forwarder et autre règle applicable à ces domaines.

Comme ces zones sont hébergées dans l’annuaire, la configuration consiste à déclarer la connectivité vers cet annuaire et la branche qui contient les informations applicables à ce serveur.

Il est important aussi de déclarer la clé partagé permettant à un tiers d’effectuer des modifications de zone. (RNDC key).

RNDCKEY

Cette clé peut êter générée par l’utilitaire rndc-confgen. Elle est partagé notament avec le serveur DHCP afin que celui ci puisse faire des modifications d’enregistrement.

root@annuaire:/etc/bind# rndc-confgen -a -A hmac-sha256 -c cloud.key -k clednscloud -u bind
Le contenu du fichier named.conf.local devrait ressembler à cela maintenant

include "/etc/bind/cloud.key";
dyndb "pfcloud_db" "/usr/lib/bind/ldap.so" {
        //library "ldap.so";
        uri "ldap://127.0.0.1:389";
        base "dc=DNS,dc=servicereseau,ou=cloud,dc=lab,dc=ezydata,dc=fr";
        auth_method "simple";
        bind_dn "uid=bind,ou=people,ou=cloud,dc=lab,dc=ezydata,dc=fr";
        password "MonMotDePasse";
        server_id "annuaire";
};
Le redémarrage du service bind pour prendre en compte ces modifications peuvent se faire. Si tout se passe bien, les logs du serveur indiquement la présence d’une zone (lab.ezydata.fr).

Résolution de problèmes

L’un des problèmes avec Bind et OpenLDAP c’est le manque d’information de cet intégration. C’est aussi en partie à cause d’une architecture encore peu connu qui n’est appliqué que dans des infrastructures complexes.

Si vous avez une erreure de ce genre :

unable to start SyncRepl session: is RFC 4533 supported by LDAP server?

Il n’est pas très parlant. Même avec votre moteur de recherche préféré, peu de documents ont abordé le sujet.

Dans les versions précédentes, les mainteneurs Debian ont fait un trop bon boulot. Dans le sens ou la plomberie (la glue) entre les différents composants (OpenLDAP, dyndb-ldap) sont fait automatiquement laissant croire à l’utilisateur final une simplicité d’installation.

En fait, si on reprend un peu l’architecture applicative de Bind, on constate qu’il est possible d’étendre Bind à être géré par autre chose que des fichiers plats. C’est donc naturellement que l’équipe FreeIPA a ajouté un module ldap pour bind (dyndb-ldap) pour développer leur solution. L’équipe s’est basé sur la spécification SyncRepl pour implémenter la synchronisation d’une branche ldap pour héberger les zones Bind.

SyncRepl dans sa philosophie première est de faire d’un annuaire LDAP une solution robuste capable d’avoir une haute disponibilité. On l’utilise pour les architecture LDAP Master/Slave(s). Or notre serveur étant en standalone, ce module n’est pas activé et n’est pas utilisé par cette database (dc=lab,dc=ezydata,dc=fr).

La solution consiste à activer ce module et à déclarer la base en question faisant partie des bases à répliquer.

Les fichiers ldifs suivant sont à exécuter.

root@annuaire:~/dns# cat syncprov_database.ldif 
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
root@annuaire:~/dns# cat activer_module_syncprov.ldif 
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
root@annuaire:~/dns# ldapadd -Y EXTERNAL -H ldapi:/// -v -f activer_module_syncprov.ldif 
ldap_initialize( ldapi:///??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
add olcModuleLoad:
	syncprov
modifying entry "cn=module{0},cn=config"
modify complete
root@annuaire:~/dns# ldapadd -Y EXTERNAL -H ldapi:/// -v -f syncprov_database.ldif 
ldap_initialize( ldapi:///??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
add objectClass:
	olcOverlayConfig
	olcSyncProvConfig
add olcOverlay:
	syncprov
add olcSpCheckpoint:
	100 10
add olcSpSessionlog:
	100
adding new entry "olcOverlay=syncprov,olcDatabase={1}mdb,cn=config"
modify complete

Procédure de vérification

Il existe plusieur procédure de vérification :

– lecture des logs;

– diagnostique des fichiers dans /var/cache/bind/dyndb-ldap;

– ou en tant qu’utilisateur.

De mont point de vue, dans un monde idéal, il faut le faire dans cet ordre. Mais étant un bon informaticien, je préfère passé directement à une vérification end-user.

dig axfr lab.ezydata.fr

; <> DiG 9.11.5-P4-5.1+deb10u3-Debian <> axfr lab.ezydata.fr
;; global options: +cmd
lab.ezydata.fr.		86400	IN	SOA	ns1.lab.ezydata.fr. jean-pierre.hoang.lab.ezydata.fr. 1615215326 10800 900 604800 86400
lab.ezydata.fr.		86400	IN	A	192.168.100.199
lab.ezydata.fr.		86400	IN	NS	ns1.lab.ezydata.fr.
_ldap._tcp.lab.ezydata.fr. 86400 IN	SRV	0 100 389 annuaire.lab.ezydata.fr.
_ldaps._tcp.lab.ezydata.fr. 86400 IN	SRV	0 100 636 annuaire.lab.ezydata.fr.
_ntp._udp.lab.ezydata.fr. 86400	IN	SRV	0 100 123 annuaire.lab.ezydata.fr.
annuaire.lab.ezydata.fr. 86400	IN	A	192.168.200.10
ns1.lab.ezydata.fr.	86400	IN	A	192.168.200.10
lab.ezydata.fr.		86400	IN	SOA	ns1.lab.ezydata.fr. jean-pierre.hoang.lab.ezydata.fr. 1615215326 10800 900 604800 86400
;; Query time: 1 msec
;; SERVER: 192.168.200.10#53(192.168.200.10)
;; WHEN: Mon Mar 08 15:57:24 CET 2021
;; XFR size: 9 records (messages 1, bytes 384)

Gestion des enregistrements de façon dynamique

L’utilité d’une gesion dynamique est que la modification d’une zone (ajout d’un enregistrement) ne nécessite pas un redémarrage du système.

Nous pouvons peupler notre zone par les adresses suivantes :

– 192.168.200.1 : le routeur

– 192.168.200.2, 3, 4 : les hiperviseurs

– 192.168.200.10 : un alias pour ldap par exemple.

Ces modifications peuvent être faite soit dans l’annuaire ldap directement (avec ldif ou avec un client ldap tel Apache Directory studio) ou via l’application « nsupdate ».

Pour rappel, dans les règles de gestion des zones nous avons stipulé que cette zone pouvait être géré avec la clé cleclouddns sans restriction sur l’adresse ip ou provient la commande.

 

root@annuaire:/etc/bind# nsupdate -k cloud.key 
> update add routeur.lab.ezydata.fr 86400 A 192.168.200.1             
> update add hyperviseur1.lab.ezydata.fr 86400 A 192.168.200.2
> update add hyperviseur2.lab.ezydata.fr 86400 A 192.168.200.3
> update add hyperviseur3.lab.ezydata.fr 86400 A 192.168.200.4
> update add ldap.lab.ezydata.fr 86400 CNAME annuaire.lab.ezydata.fr
> send
> quit
root@annuaire:/etc/bind# dig axfr lab.ezydata.fr

; <> DiG 9.11.5-P4-5.1+deb10u3-Debian <> axfr lab.ezydata.fr
;; global options: +cmd
lab.ezydata.fr.		86400	IN	SOA	ns1.lab.ezydata.fr. jean-pierre.hoang.lab.ezydata.fr. 1615220309 10800 900 604800 86400
lab.ezydata.fr.		86400	IN	A	192.168.200.10
lab.ezydata.fr.		86400	IN	NS	ns1.lab.ezydata.fr.
_ldap._tcp.lab.ezydata.fr. 86400 IN	SRV	0 100 389 annuaire.lab.ezydata.fr.
_ldaps._tcp.lab.ezydata.fr. 86400 IN	SRV	0 100 636 annuaire.lab.ezydata.fr.
_ntp._udp.lab.ezydata.fr. 86400	IN	SRV	0 100 123 annuaire.lab.ezydata.fr.
annuaire.lab.ezydata.fr. 86400	IN	A	192.168.200.10
hyperviseur1.lab.ezydata.fr. 86400 IN	A	192.168.200.2
hyperviseur2.lab.ezydata.fr. 86400 IN	A	192.168.200.3
hyperviseur3.lab.ezydata.fr. 86400 IN	A	192.168.200.4
ldap.lab.ezydata.fr.	86400	IN	CNAME	annuaire.lab.ezydata.fr.
ns1.lab.ezydata.fr.	86400	IN	A	192.168.200.10
routeur.lab.ezydata.fr.	86400	IN	A	192.168.200.1
lab.ezydata.fr.		86400	IN	SOA	ns1.lab.ezydata.fr. jean-pierre.hoang.lab.ezydata.fr. 1615220309 10800 900 604800 86400
;; Query time: 2 msec
;; SERVER: 192.168.200.10#53(192.168.200.10)
;; WHEN: Mon Mar 08 17:39:13 CET 2021
;; XFR size: 14 records (messages 1, bytes 514)

Prochaine étape : DHCP avec gestion dynamique des FDQN

Le serveur DNS a été configuré pour gérer des changement dynamique en continue (sans redémarrage du système) depuis un autre système (pas uniquement depuis le serveur annuaire).

La suite est de lui adjoindre le système d’adressage réseau dhcp pour que celui-ci envoie des ordres de modification dns.