TOC

Comment configurer la liaison en tant que serveur de cache ou de transfert DNS sur Ubuntu 16.04

introduction

Le DNS, ou système de noms de domaine, est souvent un composant difficile à maîtriser lorsqu’on apprend à configurer des sites Web et des serveurs. Bien que la plupart des gens choisissent probablement d’utiliser les serveurs DNS fournis par leur société d’hébergement ou leur registraire de domaine, la création de vos propres serveurs DNS présente certains avantages.

Dans ce guide, nous expliquerons comment installer et configurer le serveur DNS Bind9 en tant que serveur DNS de mise en cache ou de transfert sur des machines Ubuntu 16.04. Ces deux configurations présentent des avantages pour la gestion de réseaux de machines.

Prérequis et objectifs

Pour compléter ce guide, vous devez d’abord connaître la terminologie courante du DNS. Consultezthis guide pour en savoir plus sur certains des concepts que nous mettrons en œuvre dans ce guide.

Nous présenterons deux configurations distinctes qui atteignent des objectifs similaires: un serveur DNS de mise en cache et de transfert.

Pour suivre, vous devez avoir accès à deux ordinateurs (dont au moins un serveur Ubuntu 16.04). L'un fonctionnera en tant que client et l'autre sera configuré en tant que serveur DNS. Pour mettre le serveur dans un bon état préliminaire, suivez lesUbuntu 16.04 initial server setup guide.

Les détails de notre exemple de configuration sont les suivants:

Role Adresse IP

Serveur dns

192.0.2.2

Client

192.0.2.100

Nous allons vous montrer comment configurer la machine client pour utiliser le serveur DNS pour les requêtes. Nous allons vous montrer comment configurer le serveur DNS dans deux configurations différentes, en fonction de vos besoins.

Mise en cache du serveur DNS

La première configuration sera pour un serveur DNScaching. Ce type de serveur est également appelé résolveur car il gère les requêtes récursives et peut généralement gérer le travail fastidieux de suivi des données DNS provenant d'autres serveurs.

Lorsqu'un serveur DNS en mémoire cache la réponse à une requête d'un client, il la renvoie au client. Mais il stocke également la réponse dans son cache pendant la période de temps autorisée par la valeur TTL des enregistrements. Le cache peut ensuite être utilisé comme source pour les demandes ultérieures afin d’accélérer le temps total aller-retour.

Presque tous les serveurs DNS que vous pourriez avoir dans votre configuration réseau mettront en cache les serveurs DNS. Celles-ci compensent le manque de bibliothèques de résolution DNS adéquates implémentées sur la plupart des ordinateurs clients. Un serveur DNS en cache est un bon choix dans de nombreuses situations. Si vous ne souhaitez pas vous fier au serveur DNS de votre fournisseur d’accès ou à d’autres serveurs DNS accessibles au public, créer votre propre serveur de mise en cache est un bon choix. S'il se trouve à proximité physique des machines clientes, il est également très probable que les temps de requête DNS seront améliorés.

Serveur DNS de transfert

La deuxième configuration que nous allons démontrer est un serveur DNSforwarding. Un serveur DNS de transfert semblera presque identique à un serveur de mise en cache du point de vue du client, mais les mécanismes et la charge de travail sont assez différents.

Un serveur DNS de transfert offre le même avantage que de conserver un cache pour améliorer les temps de résolution DNS des clients. Cependant, il ne fait en réalité aucune interrogation récursive. Au lieu de cela, il transfère toutes les demandes à un serveur de résolution externe, puis met en cache les résultats à utiliser pour les requêtes ultérieures.

Cela permet au serveur de transfert de répondre à partir de son cache, sans qu'il soit obligé d'effectuer tout le travail des requêtes récursives. Cela permet au serveur de ne faire qu'une seule demande (la demande du client transféré) au lieu de devoir passer par toute la routine de récursivité. Cela peut être un avantage dans les environnements où le transfert de bande passante externe est coûteux, où il peut être nécessaire de changer souvent vos serveurs de mise en cache ou lorsque vous souhaitez transférer des requêtes locales vers un serveur et des requêtes externes vers un autre serveur.

