22602
Comment: drop link to original page location (content copied here by author).
|
22616
converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
||<tablestyle="width: 100%;" style="border: 0px hidden">~-[:DebianWiki/EditorGuide#translation:Traduction(s)]: [:Bind9:English]-~||<style="text-align: right;border: 0px hidden"> (!) [:/Discussion:Discussion]|| | ||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[DebianWiki/EditorGuide#translation|Traduction(s)]]: [[Bind9|English]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]|| |
Line 6: | Line 6: |
[[TableOfContents(3)]] | <<TableOfContents(3)>> |
Line 19: | Line 19: |
Nous disposons d'un accès Internet via une xxxbox (192.168.1.1), de deux serveurs DNS fournis par notre FAI (80.10.249.2, 80.10.246.129). En fait, ces deux derniers ne seront jamais mentionnés dans la configuration car la xxxbox va se charger de faire la résolution de noms si elle ne connaît pas l'adresse de destination des paquets. Par conséquent, je considère la xxxbox comme le serveur primaire hors de notre domaine. Le serveur "sid" (192.168.1.10) est connectée à la xxxbox via sa première carte réseau. Il est aussi connecté au lan (192.168.0.0/24) via sa seconde interface réseau (192.168.0.1). C'est sur celui-ci que nous allons installer le serveur DNS primaire pour notre domaine example.com ([http://www.ietf.org/rfc/rfc2606.txt RFC 2606]) Tous les ordinateurs du lan se voient attribuer une adresse ip automatiquement via le service DHCP. Ce dernier fournira aussi l'adresse du serveur DNS primaire situé sur notre domaine, et mettra à jour les noms d'hôtes pour la zone example.com auxquels il aura attribué une adresse ip. | Nous disposons d'un accès Internet via une xxxbox (192.168.1.1), de deux serveurs DNS fournis par notre FAI (80.10.249.2, 80.10.246.129). En fait, ces deux derniers ne seront jamais mentionnés dans la configuration car la xxxbox va se charger de faire la résolution de noms si elle ne connaît pas l'adresse de destination des paquets. Par conséquent, je considère la xxxbox comme le serveur primaire hors de notre domaine. Le serveur "sid" (192.168.1.10) est connectée à la xxxbox via sa première carte réseau. Il est aussi connecté au lan (192.168.0.0/24) via sa seconde interface réseau (192.168.0.1). C'est sur celui-ci que nous allons installer le serveur DNS primaire pour notre domaine example.com ([[http://www.ietf.org/rfc/rfc2606.txt|RFC 2606]]) Tous les ordinateurs du lan se voient attribuer une adresse ip automatiquement via le service DHCP. Ce dernier fournira aussi l'adresse du serveur DNS primaire situé sur notre domaine, et mettra à jour les noms d'hôtes pour la zone example.com auxquels il aura attribué une adresse ip. |
Line 157: | Line 157: |
* [http://www.kb.cert.org/vuls/id/800113 Vulnerability Note VU#800113] * [http://www.trusteer.com/bind9dns Bind9 DNS Cache Poisoning] M. Rash a écrit un article intéressant à propos de cela et comment forcer le port source de manière aléatoire par le biais d'iptables :[http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html Mitigating DNS Cache Poisoning Attacks with iptables] |
* [[http://www.kb.cert.org/vuls/id/800113|Vulnerability Note VU#800113]] * [[http://www.trusteer.com/bind9dns|Bind9 DNS Cache Poisoning]] M. Rash a écrit un article intéressant à propos de cela et comment forcer le port source de manière aléatoire par le biais d'iptables :[[http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html|Mitigating DNS Cache Poisoning Attacks with iptables]] |
Line 228: | Line 228: |
On définit ici les différentes méthodes de log pour les différentes catégories. La première catégorie est comme son nom l'indique la catégorie par défaut qui est habituellement affectée au syslog. Toutes catégories non mentionnées, sont assimilées à la catégorie default. Pour obtenir une liste des différentes catégories, consulter[http://www.bind9.net/manual/bind/9.3.2/Bv9ARM le manuel de référence de l'administrateur pour bind9]. Pour ce qui est des lame-servers, on ignore tous les logs qui leur sont associés. | On définit ici les différentes méthodes de log pour les différentes catégories. La première catégorie est comme son nom l'indique la catégorie par défaut qui est habituellement affectée au syslog. Toutes catégories non mentionnées, sont assimilées à la catégorie default. Pour obtenir une liste des différentes catégories, consulter[[http://www.bind9.net/manual/bind/9.3.2/Bv9ARM|le manuel de référence de l'administrateur pour bind9]]. Pour ce qui est des lame-servers, on ignore tous les logs qui leur sont associés. |
Line 285: | Line 285: |
Les classes : IN determine l'association a la classe Internet. D'autres classe sont disponibles (CH et HS). Pour de plus amples informations vous pouvez consulter la[http://www.ietf.org/rfc/rfc1035.txt RFC 1035] | Les classes : IN determine l'association a la classe Internet. D'autres classe sont disponibles (CH et HS). Pour de plus amples informations vous pouvez consulter la[[http://www.ietf.org/rfc/rfc1035.txt|RFC 1035]] |
Line 378: | Line 378: |
Pour de plus amples informations sur la mise en place de l'update dynamique des enregistrements DNS via Dhcp c'est[http://www.dthconnex.com/dhcp_server.html ici] | Pour de plus amples informations sur la mise en place de l'update dynamique des enregistrements DNS via Dhcp c'est[[http://www.dthconnex.com/dhcp_server.html|ici]] |
Line 488: | Line 488: |
* [wiki:RFC:1035 rfc1035] - Implementation ans specifications * [wiki:RFC:1591 rfc1591] - Domain Name System Structure and Delegation * [wiki:RFC:2606 rfc2606] - Reserved Top Level DNS Names * [http://www.bind9.net/manual/bind/9.3.2/Bv9ARM] - Bind 9 Administrator Manual |
* [[RFC:1035|rfc1035]] - Implementation ans specifications * [[RFC:1591|rfc1591]] - Domain Name System Structure and Delegation * [[RFC:2606|rfc2606]] - Reserved Top Level DNS Names * [[http://www.bind9.net/manual/bind/9.3.2/Bv9ARM]] - Bind 9 Administrator Manual |
Line 493: | Line 493: |
* [http://www.gandi.net/whois?l=FR Gandhi] * [http://www.afnic.fr/outils/whois/ AFNIC] |
* [[http://www.gandi.net/whois?l=FR|Gandhi]] * [[http://www.afnic.fr/outils/whois/|AFNIC]] |
Contents
Présentation
La mise en place d'un serveur DNS sur un réseau permet de remplacer les adresses ip des machines par un nom. Ainsi, il est même possible d'associer plusieurs noms à la même machine pour mettre en évidence les différents services possibles. Du coup, www.example.com et pop.example.com, peuvent pointer sur le serveur principale où sont présents le serveur de mail et l'intranet de l'entreprise dont le domaine serait example.com. C'est tout de même plus facile que de se rappeler que ces deux services tournent sur la machine dont l'adresse ip est 192.168.0.1.
Imaginez maintenant, que l'administrateur de notre entreprise décide pour une raison ou une autre de déplacer le serveur de mail sur la machine 192.168.0.11. Il n'y a rien a faire du tout sauf modifier le fichier de configuration du serveur DNS. Il vous reste toujours la possibilité d'aller modifier le fichier hosts de tous les utilisateurs, mais cela risque de prendre du temps et d'embêter certaines personnes.
Définitions
DNS : signifie soit Domain Name System ou Domain Name Server
Serveur primaire :
Serveur secondaire :
Serveur cache :
Disposition réseau
Nous disposons d'un accès Internet via une xxxbox (192.168.1.1), de deux serveurs DNS fournis par notre FAI (80.10.249.2, 80.10.246.129). En fait, ces deux derniers ne seront jamais mentionnés dans la configuration car la xxxbox va se charger de faire la résolution de noms si elle ne connaît pas l'adresse de destination des paquets. Par conséquent, je considère la xxxbox comme le serveur primaire hors de notre domaine. Le serveur "sid" (192.168.1.10) est connectée à la xxxbox via sa première carte réseau. Il est aussi connecté au lan (192.168.0.0/24) via sa seconde interface réseau (192.168.0.1). C'est sur celui-ci que nous allons installer le serveur DNS primaire pour notre domaine example.com (RFC 2606) Tous les ordinateurs du lan se voient attribuer une adresse ip automatiquement via le service DHCP. Ce dernier fournira aussi l'adresse du serveur DNS primaire situé sur notre domaine, et mettra à jour les noms d'hôtes pour la zone example.com auxquels il aura attribué une adresse ip.
Gestion du serveur
Installation
On va utiliser le package bind9 pour faire tout ça.
# apt-get install bind9
et puis si vous voulez installer en plus la documentation, (très utile):
# apt-get install bind9-doc
Configuration
Après l'installation, on va voir un peu du coté des fichiers de configuration. Ils sont placés dans le répertoire /etc/bind/
Signature TSIG
Cette signature à pour but d'authentifier les transactions avec BIND. Ainsi, le serveur DHCP ne pourra mettre à jour le domaine example.com que si il dispose de cette clef. On recopie une clef existante
# cd /etc/bind/ # cat rndc.key key "rndc-key" { algorithm hmac-md5; secret "QJc08cnP1xkoF4a/eSZZbw=="; }; # cp rndc.key ns-example-com_rndc-key
On génère une nouvelle clef avec les options suivantes :
algorithme HMAC-MD5 - identifiant 157 (obligatoire pour une signature TSIG et seul algorithme supporté par BIND)
longeur de 512 octets (multiple de 64 avec une longueur maximale de 512 pour l'algorithme ci-dessus)
nom : ns-example-com_rndc-key
dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key Kns-example-com_rndc-key.+157+53334
Le footprint associé à la clef est 53334. On obtient alors deux fichiers, l'un avec une extension key et l'autre avec une extension private. On substitue la clef présente dans le fichier ns-example-com_rndc-key par celle présente dans un de ces derniers.
# cat Kns-example-com_rndc-key.+157+53334.private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA== Bits: AAA= # cat ns-example-com_rndc-key key "ns-example-com_rndc-key" { algorithm hmac-md5; secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA=="; };
Le fichier ns-example-com_rndc-key ne doit pas être world-readable, afin de garantir la sécurité. Celui-ci sera inséré dans la configuration de bind via une directive include car la configuration de bind est quant à elle world-readable. On pensera aussi à supprimer les fichiers key et private précédemment générés.
Fichier named.conf
Ce fichier est le fichier de configuration principal du serveur DNS.
// Gérer les acls acl internals { 127.0.0.0/8; 192.168.0.0/24; }; // Charger les options include "/etc/bind/named.conf.options"; // Déclaration de la clef TSIG utilisé pour la mise à jour dynamique include "/etc/bind/ns-example-com_rndc-key"; // Configurer le canal de communication pour adminsistrer BIND9 avec rndc // Par défaut, la clef est située dans le fichier rndc.key et utiliser par // rndc et bind9 sur localhost controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; }; }; // prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; include "/etc/bind/named.conf.local";
Fichier named.conf.options
Ce fichier contient l'ensemble des options de configuration du serveur DNS.
options { directory "/var/cache/bind"; // Port d'échange entre les serveurs DNS query-source address * port *; // Transmettre les requêtes à 192.168.1.1 si // ce serveur ne sait pas résoudre ces adresses forward only; forwarders { 192.168.1.1; }; auth-nxdomain no; # conform to RFC1035 // Ecouter sur les interfaces locales uniquement (IPV4) listen-on-v6 { none; }; listen-on { 127.0.0.1; 192.168.0.1; }; // Ne pas transférer les informations de zones aux DNS secondaires allow-transfer { none; }; // Accepter les requêtes pour le réseau interne uniquement allow-query { internals; }; // Autoriser les requêtes récursives pour les hôtes locaux allow-recursion { internals; }; // Ne pas rendre publique la version de BIND version none; };
Le port associé à l'option query-source ne doit en aucun cas être figé car il fragilise les transactions DNS dans le cas d'un résolveur.
M. Rash a écrit un article intéressant à propos de cela et comment forcer le port source de manière aléatoire par le biais d'iptables :Mitigating DNS Cache Poisoning Attacks with iptables
Afin de diminuer la temporisation de timeout pour les connexions udp, et ainsi mettre en évidence la randomization qui par défaut est de 30s par tuple, il suffit de mettre à jour le paramètre net.netfilter.nf_conntrack_udp_timeout
# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
pour obtenir un timeout à 10s.
Fichier named.conf.local
Ce fichier contient la configuration local du serveur DNS, on y déclare les zones associées au domaine.
// Gérer les fichiers de logs include "/etc/bind/named.conf.log"; // Gestion du domaine example.com // ------------------------------ // - Le serveur est défini comme maître sur ce domaine // - Il n'y a aucun forwaders pour ce domaine // - Les entrees sur le domaine peuvent être ajoutées // dynamiquement avec le clef ns-example-com_rndc-key zone "example.com" { type master; file "/var/cache/bind/db.example.com"; forwarders {}; allow-update { key ns-example-com_rndc-key; }; }; zone "0.168.192.in-addr.arpa" { type master; file "/var/cache/bind/db.example.com.inv"; forwarders {}; allow-update { key ns-example-com_rndc-key; }; }; // Consider adding the 1918 zones here, if they are not used in your // organization include "/etc/bind/zones.rfc1918";
Fichier named.conf.log
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; }; };
On définit ici les différentes méthodes de log pour les différentes catégories. La première catégorie est comme son nom l'indique la catégorie par défaut qui est habituellement affectée au syslog. Toutes catégories non mentionnées, sont assimilées à la catégorie default. Pour obtenir une liste des différentes catégories, consulterle manuel de référence de l'administrateur pour bind9. Pour ce qui est des lame-servers, on ignore tous les logs qui leur sont associés.
Les Ressources Records (RR)
Un DNS est constitue de plusieurs enregistrements, les RR ou Ressources Records, définissant les diverses informations relatives au domaine. Le premier enregistrement est consacré à la résolution de noms, dans notre cas, il s'agit du fichier db.example.com. Le second sera quant à lui en rapport avec la résolution de noms inverses ; il s'agit du fichier db.example.com.inv.
Les fichiers
- RR pour la résolution de noms (fichier db.example.com)
$TTL 3600 @ IN SOA sid.example.com. root.example.com. ( 2007010401 ; Serial 3600 ; Refresh [1h] 600 ; Retry [10m] 86400 ; Expire [1d] 600 ) ; Negative Cache TTL [1h] ; @ IN NS sid.example.com. @ IN MX 10 sid.example.com. sid IN A 192.168.0.1 etch IN A 192.168.0.2 pop IN CNAME sid www IN CNAME sid mail IN CNAME sid
- RR pour la résolution inverse (fichier db.example.com.inv)
@ IN SOA sid.example.com. root.example.com. ( 2007010401 ; Serial 3600 ; Refresh [1h] 600 ; Retry [10m] 86400 ; Expire [1d] 600 ) ; Negative Cache TTL [1h] ; @ IN NS sid.example.com. 1 IN PTR sid.example.com. 2 IN PTR etch.example.com.
Quelques explications :
$TTL : (Time To Live) exprime la duree (en secondes) de validité, par défaut, des informations que contiennent les RRs. Une fois ce délais expire, il est nécessaire de revérifier les données. Les différents types :
SOA : permet de définir les informations relatives à la zone. En l'occurrence le nom du serveur DNS primaire "sid.example.com." et l'adresse mail du contact technique (root.example.com. ; le @ est remplace par un point). Il est compose de plusieurs champs :
1. Serial : est un entier non signé 32 bits. C'est le numéro de série à incrémenter à chaque modification du fichier. Il permet au serveur secondaire de recharger les informations qu'ils ont. L'usage général vient à le formater de cette manière YYYYMMDDXX, soit pour la première modification du 01/04/2007 -> 2007040101, pour la seconde 2007040102.
2. Refresh : définit la période de rafraîchissement des données.
3. Retry : si une erreur survient au cours du dernier rafraîchissement, celle -ci sera répéter au bout du délais Retry.
4. Expire : le serveur sera considéré comme non disponible au bout du délais Expire.
5. Negative cache TTL : défini la durée de vie d'une réponse NXDOMAIN de notre part.
NS : renseigne le nom des serveurs de noms pour le domaine.
MX : renseigne sur le serveur de messagerie. Plusieurs peuvent être définis. Ainsi, il est possible de leur donner une priorité en leur affectant un numéro. Plus bas est le numéro, plus haute est la priorité.
A : associe une nom d'hôte à une adresse ipv4 (32 bits)
AAAA : associe une nom d'hôte à une adresse ipv6 (128 bits)
CNAME : identifie le nom canonique d'un alias (un nom pointant sur un autre nom)
PTR : c'est simplement la résolution inverse (le contraire du type A).
Les classes : IN determine l'association a la classe Internet. D'autres classe sont disponibles (CH et HS). Pour de plus amples informations vous pouvez consulter laRFC 1035
Fichier /etc/resolv.conf
search example.com
Il est pas des plus compliqué celui-la !
Chroot de bind
Par défaut, la configuration de bind emploi l'utilisateur bind pour exécuter le démon named. Ainsi, on retrouve cette option dans /etc/default/bind9:
OPTIONS="-u bind"
qui est pris en compte lors du lancement du service bind9. Voici un extrait du fichier /etc/init.d/bind9 :
test -f /etc/default/bind9 && . /etc/default/bind9 ... if start-stop-daemon --start --quiet --exec /usr/sbin/named \ --pidfile /var/run/bind/run/named.pid -- $OPTIONS;
C'est déja une bonne chose mais à celà, il faut ajouter l'utilisation d'une racine autre que / pour emprisonner le démon named dans sa prison. Il s'agit tout simplement d'employer l'option-ten précisant le répertoire de chroot. La variable OPTIONS dans le fichier /etc/default/bind9 devient :
OPTIONS="-u bind -t /var/lib/named"
Maintenant il faut créer l'arborescence dans le chroot.
/var/lib/named/ | |__ /etc |__ /dev |__ /var |__ /cache | |__ /bind | |__ /log # mkdir -p /var/lib/named/etc # mkdir /var/lib/named/dev # mkdir -p /var/lib/named/var/cache/bind # mkdir /var/lib/named/var/log
On déplace l'ancien répertoire de travail de bind dans le prison, et l'on met en place un lien symbolique /etc/bind vers ce même répertoire pour permettre au processus rndc de retrouver ces petits puisqu'il va utiliser le fichier rndc.key par défaut pour s'authentifier sur le channel d'administration port 953.
# mv /etc/bind /var/lib/named/etc # ln -s /var/lib/named/etc/bind /etc/bind
On ajoute les périphériques null et random :
# mknod /var/lib/named/dev/null c 1 3 # mknod /var/lib/named/dev/random c 1 8 # chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random
Pour autoriser le démon syslog à prendre en compte les logs de bind, il nous faut lui préciser d'écouter le socket /var/lib/named/dev/log. Pour ce faire, modifier le fichier /etc/default/syslogd pour utiliser l'option suivante.
SYSLOGD="-a /var/lib/named/dev/log"
Une dernière chose, consiste à créer le répertoire pour stocker le pid du processus. J'ai opté pour une amélioration du fichier de démarrage du service. J'ai modifié le fichier /etc/init.d/bind9:
- Création de la variable CHROOT_DIR
- Modification de la création du répertoire contenant le pid du processus
CHROOT_DIR=`echo $OPTIONS | cut -d ' ' -f 4` # dirs under /var/run can go away on reboots. mkdir -p $CHROOT_DIR/var/run/bind/run chmod 775 $CHROOT_DIR/var/run/bind/run chown root:bind $CHROOT_DIR/var/run/bind/run >/dev/null 2>&1 || true
Il faut déplacer les fichiers RR précédemment stockés dans /var/cache/bind/, dans /var/lib/named/var/cache/bind
# mv /var/cache/bind/* /var/lib/named/var/cache/bind/
L'arborescence est complète et tous les fichiers sont présents, mais les droits ne sont pas encore aux points, donc :
# chown -R root:bind /var/lib/named/etc/bind # chmod 640 /var/lib/named/etc/bind/* # chown bind:bind /var/lib/named/var/*
Gestion des clients
Comme je l'ai mentionne au début, l'attribution des adresses ip sur le réseau local est effectuée par le serveur DHCP. Ainsi, pour définir notre serveur DNS aux différents clients, il est nécessaire d'ajouter au fichier de configuration DHCP les deux lignes suivantes :
option domain-name "example.com"
option domain-name-server sid.example.com
Pour de plus amples informations sur la mise en place de l'update dynamique des enregistrements DNS via Dhcp c'estici
Les outils de tests
La commande dig : Elle permet d'interroger directement le serveur DNS de son choix et d'obtenir de nombreuses informations, en plus de la résolution de noms et la résolution inverse.
$ dig nomade-frjo.stones.lan ; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;nomade-frjo.stones.lan. IN A ;; ANSWER SECTION: nomade-frjo.stones.lan. 900 IN A 192.168.0.242 ;; AUTHORITY SECTION: stones.lan. 604800 IN NS emerald.stones.lan. stones.lan. 604800 IN NS diamond.stones.lan. ;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2 ;; Query time: 20 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:09 2008 ;; MSG SIZE rcvd: 131 $ dig -x 192.168.0.242 ; <<>> DiG 9.4.2 <<>> -x 192.168.0.242 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;242.0.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 242.0.168.192.in-addr.arpa. 900 IN PTR nomade-frjo.stones.lan. ;; AUTHORITY SECTION: 0.168.192.in-addr.arpa. 604800 IN NS diamond.stones.lan. 0.168.192.in-addr.arpa. 604800 IN NS emerald.stones.lan. ;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2 ;; Query time: 19 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:31 2008 ;; MSG SIZE rcvd: 155
La commande nslookup : Elle est moins performantes mais reste utile.
$ nslookup etch Server: 192.168.0.1 Address: 192.168.0.1#53 Name: etch.example.com Address: 192.168.0.2 $ nslookup 192.168.0.2 Server: 192.168.0.1 Address: 192.168.0.1#53 2.0.168.192.in-addr.arpa name = etch.example.com.
named-checkconf : Elle permet de vérifier la syntaxe des fichers de configuration de Bind9.
# named-checkconf -z zone localhost/IN: loaded serial 1 zone 127.in-addr.arpa/IN: loaded serial 1 zone 0.in-addr.arpa/IN: loaded serial 1 zone 255.in-addr.arpa/IN: loaded serial 1 zone estar.lan/IN: loaded serial 20080315 zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 zone 10.in-addr.arpa/IN: loaded serial 1 zone 16.172.in-addr.arpa/IN: loaded serial 1 zone 17.172.in-addr.arpa/IN: loaded serial 1 zone 18.172.in-addr.arpa/IN: loaded serial 1 zone 19.172.in-addr.arpa/IN: loaded serial 1 zone 20.172.in-addr.arpa/IN: loaded serial 1 zone 21.172.in-addr.arpa/IN: loaded serial 1 zone 22.172.in-addr.arpa/IN: loaded serial 1 zone 23.172.in-addr.arpa/IN: loaded serial 1 zone 24.172.in-addr.arpa/IN: loaded serial 1 zone 25.172.in-addr.arpa/IN: loaded serial 1 zone 26.172.in-addr.arpa/IN: loaded serial 1 zone 27.172.in-addr.arpa/IN: loaded serial 1 zone 28.172.in-addr.arpa/IN: loaded serial 1 zone 29.172.in-addr.arpa/IN: loaded serial 1 zone 30.172.in-addr.arpa/IN: loaded serial 1 zone 31.172.in-addr.arpa/IN: loaded serial 1 zone 168.192.in-addr.arpa/IN: loaded serial 1
named-checkzone : Elle permet de vérifier la validité des fichiers de zones avant de recharger la configuration.
# named-checkzone example.com /var/cache/bind/db.example.com zone example.com/IN: loaded serial 20080315 OK
# named-checkzone 0.168.192.in-addr.arpa /var/cache/bind/db.example.com.inv zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 OK
Liens et Ressources
rfc1035 - Implementation ans specifications
rfc1591 - Domain Name System Structure and Delegation
rfc2606 - Reserved Top Level DNS Names
http://www.bind9.net/manual/bind/9.3.2/Bv9ARM - Bind 9 Administrator Manual
- Services Whois :
?ToDos
- Finir les définitions
- Ajouter DNSSEC.