Configuration parfaite de DjbDNS sur Ubuntu Server 8.04 (amd64) Hardy

DjbDNS est une collection d’outils du système de noms de domaine. Il comprend des logiciels pour toutes les opérations fondamentales de DNS :

Cache DNS : Trouver les adresses des hôtes Internet. Lorsque un navigateur veut contacter www.hotwired.com, il demande d’abord à un cache DNS, tel que le dnscache de djbdns, de trouver l’adresse IP de www.hotwired.com. Les fournisseurs de services Internet exécutent dnscache pour trouver les adresses IP demandées par leurs clients. Si vous exécutez un ordinateur personnel ou un poste de travail, vous pouvez exécuter votre propre dnscache pour accélérer votre navigation web.

Serveur DNS : Publier les adresses des hôtes Internet. L’adresse IP de www.hotwired.com est publiée par les serveurs DNS de HotWired. djbdns comprend un serveur DNS polyvalent, tinydns ; les administrateurs réseau exécutent tinydns pour publier les adresses IP de leurs ordinateurs. djbdns comprend également des serveurs spécialisés pour publier des murs DNS et des RBL.

Client DNS : Communiquer avec un cache DNS. djbdns comprend une bibliothèque C de client DNS et plusieurs utilitaires de client DNS en ligne de commande. Les programmeurs utilisent ces outils pour envoyer des requêtes aux caches DNS.

DjbDNS comprend également plusieurs outils de débogage DNS, notamment dnstrace, que les administrateurs utilisent pour diagnostiquer des serveurs distants mal configurés.

Fonctionnalités de sécurité :

dnscache s’exécute en tant qu’uid non-root dédié à l’intérieur d’une prison chroot, donc il ne peut pas toucher au reste de la machine.
tinydns s’exécute en tant qu’autre uid non-root dédié à l’intérieur de sa propre prison chroot.
walldns s’exécute en tant qu’autre uid non-root dédié à l’intérieur de sa propre prison chroot.
dnscache rejette les requêtes DNS provenant d’une liste spécifiée d’adresses IP.
dnscache et la bibliothèque DNS utilisent un nouvel ID de requête et un nouveau port UDP pour chaque paquet de requête. Ils rejettent les réponses DNS de toute adresse IP autre que celle à laquelle la requête correspondante a été envoyée.
dnscache utilise un générateur cryptographique pour sélectionner des numéros de port et des ID imprévisibles.
dnscache est immunisé contre l’empoisonnement de cache.

tinydns ne met jamais en cache d’informations. Il ne prend pas en charge la récursivité.

Pré-installation

apt-get install build-essential  
mkdir /tmp/downloads  
cd $_  
wget -c  HYPERLINK "http://www.thedjbway.org/patches/djb_errno_patches.tgz" http://www.thedjbway.org/patches/djb_errno_patches.tgz  
tar -zxvf djb_errno_patches.tgz  
wget -c   HYPERLINK "http://cr.yp.to/daemontools/daemontools-0.76.tar.gz" http://cr.yp.to/daemontools/daemontools-0.76.tar.gz  
wget -c  HYPERLINK "http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz" http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz  
wget -c  HYPERLINK "http://cr.yp.to/djbdns/djbdns-1.05.tar.gz" http://cr.yp.to/djbdns/djbdns-1.05.tar.gz

Installer tous les paquets

a. Installer ucspi-tcp-src :

cd /tmp/downloads  
tar -zxvf ucspi-tcp-0.88.tar.gz  
cd ucspi-tcp-0.88  
patch -p1 < /tmp/downloads/ucspi-tcp-0.88.errno.patch  
make  
make setup check

b. daemontools

cd /tmp/downloads  
tar -zxvf  daemontools-0.76.tar.gz  
cd admin/daemontools-0.76/  
touch /etc/inittab  
patch -p1 < /tmp/downloads/daemontools-0.76.errno.patch  
package/install

vi /etc/event.d/svscan

# svscan - daemontools

start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /command/svscanboot

Cet installateur ne crée que des liens vers toutes les commandes svscan dans /command, il est donc préférable de copier celles-ci :