Installer Bind sur le serveur DNS

Quel que soit le choix de configuration que vous souhaitez utiliser, la première étape de la mise en œuvre d'un serveur DNS Bind consiste à installer le logiciel proprement dit.

Le logiciel Bind est disponible dans les référentiels par défaut d'Ubuntu, il nous suffit donc de mettre à jour notre index de package local et d'installer le logiciel à l'aide deapt. Nous allons également inclure la documentation et quelques utilitaires courants: 

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

Maintenant que les composants Bind sont installés, nous pouvons commencer à configurer le serveur. Le serveur de transfert utilise la configuration du serveur de mise en cache comme point de départ. Par conséquent, quel que soit votre objectif final, configurez d'abord le serveur en tant que serveur de mise en cache.

Configurer en tant que serveur DNS de mise en cache

Dans un premier temps, nous verrons comment configurer Bind pour qu’il agisse comme un serveur DNS de mise en cache. Cette configuration forcera le serveur à rechercher de manière récursive des réponses auprès d'autres serveurs DNS lorsqu'un client émettra une requête. Cela signifie qu'il interroge chaque serveur DNS associé jusqu'à ce qu'il trouve la réponse complète.

Les fichiers de configuration Bind sont conservés par défaut dans un répertoire à/etc/bind. Déplacer dans ce répertoire maintenant: 

cd /etc/bind

Nous ne nous intéresserons pas à la majorité des fichiers de ce répertoire. Le fichier de configuration principal est appelénamed.conf (named etbind sont deux noms pour la même application). Ce fichier source simplement le fichiernamed.conf.options, le fichiernamed.conf.local et le fichiernamed.conf.default-zones.

Pour un serveur DNS de mise en cache, nous ne modifierons que le fichiernamed.conf.options. Ouvrez-le dans votre éditeur de texte avec les privilèges sudo: 

sudo nano named.conf.options

Avec les commentaires supprimés pour plus de lisibilité, le fichier ressemble à ceci:

/etc/bind/named.conf.options

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Pour configurer la mise en cache, la première étape consiste à configurer une liste de contrôle d'accès, ou ACL.

En tant que serveur DNS utilisé pour résoudre les requêtes récursives, nous ne souhaitons pas que le serveur DNS soit utilisé de manière abusive par des utilisateurs malveillants. Une attaque appeléeDNS amplification attack est particulièrement gênante car elle peut amener votre serveur à participer à des attaques de déni de service distribuées.

Une attaque par amplification DNS est un moyen par lequel des utilisateurs malveillants tentent de supprimer des serveurs ou des sites sur Internet. Pour ce faire, ils essaient de trouver des serveurs DNS publics capables de résoudre les requêtes récursives. Ils usurpent l’adresse IP de la victime et envoient une requête qui renvoie une réponse volumineuse au serveur DNS. Ce faisant, le serveur DNS répond à une petite requête avec une charge utile importante dirigée vers le serveur victime, amplifiant ainsi la bande passante disponible de l'attaquant.

L'hébergement d'un serveur DNS public récursif nécessite beaucoup de configuration et d'administration spéciales. Pour éviter que votre serveur ne soit utilisé à des fins malveillantes, nous allons configurer une liste d'adresses IP ou de plages de réseaux de confiance.

Au-dessus du blocoptions, nous allons créer un nouveau bloc appeléacl. Créez une étiquette pour le groupe de LCA que vous configurez. Dans ce guide, nous appellerons le groupegoodclients.

/etc/bind/named.conf.options

acl goodclients {
};

