Bind (Berkeley Internet Name Domain) is a popular DNS server. It can be used to host a master zone or simply as a DNS cache.
Install the package :
Configuration files are located into /etc/bind/.
To make the operating system use bind localy, change /etc/resolv.conf to :
nameserver 127.0.0.1
By default bind is configured as a DNS proxy, requesting directly the DNS root servers. This configuration is independent of provider's DNS.
Default configuration inside named.conf.default-zones :
// prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; };
It is also possible to forward requests to another DNS server.
Configuration example to add into named.conf.local :
zone "." { type forward; forward only; forwarders { 192.168.10.10; } ; };
Configuration example to forward only one domain :
zone "thisdomain.com" { type forward; forward only; forwarders { 10.0.10.11; 10.0.10.12; } ; };
It is one of the main function or Bind : create a public or private zone.
This task is done in two steps :
The following example show the configuration of bouthors.fr.
The file below is the zone file for bouthors.fr, saved into db.bouthors.fr :
$ORIGIN . $TTL 300 ; 5 minutes bouthors.fr IN SOA dc1.bouthors.fr. matthieu.bouthors.fr. ( 1110210001 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 300 ; minimum (5 minutes) ) NS dc1.bouthors.fr. A 88.174.63.25 MX 10 mail.bouthors.fr. $ORIGIN bouthors.fr. matthieu CNAME www www A 88.174.63.25 mail CNAME ghs.google.com. dc1 A 88.174.63.25
A zone file is composed by several records of different types (SOA, NS, A, MX, …). In details :
Please note that text records are relative to the current zone, you can add a ”.” at the end to make them absolute.
Then, to register the new zone into Bind, update the file /etc/bind/named.conf.local :
zone "bouthors.fr" { type master; file "/etc/bind/db.bouthors.fr"; };
Bind needs to be restarted to apply the changes :
/etc/init.d/bind9 restart
To add a sub zone, the steps are quite similar to the primary zone configuration :
Example of the sub zone for ddns.bouthors.fr which is dedicated to dynamic records.
Zone file :
$ORIGIN . $TTL 300 ; 5 minutes ddns.bouthors.fr IN SOA dc1.bouthors.fr. matthieu.bouthors.fr. ( 2011102303 ; serial 3600 ; refresh (1H) 1200 ; retry (20m) 2419200 ; expire (4 weeks) 180 ; minimum (3 minutes) ) NS dc1.bouthors.fr.
Zone registration into named.conf.local :
zone "ddns.bouthors.fr" { type master; file "/etc/bind/db.ddns.bouthors.fr"; };
Update of the top zone :
$ORIGIN . $TTL 300 ; 5 minutes bouthors.fr IN SOA dc1.bouthors.fr. matthieu.bouthors.fr. ( 1110210001 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 300 ; minimum (5 minutes) ) NS dc1.bouthors.fr. ddns.bouthors.fr. NS dc1.bouthors.fr.
If DNS servers are part of the sub zone (for example if the dns server of ddns.bouthors.fr would be dc1.ddns.bouthors.fr), then there is a loop : DNS servers of ddns.bouthors.fr are required to resolve dc1.ddns.bouthors.fr. In this case, we need to add glue records : dc1.ddns.bouthors.fr will be addded to the top zone bouthors.fr. For example :
dc1.ddns.bouthors.fr. NS 192.168.10.2
To add your own reverse DNS zone, create a zone fine. For example db.192.168 :
$ORIGIN . $TTL 60 ; 1 minute 168.192.in-addr.arpa IN SOA dc1.bouthors.fr. matthieu.bouthors.fr. ( 1110210001 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 60 ; minimum (1 minute) ) NS dc1.bouthors.fr. $ORIGIN 10.168.192.in-addr.arpa. 1 PTR rt1.bouthors.fr. 2 PTR dc1.bouthors.fr.
Then register this zone into named.conf.local :
zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; };
The goal of the secondary server is to improve the availability of the service. Moreover it is required for any public DNS.
When the primary DNS is updated, the secondary servers will be informed and will update their zone.
The serial number of the zone is used to identify the version of the zone, so it should be increased at each modification.
By default, a primary server will notify and allow transferts to all servers defined as NS records.
But you can also configure this parameters manually, for example :
zone "bouthors.fr" { type master; file "/etc/bind/db.bouthors.fr"; allow-transfer {192.168.10.3;}; also-notify {192.168.10.3;}; };
On the secondary server, the slave zone definition is quite simple :
zone "bouthors.fr" { type slave; file "/var/cache/bind/db.bouthors.fr"; masters {192.168.10.2;}; };
Please choice a writable folder and define the IP of the master DNS.
Dynamic updates (aka Dynamic DNS or DDNS) allow to update dynamically records.
This is useful for computers using DHCP.
Updates can be sent by DHCP clients or servers. DHCP server updates are better because records can be removed when the IP allocation is over.
Very important : when a zone is configured to allow dynamic updates, a journal file is created to save updates temporary. Direct edition of the zone file is not possible anymore.
You need to use one of the following method :
Before activating the dynamic updates, check that Bind can write into /etc/bind for journal files creation :
chown bind /etc/bind
Add updates authorization for the zone with allow-update :
zone "ddns.bouthors.fr" { type master; file "/etc/bind/db.ddns.bouthors.fr"; allow-update { 192.168.10.2;192.168.10.3;}; };
After the restart of Bind, test the DDNS with nsupdate :
# nsupdate > server 192.168.10.2 > zone ddns.bouthors.fr > update add test.ddns.bouthors.fr. 300 IN A 192.168.10.150 > send > quit # nslookup test.ddns.bouthors.fr Server: 192.168.10.2 Address: 192.168.10.2#53 Name: test.ddns.bouthors.fr Address: 192.168.1.111 Name: test.ddns.bouthors.fr Address: 192.168.10.150 #
To block updates while editing the zone file, use “rndc freeze zone” and “rndc unfreeze zone”, for example :
# rndc freeze ddns.bouthors.fr # vi /etc/bind/db.ddns.bouthors.fr # rndc unfreeze ddns.bouthors.fr A zone reload and thaw was started. Check the logs to see the result. #
It is higly recommended to secure the updates with TSIG because it is really easy to usurp DNS updates.
Il est possible de sécuriser les échanges entre serveurs (update, transfert) avec TSIG.
Les étapes sont :
La génération de la clef se fait avec la commande dnssec-keygen (remplacer dc1-dc2 par les noms de vos serveurs) :
dnssec-keygen -a hmac-md5 -b 128 -n HOST dc1-dc2
Sous VMWare le résultat n'arrive pas rapidement (cf bug https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/650721), le plus simple est de générer de l'activité disque par exemple avec “find /”).
Deux fichiers sont alors créés avec les extensions .key et .private, nous allons uniquement utiliser la clef présente à la ligne “Key:” dans le fichier .private :
Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: 0jnu3SdsMvzzlmTDPYRceA== Bits: AAA=
Il faut ensuite déclarer cette clef sur les deux serveurs, par exemple sur le master :
key dc1-dc2 { algorithm hmac-md5; secret "0jnu3SdsMvzzlmTDPYRceA=="; }; server 192.168.10.3 { keys {dc1-dc2;}; }; zone "bouthors.fr" { type master; file "/etc/bind/db.bouthors.fr"; allow-transfer { key dc1-dc2 ;}; also-notify {192.168.10.3;}; allow-update { key dc1-dc2 ;}; };
Sur le slave :
key dc1-dc2 { algorithm hmac-md5; secret "0jnu3SdsMvzzlmTDPYRceA=="; }; server 192.168.10.2 { keys {dc1-dc2;}; };
Enfin, il est conseillé de sécuriser la configuration en supprimant les fichiers .key et .private et en supprimant l'accès à named.conf.local :
chmod o-r named.conf.local
Communiquer via IPv6 et fournir des réponses IPv6 sont deux problématiques distinctes. Nous traitons ici de la résolution des noms DNS par des adresses IPv6.
L'annonce d'adresses IPv6 dans le DNS est très simple, il suffit d'ajouter des enregistrements de type AAAA dans la zone. Exemple :
web3 AAAA 2001:470:c981::24
Il est également possible de paramétrer une zone de résolution inverse.
Attention à bien respecter la notation reverse, chaque caractère hexadécimal est séparé par un point. Exemples :
Pour effectuer la transformation, utiliser la commande dig :
dig -x 2001:470:c981::24 ... ;; QUESTION SECTION: ;4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR ...
Dans l'exemple suivant, nous allons créer une zone reserve pour le réseau 2001:470:c981::/48
Il faut tout d'abord créer un nouveau fichier de zone /etc/bind/db.2001_470_c981 :
$ORIGIN . $TTL 60 ; 1 minute 1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa. IN SOA dc1.bouthors.fr. matthieu.bouthors.fr. ( 2011102301 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 60 ; minimum (1 minute) ) NS dc1.bouthors.fr. $ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa. 2.0 PTR dc1.bouthors.fr. 3.0 PTR dc2.bouthors.fr.
Puis ajouter la nouvelle zone à named.conf.local :
zone "1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa" { type master; file "/etc/bind/db.2001_470_c981"; allow-transfer { key dc1-dc2;}; also-notify {192.168.10.3;}; };
Remarque : la zone reverse IPv6 étant généralement publique, elle peut être synchronisée et annoncée comme les zones forward.
Look at reseau