Les types d’enregistrements DNS
On a vu lors du premier module que le DNS n’était rien d’autre qu’un annuaire (au même titre qu’un simple bottin téléphonique), mettant en relation les adresses IP des équipements du réseau avec un nom (plus exploitable), lié à la machine.
Donc, un DNS peut être vu comme une base de données répartie, contenant des enregistrements de ressources, appelés Resource Records (ou RR), codés sur 16bits, concernant les noms de domaine et codifiant les types d’enregistrements suivants :
- A : il s’agit des enregistrements d’adresses faisant correspondre un nom d’hôte à une adresse IPv4 de 32bits. En IPv6, on utilise des enregistrements AAAA codés sur 128bits.
- CNAME : il s’agit d’enregistrements canoniques créant un alias d’un domaine vers un autre. L’alias hérite de tous les sous-domaines de l’original.
- MX : définit les serveurs de messagerie pour le domaine.
- PTR : associe une adresse IP à un enregistrement de nom de domaine (on parle de reverse puisqu’il s’agit du contraire de l’enregistrement A).
- NS : définit les serveurs DNS du domaine (primaire et secondaire).
- SOA : fournit les informations générales de la zone : serveur principal, contact, délai d’expiration, n° de série de la zone.
- SRV : généralise la notion d’enregistrement MX en proposant des fonctions avancées : taux de répartition de charge (décrit dans la RFC2782).
- NAPTR : donne accès aux règles de réécriture de l’information permettant de lier le nom de domaine et une ressource (RFC3403).
- TXT : permet à l’administrateur d’insérer un texte quelconque pour un enregistrement DNS.
REMARQUE : pour les amateurs de géolocalisation, il existe également des enregistrements LOC permettant de fournir longitude et latitude précises d’un serveur.
Seules les personnes ayant autorité ou administrant la zone, peuvent être intéressées par les informations de description d’un enregistrement DNS.
De façon générale, un enregistrement DNS est composé des champs suivants :
Puisque le système de cache permet au système DNS de rester réparti, les enregistrements de chaque domaine possèdent une durée de vie limitée, appelée TTL, et permettent aux serveurs intermédiaire de connaître leur date de péremption et de savoir s’il faut ou non vérifier à nouveau les informations s’y trouvant, pour les différents types énoncés ci-dessus.
Le système de cache du serveur BIND est intégré à la commande elle-même. Aussi, pour vider le cache, il suffit d’arrêter et redémarrer le service :
# service named reload
Il se peut, dans certaines configurations (RHEL, CentOS, Fedora), qu’un autre service de cache existe : le service nscd. Dans ce cas, c’est lui qu’il faut redémarrer pour le rafraichir :
# service nscd restart
ATTENTION : le serveur de noms BIND s’appuie le plus souvent sur un mécanisme de cache appelé rndc. Il est ainsi possible de lister le contenu de celui-ci en exécutant la commande suivante :
# rndc dumpdb –cache
Outre le fait de consulter le contenu du cache et pouvoir ainsi obtenir des informations, cette commande permet également d’administrer les zones DNS. On peut, entre autres arrêter le serveur, recharger les fichiers de configuration et, si l’on souhaite vider le cache en exécutant l’une des deux commandes ci-dessous :
# rndc flush # rndc flushname <Domaine FQDN>
Sur une distribution Debian, le cache est localisé dans le répertoire /var/cache/bind et les journaux de logs sont administrés à part. Il faut créer un script named.conf.log dans le répertoire /etc/bind permettant de journaliser les différents types de flux et d’erreurs :
logging {
channel update_debug {
file "/var/log/update_debug.log" versions 3 size 100k;
severity debug;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/security_info.log" versions 1 size 100k;
severity info;
print-severity yes;
print-time yes;
};
channel bind_log {
file "/var/log/bind.log" versions 3 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { bind_log; };
category lame-servers { null; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
};
Pour le reste les déclarations d’enregistrements dans les fichiers de zones sont exactement les mêmes entre une distribution CentOS et une distribution Debian (ou dérivé).