cd /command  
rm -rf *  
cp /tmp/downloads/admin/daemontools/command/* /command/

C’est tout… ensuite (vous pourriez avoir besoin de redémarrer) …

initctl start svscan

c. djbdns

cd /tmp/downloads  
tar -zxvf djbdns-1.05.tar.gz  
cd djbdns-1.05  
echo gcc -O2 -include /usr/include/errno.h > conf-cc   
make  
make setup check

Configurer les paquets

Créer des utilisateurs (s’ils n’ont pas été créés automatiquement) :

adduser --no-create-home --disabled-login --shell /bin/false dnscache  
adduser --no-create-home --disabled-login --shell /bin/false dnslog  
adduser --no-create-home --disabled-login --shell /bin/false tinydns

Configurer dnscache :

Dans notre scénario, nous avons besoin que chaque serveur maître et esclave soit à la fois “autoritaire” et “caching”. Il est donc très important de comprendre comment y parvenir avec djbdns. Contrairement à bind, djbdns utilise une IP individuelle pour chaque type de service DNS. Par défaut, chaque système est prêt avec 2 IP => une IP hôte et l’autre est une IP de boucle. Donc, tout système sur le LAN doit toucher le DNS de cache, d’où l’IP hôte pour le DNS de cache. Et nous exécuterons l’autoritaire sur l’IP de boucle, puis lierons cela au DNS de cache, permettant ainsi aux hôtes LAN de requêter également les enregistrements d’hôtes autoritaires.

mkdir /var/lib/svscan  
dnscache-conf dnscache dnslog /var/lib/svscan/dnscache   
ln -sf /var/lib/svscan/dnscache /service

Vérifiez que le répertoire “supervise” a été créé dans /service/dnscache
Pour vérifier qu’il fonctionne : ajoutez simplement une seule entrée comme ‘nameserver ’ dans /etc/resolv.conf et vérifiez une requête de site web public en utilisant ‘nslookup’ ou ‘dig’ depuis la ligne de commande.

Maintenant, vous devez permettre aux hôtes LAN de requêter depuis celui-ci. Créez simplement un fichier vide nommé d’après votre réseau ou sous-réseau comme :

touch /etc/dnscache/root/ip/

C’est tout. Maintenant, vous pouvez requêter depuis n’importe quel hôte de ce . De même, vous pouvez activer plusieurs hôtes, réseaux ou sous-réseaux pour la requête.
Contrairement à bind, vous pouvez ajuster la taille du cache du serveur de noms en modifiant le fichier /etc/dnscache/env/CACHESIZE. Vous pouvez également rafraîchir ou vider manuellement le cache en exécutant la commande suivante :

svc -t /service/dnscache

Temporairement, vous pouvez arrêter et démarrer dnscache avec les commandes suivantes :

svc -d /service/dnscache => pour arrêter le service dnscache  
svc -u /service/dnscache => pour démarrer le service dnscache

Configurer tinydns :

tinydns-conf tinydns dnslog /var/lib/svscan/tinydns   
ln -sf /var/lib/svscan/tinydns /service

Vérifiez que le répertoire “supervise” a été créé dans /service/tinydns.

Ils ne contiennent pas encore d’entrées de zone pour des domaines, mais nous y arriverons bientôt. Eh bien, contrairement à bind, les informations de zone sont écrites dans un seul fichier (même pour plusieurs zones, y compris les zones inverses) et c’est /var/lib/svscan/tinydns/root/data. C’est un fichier modifiable par l’homme qui est ensuite converti en format binaire à l’aide d’une commande tinydns et ce binaire est appelé format cdb, donc ce fichier binaire est /var/lib/svscan/tinydns/root/data.cdb d’où tinydns répond à toutes les requêtes. La syntaxe pour les enregistrements de zone est très courte et compacte par rapport à bind. Voici quelques exemples :

a. Pour l’entrée du serveur de noms :

  .in.domain.com:10.20.0.10:ns1.in.domain.com  
  .in.domain.com:10.20.0.12:ns2.in.domain.com

b. Pour le reverse-dns pour le serveur de noms ci-dessus :

  .10.in-addr.arpa::ns1.in.domain.com  
  .10.in-addr.arpa::ns2.in.domain.com

c. Pour les enregistrements MX :

  @in.domain.com:165.212.65.113:mx.usa.net:10  
  @in.domain.com:10.20.0.12:mail.in.domain.com:20

d. Enregistrements A :

  =host0001.in.domain.com:10.10.0.101

e. Enregistrements alias pour les hôtes :

  +host01.in.domain.com:10.10.0.101  
  +mysql01.in.domain.com:10.10.0.101

Et enfin, convertissez /var/lib/svscan/tinydns/root/data en format cdb par

tinydns-data

cd /var/lib/svscan/tinydns/root  
make

À la fin, pour lier ces informations de zone au serveur DNS de cache, créez des fichiers nommés comme 10.in-addr.arpa, in.domain.com et domain.com, etc. dans le répertoire /var/lib/svscan/dnscache/root/servers/, dont le contenu doit être 127.0.0.1 (l’IP de boucle). C’est tout. Tout est configuré.

Remarque : Chaque fois que vous apportez des modifications aux données et créez un fichier data.cdb modifié, n’oubliez pas de rafraîchir ou de vider le cache.

svc -t /services/*

Configuration du serveur esclave utilisant Djbdbs

Il suffit de suivre http://www.seebq.com/dns-replication-using-rsync et quelques ajustements sur certains fichiers du maître et des esclaves.

a. Modifications sur le /var/lib/svscan/tinydns/root/Makefile du maître : Modifiez le fichier comme suit

remote: data.cdb
  rsync -az -e ssh data.cdb :/service/tinydns/root/data.cdb
  ssh  'svc -t /service/dnscache'
data.cdb: data
  /usr/local/bin/tinydns-data
  svc -t /service/dnscache

b. Modifications sur le fichier /var/libsvscan/tinydns/root/data de l’esclave comme

# Ne modifiez pas les données sur cet ordinateur ! data.cdb est copié depuis le MAÎTRE.
# La ligne suivante protège data.cdb en arrêtant make.
9

Ainsi, si par erreur quelqu’un tape la commande make dans le répertoire /etc/tinydns/root ou la commande tinydns-data, cela ne fera que vider le cache car il n’y a pas de fichier de données dans l(es) esclave(s).

Et oui, il suffit de configurer une connexion auto-ssh entre le maître et l(es) esclave(s) afin que les modifications ci-dessus automatisent le processus. Les modifications ci-dessus ne pousseront que le fichier data.cdb vers l(es) esclave(s). Donc, aucune chance d’avoir des données différentes entre les serveurs de noms, ce qui signifie cohérence entre tous.

Sauvegarde et restauration

Au minimum, nous avons juste besoin d’une copie du fichier /var/lib/svscan/tinydns/root/data ou au maximum de l’ensemble de /var/lib/svscan/dnscache et /var/lib/svscan/tinydns. C’est tout.

Pour la restauration, il suffit de configurer dnscache ou tinydns, cela ne prendra guère de temps, et de copier les données de sauvegarde. Enfin, créez un lien symbolique vers /service. C’est tout.