Commandes Linux : rndc

RNDC

Installé avec le paquet bind9utils
Voir aussi : rndc-confgen
 
Rmq : RNDC utilise, par défaut, la clef rndc-key du fichier /etc/bind/rndc.conf (à créer, mais facultatif), ou la clef rndc-key incluse dans le fichier /etc/bind/rndc.key. Si les deux sont présents, c’est le fichier /etc/bind/rndc.conf qui sera utilisé en priorité.
 

Pré-requis à l’utilisation de l’utilitaire RNDC

  • Utiliser la clef rndc-key stockée dans le fichier /etc/bind/rndc.key généré à l’installation de Bind9, ou générer un nouveau fichier /etc/bind/rndc.key par la commande rndc-confgen -a
  • Inclure le fichier /etc/bind/rndc.key dans le fichier /etc/bind/named.conf, comme ceci :
    include "/etc/bind/named.conf.options";
    include "/etc/bind/named.conf.local";
    include "/etc/bind/named.conf.default-zones";
    include "/etc/bind/tsig.key";
    include "/etc/bind/rndc.key";
    
  • Ajouter une option de controls dans le fichier /etc/bind/named.conf.options, comme ceci :
    [...]
    controls {
            inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
    };
    

 

Afficher la version de la commande rndc

apt-cache policy bind9utils

 

Afficher le statut et la version de Bind

rndc status

ex :

# rndc status
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
version: 9.9.5-9+deb8u6-Debian 
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 102
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

 

Activer/Désactiver les logs de requêtes DNS

rndc querylog

Activera ou désactivera les logs de requêtes DNS (en fonction de son statut) visibles dans le fichier /var/log/syslog.
Pour afficher le statut du query logging, utiliser rndc status.
 

Vider le cache local du serveur Bind

rndc flush

 

Recharger les zones non dynamiques après modification, mais aussi les fichiers de configuration de Bind9

rndc reload

ex :

# rndc reload
server reload successful

Rmq : Permet d’initier un transfert de zone vers le slave.
 

Recharger une zone particulière non dynamique après modification de son fichier de zone sur le master

rndc reload zonename

ex :

# rndc reload opensharing.priv
zone reload queued

Rmq : Permet d’initier un transfert de zone vers le slave.
 

Recharger une zone particulière dynamique après modification de son fichier de zone sur le master

Une zone dynamique, c’est-à-dire contenant l’option allow-update, nécessite que la mise à jour dynamique soit bloquée avant de modifier son fichier de zone, de le recharger puis de débloquer la mise à jour dynamique. Si on ne suit pas ce processus, on observe alors le message d’erreur suivant :

# rndc reload opensharing.priv
rndc: 'reload' failed: dynamic zone

Voici donc les étapes à respecter pour une zone dynamique :

  1. rndc freeze zonename : On bloque (gèle) les mises à jour dynamiques pour la zone. De plus, les informations du journal sont synchronisées avec le fichier de zone correspondant
  2. nano /var/cache/bind/zonefile : On modifie le fichier de zone et on incrémente le serial du SOA
  3. rndc reload zonename : On recharge la zone, ce qui supprime (si l’on a édité manuellement la zone) le fichier journal .jnl relatif aux mises à jour dynamiques. Ce dernier sera automatiquement recréé lors de la prochaine mise à jour dynamique
  4. rndc thaw zonename : On débloque (dégèle) les mises à jour dynamiques pour la zone

ex :

# rndc freeze opensharing.priv
# nano /var/cache/bind/db.opensharing.priv
# rndc reload opensharing.priv
zone reload queued
# rndc thaw opensharing.priv
The zone reload and thaw was successful.

Rmq : Cette procédure est valable pour Bind9 à partir de la version 9.3.0. Pour les versions antérieures de Bind9, il faut arrêter le service Bind9, supprimer le journal zonename.jnl relatif à la zone à éditer et situé dans le même répertoire que cette dernière, procéder à la modification de la zone et enfin relancer le service Bind9.
Dans tous les cas, il est préférable de mettre à jour une zone dynamique avec nsupdate plutôt que de l’éditer manuellement.
 

Redemander un transfert de zone du master vers le slave

Rmq : Commande à effectuer sur le slave, avec l’option allow-tranfer paramétrée correctement sur le master (doit autoriser l’IP du slave)

rndc retransfer zonename

ex :

# rndc retransfer opensharing.priv

 

Forcer le refresh d’une zone particulière du slave

Rmq : Commande à effectuer sur le slave, avec l’option allow-tranfer paramétrée correctement sur le master (doit autoriser l’IP du slave)

rndc refresh zonename

ex :

# rndc refresh opensharing.priv

 

Forcer la synchronisation du fichier journal d’une zone et du fichier de zone lui-même

Lors d’une mise à jour dynamique, via nsupdate par exemple, le fichier journal zone.jnl est mis à jour automatiquement, tout comme la copie du fichier de zone en mémoire sur le serveur. Par contre, le fichier de zone lui-même doit attendre environ 20 minutes pour être mis à jour (bien que cela ne soit pas pénalisant en termes de cohérence des requêtes DNS). Si l’on ne souhaite pas attendre ce temps de synchronisation, on peut forcer cette dernière.
Forcer la synchornisation journal-zone tout en gardant le journal :

rndc sync

Forcer la synchronisation journal-zone mais en vidant le journal :

rndc sync -clean
12-Jul-2016 01:02:59.528 general: info: received control channel command 'sync -clean'
12-Jul-2016 01:02:59.528 general: info: dumping all zones, removing journal files: success

Rmq : Toutes les zones seront synchronisées, mais il est possible de spécifier une zone en partuclier

# rndc sync -clean opensharing.priv
12-Jul-2016 01:02:19.700 general: info: received control channel command 'sync -clean opensharing.priv'
12-Jul-2016 01:02:19.700 general: info: sync: dumping zone 'opensharing.priv/IN' internal, removing journal file: success

 

Gestion distante du slave depuis le master via l’utilitaire RNDC

Par défaut, RNDC n’est utilisable que sur l’hôte sur lequel il est lancé. Pour un rechargement des zones non dynamiques, par exemple, la commande par défaut est :

# rndc reload

Elle revient à effectuer :

# rndc -s 127.0.0.1 -c /etc/bind/rndc.conf -p 953 reload

ou

# rndc -s 127.0.0.1 -k /etc/bind/rndc.key -p 953 reload

Car le fichier /etc/bind/named.conf.options contient la déclaration de controls suivante :

[...]
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key";};
};

Pour exécuter RNDC depuis le master sur le slave, il faut autoriser le master, le port 953 et définir la clef d’authentification dans la configuration du slave.
Pour cela, le slave doit posséder la même clef rndc-key et il faut éditer son fichier /etc/bind/named.conf.options en modifiant simplement les lignes suivantes :

[...]
controls {
        inet * port 953 allow { 127.0.0.1; 192.168.1.11; } keys { "rndc-key";};
};

La connexion se fait sur toutes les interfaces, via le port 953, en autorisant lui-même et le master authentifiés par la clef rndc-key définie dans /etc/bind/named.conf.
Ensuite, redémarrer le service Bind9 pour prendre en compte les modification du fichier /etc/bind/named.conf.options :

# /etc/init.d/bind9 restart

Il est ensuite possible, sur le master, de lancer les commandes RNDC comme :

# rndc -s 192.168.1.12 reload
# rndc -s 192.168.1.12 retransfer opensharing.priv
Fermer le menu
%d blogueurs aiment cette page :