options {
    . . .

Dans ce bloc, répertoriez les adresses IP ou les réseaux autorisés à utiliser ce serveur DNS. Étant donné que notre serveur et notre client fonctionnent tous deux dans le même sous-réseau / 24 dans notre exemple, nous limiterons cet exemple à ce réseau. Vous devez ajuster cela pour inclure vos propres clients et non des tiers. Nous ajouterons égalementlocalhost etlocalnets qui tenteront de le faire automatiquement:

/etc/bind/named.conf.options

acl goodclients {
    192.0.2.0/24;
    localhost;
    localnets;
};

options {
    . . .

Maintenant que nous avons une ACL de clients pour lesquels nous voulons résoudre la demande, nous pouvons configurer ces capacités dans le blocoptions. Dans ce bloc, ajoutez les lignes suivantes:

/etc/bind/named.conf.options

. . .

options {
    directory "/var/cache/bind";

    recursion yes;
    allow-query { goodclients; };
    . . .

Nous avons explicitement activé la récursivité, puis configuré le paramètreallow-query pour utiliser notre spécification ACL. Nous aurions pu utiliser un paramètre différent, commeallow-recursion pour référencer notre groupe ACL. Si présent et que la récursivité est activée,allow-recursion dictera la liste des clients pouvant utiliser les services récursifs.

Cependant, siallow-recursion n'est pas défini, alors Bind retombe sur la listeallow-query-cache, puis sur la listeallow-query, et enfin une valeur par défaut delocalnets etlocalhost seulement. Puisque nous configurons un serveur de mise en cache uniquement (il n’a pas de zones faisant autorité et ne transmet pas les requêtes), la listeallow-query s’appliquera toujours uniquement à la récursivité. Nous l'utilisons parce que c'est la manière la plus générale de spécifier la liste de contrôle d'accès.

Lorsque vous avez terminé ces modifications, enregistrez et fermez le fichier.

C'est en fait tout ce qui est requis pour un serveur DNS en cache. Si vous avez décidé qu'il s'agit du type de serveur que vous souhaitez utiliser, n'hésitez pas à passer à l'étape suivante pour savoir comment vérifier vos fichiers de configuration, redémarrer le service et implémenter les configurations client.

Sinon, continuez à lire pour apprendre comment configurer un serveur DNS de transfert.

Configurer en tant que serveur DNS de transfert

Si un serveur DNS de transfert convient mieux à votre infrastructure, nous pouvons facilement le configurer.

Nous allons commencer par la configuration que nous avons laissée dans la configuration du serveur de mise en cache. Le fichiernamed.conf.options devrait ressembler à ceci:

/etc/bind/named.conf.options

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Nous utiliserons la même liste de contrôle d'accès pour restreindre votre serveur DNS à une liste spécifique de clients. Cependant, nous devons modifier la configuration afin que le serveur n'essaye plus d'effectuer lui-même des requêtes récursives.

Pour ce faire, nous faisonsnot changerrecursion en no. Le serveur de transfert fournit toujours des services récursifs en répondant aux requêtes pour les zones pour lesquelles il ne fait pas autorité. Au lieu de cela, nous devons configurer une liste de serveurs de mise en cache vers lesquels transférer nos demandes.

Cela sera fait dans le blocoptions {}. Tout d'abord, nous créons un bloc à l'intérieur appeléforwarders qui contient les adresses IP des serveurs de noms récursifs vers lesquels nous voulons transférer les requêtes. Dans notre guide, nous utiliserons les serveurs DNS publics de Google (8.8.8.8 et8.8.4.4):

/etc/bind/named.conf.options

. . .

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

Ensuite, nous devrions définir la directiveforward sur «seulement» car ce serveur transmettra toutes les requêtes et ne devrait pas tenter de résoudre les requêtes par lui-même.

Le fichier de configuration ressemblera à ceci lorsque vous aurez terminé:

/etc/bind/named.conf.options

. . .

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Une dernière modification que nous devrions apporter concerne les paramètresdnssec. Avec la configuration actuelle, en fonction de la configuration des serveurs DNS transférés, des erreurs semblables à celles-ci peuvent apparaître dans les journaux: 

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

Pour éviter cela, modifiez le paramètrednssec-validation sur «yes» et activez explicitement dnssec:

/etc/bind/named.conf.options

. . .

forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no;    # conform to RFC1035
. . .

Enregistrez et fermez le fichier lorsque vous avez terminé. Vous devriez maintenant avoir un serveur DNS de transfert en place. Passez à la section suivante pour valider vos fichiers de configuration et redémarrer le démon.

Testez votre configuration et relancez la liaison

Maintenant que votre serveur Bind est configuré en tant que serveur DNS de mise en cache ou de transfert, nous sommes prêts à implémenter nos modifications.

Avant de franchir le pas et de redémarrer le serveur Bind sur notre système, nous devrions utiliser les outils inclus de Bind pour vérifier la syntaxe de nos fichiers de configuration.

Nous pouvons le faire facilement en tapant: 

sudo named-checkconf

S'il n'y a pas d'erreur de syntaxe dans votre configuration, l'invite du shell retournera immédiatement sans afficher de sortie.

Si vous avez des erreurs de syntaxe dans vos fichiers de configuration, vous serez averti de l'erreur et du numéro de ligne où cela se produit. Si cela se produit, revenez en arrière et vérifiez si vos fichiers contiennent des erreurs.

Une fois que vous avez vérifié que vos fichiers de configuration ne contiennent aucune erreur de syntaxe, redémarrez le démon Bind pour implémenter vos modifications: 

sudo systemctl restart bind9

Si vous avez suivi le guide de configuration initiale du serveur, le pare-feu UFW est activé sur votre serveur. Nous devons autoriser le trafic DNS sur notre serveur afin de répondre aux demandes des clients.

Activez une exception à la politique de pare-feu pour Bind en tapant: 

sudo ufw allow Bind9

Ensuite, gardez un œil sur les journaux du serveur pendant que vous configurez votre ordinateur client pour vous assurer que tout se passe bien. Laissez ceci en cours d'exécution sur le serveur: 

sudo journalctl -u bind9 -f

Ouvrez maintenant une nouvelle fenêtre de terminal pour configurer vos ordinateurs clients.

Configurer la machine client

Maintenant que votre serveur est opérationnel, vous pouvez configurer votre ordinateur client pour utiliser ce serveur DNS pour les requêtes.

Connectez-vous à votre ordinateur client. Assurez-vous que le client que vous utilisez a été spécifié dans le groupe de LCA que vous avez défini pour votre serveur DNS. Sinon, le serveur DNS refusera de répondre aux demandes du client.

Nous devons éditer le fichier/etc/resolv.conf pour pointer notre serveur vers le serveur de noms. Les modifications apportées ici ne dureront que jusqu'au redémarrage, ce qui est excellent pour les tests. Si nous sommes satisfaits des résultats de nos tests, nous pouvons rendre ces modifications permanentes.

Ouvrez le fichier avec les privilèges sudo dans votre éditeur de texte: 

sudo nano /etc/resolv.conf

Le fichier répertorie les serveurs DNS à utiliser pour résoudre les requêtes en définissant les directivesnameserver. Mettez en commentaire toutes les entrées actuelles et ajoutez une lignenameserver qui pointe vers votre serveur DNS:

/etc/resolv.conf

nameserver 192.0.2.2
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Enregistrez et fermez le fichier.

Maintenant, vous pouvez tester pour vous assurer que les requêtes peuvent être résolues correctement à l'aide des outils courants.

Vous pouvez utiliserping pour tester que les connexions peuvent être établies aux domaines: 

ping -c 1 google.com
OutputPING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Cela signifie que notre client peut se connecter avecgoogle.com en utilisant notre serveur DNS.

Nous pouvons obtenir des informations plus détaillées en utilisant des outils spécifiques au DNS commedig. Essayez un autre domaine cette fois-ci: 

dig linuxfoundation.org
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6017    IN  A   140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

Vous pouvez voir que la requête a pris 36 millisecondes. Si nous renouvelons la demande, le serveur doit extraire les données de son cache, ce qui diminue le temps de réponse: 

dig linuxfoundation.org
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6012    IN  A   140.211.169.4

;; Query time: 1 msec
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

Comme vous pouvez le constater, la réponse en cache est beaucoup plus rapide.

Nous pouvons également tester la recherche inversée en utilisant l'adresse IP que nous avons trouvée (140.211.169.4 dans notre cas) avec l'option-x de dig: 

dig -x 140.211.169.4
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME   4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

Comme vous pouvez le constater, la recherche inversée réussit également.

De retour sur votre serveur DNS, vous devriez voir si des erreurs ont été enregistrées lors de vos tests. Une erreur commune qui peut apparaître est la suivante: 

Output from sudo journalctl -u bind9 -f. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

Celles-ci indiquent que le serveur tente de résoudre les informations IPv6 mais qu'il n'est pas configuré pour IPv6. Vous pouvez résoudre ce problème en indiquant à Bind de n'utiliser que IPv4.

Pour ce faire, nous pouvons modifier le fichier unité systemd qui lance Bind9: 

sudo systemctl edit --full bind9

Dans le fichier qui apparaît, ajoutez-4 à la fin de la ligneExecStart pour restreindre le serveur aux requêtes IPv4:

Modification du fichier d'unité bind9 systemd 

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind -4
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Rechargez le démon systemd pour lire le fichier d'unité modifié dans le système init: 

sudo systemctl daemon-reload

Redémarrez le service Bind9 pour implémenter les modifications: 

sudo systemctl restart bind9

Vous ne devriez plus voir ces erreurs dans les journaux.

Rendre les paramètres DNS du client permanents

Comme mentionné précédemment, les paramètres/etc/resolv.conf qui pointent la machine cliente vers notre serveur DNS ne survivront pas à un redémarrage. Pour apporter les modifications en dernier lieu, nous devons modifier les fichiers utilisés pour générer ce fichier.

Si la machine cliente exécute Debian ou Ubuntu, ouvrez le fichier/etc/network/interfaces avec les privilèges sudo: 

sudo nano /etc/network/interfaces

Recherchez le paramètredns-nameservers. Vous pouvez supprimer les entrées existantes et les remplacer par votre serveur DNS ou simplement ajouter votre serveur DNS parmi les options suivantes:

/etc/network/interfaces

. . .

iface eth0 inet static
        address 192.168.2.100
        netmask 255.255.255.0
        gateway 192.168.2.1
        dns-nameservers 192.0.2.2

. . .

Enregistrez et fermez le fichier lorsque vous avez terminé. La prochaine fois que vous démarrez, vos paramètres seront appliqués.

Si le client exécute CentOS ou Fedora, vous devez ouvrir le fichier/etc/sysconfig/network/network-scripts/ifcfg-eth0 à la place: 

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

À l'intérieur, recherchez les lignes commençant parDNS. RemplacezDNS1 par votre serveur DNS. Si vous ne souhaitez pas utiliser les autres serveurs DNS comme solution de secours, supprimez les autres entrées:

/etc/sysconfig/network-scripts/ifcfg-eth0

. . .
DNS1=192.0.2.2
. . .

Enregistrez et fermez le fichier lorsque vous avez terminé. Votre client doit utiliser ces paramètres au prochain démarrage.

Conclusion

Vous devriez maintenant avoir un serveur DNS de mise en cache ou de transfert configuré pour servir vos clients. Cela peut être un excellent moyen d'accélérer les requêtes DNS pour les machines que vous gérez.

Related