From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
Autres langues
English ; français ;
Résumé :
Cette page vous permettra de mettre en place votre propre serveur DNS, sécurisé par DNSSEC, avec un cache local pour accélérer la résolution des noms de domaine et avec des DNS tiers respectueux de votre privée.

Pourquoi faire ?

Dans le passé, nous avions un annuaire téléphonique pour trouver le numéro de téléphone à partir du nom de la personne. En informatique, chaque machine ou site internet est identifié par une suite de chiffres appelée adresse IP. Comme il est plus compliqué de se rappeler une suite de chiffre qu’un nom, un site internet a un nom et nous avons aussi besoin d’une sorte d’annuaire pour retrouver son adresse IP. C’est le but du système DNS (Domain Name Server).

Les domaines d’internet sont structurés en une arborescence et des serveurs sont assignés par niveaux de cette arborescence. Le niveau le plus haut (comme .org, .com…) est couvert par des serveurs appelés root (racine en anglais). Il y en a 13 à travers le monde. Sans rentrer dans les détails, ce nombre est lié au nombre de chiffres d’une adresse IPv4 et à son protocole de communication. Pour une meilleure réponse, il y a des copies réparties sur la planète, montant le nombre à environ 1400 serveurs.

Quand vous voulez accéder à un site internet, il faut résoudre le nom de domaine, c’est-à-dire trouver l’adresse IP de la machine hébergeant le site. La requête sera d’abord envoyée à un serveur root et, si le serveur root n’a pas la réponse dans son cache, jusqu’à 2 autres serveurs (serveurs « Top Level Domain » et « Authoritative ») prendront le relai en série pour descendre dans l’arborescence des noms de domaine. Cela ralentira le processus, même s’il est en général très rapide.

Dans les faits et amont de ce processus, votre fournisseur d’accès internet (FAI) a, en général, ses propres serveurs DNS qui seront en premier lieu contactés. Ces serveurs DNS de votre FAI doivent aussi avoir un cache pour permettre d’aller plus vite dans ce processus de résolution de nom de domaine. De cette façon, votre FAI aura accès à la liste de tous les sites que vous visitez. Cela peut poser des questions en termes de respect des données personnelles et de contrôle de la bande passante. Dans certains pays, c’est un moyen d’appliquer la censure. Cela ouvre aussi des possibilités à des personnes malfaisantes pour substituer la vraie adresse IP par une adresse de leurs serveurs.

Pour garder le contrôle de vos données personnelles, une option est d’installer votre propre résolveur DNS comme unbound. C’est ce que ce wiki propose, pour la machine sur laquelle l’installation est faite.

unbound offre aussi une fonction de cache local qui permettra grandement d’accélérer votre navigation vers les sites que vous avez l’habitude de visiter. Cela diminuera aussi la charge sur les serveurs qui gèrent le Web, aidant ainsi la communauté et le bilan carbone (chaque goutte compte :)).

Il n’y a pas que les navigateurs internet qui ont besoin d’un processus de résolution de noms de domaine. Les clients email ont aussi ce besoin, par exemple. Unbound travaille pour tout le système et, ainsi, améliore et sécurise l’ensemble des requêtes DNS.

Pour s’assurer que les adresses IP trouvées ne sont pas corrompues, nous activerons le processus crypté d’authentification appelé DNSSEC (Domain Name System Security Extensions).

Ne seront pas couvertes par ce wiki des fonctionnalités complémentaires comme :

  • Blocage de certains sites.
  • Utilisation d’une machine pour servir de résolveur DNS à toutes les machines d’un réseau local.

Peu de connaissances du travail en ligne de commande est nécessaire. Il faudra principalement savoir comment éditer un fichier texte dans une console de commande, en tant que super-utilisateur (avec les éditeurs nano ou vi, par exemple).

Installation

Paquet

unbound est inclus dans les dépôts de Mageia. Vous pouvez l’installer soit graphiquement par Mageia Control Center soit par la ligne de commande suivante, en tant que super-utilisateur :

# urpmi unbound

Les serveurs Root

Nous avons besoin d’initialiser la liste des serveurs root par la commande suivante, en tant que super-utilisateur :

# curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache

Cette liste change peu souvent, mais il est quand même avisé de la rafraichir tous les mois. Nous utiliserons un "timer" systemd pour cela.

Pour cela, 2 fichiers sont nécessaires : /usr/lib/systemd/system/roothints.service and /usr/lib/systemd/system/roothints.timer

Il faut donc les créer en tant que super-utilisateurs.

/usr/lib/systemd/system/roothints.service contiendra :

[Unit] Description=Update root hints for unbound After=network.target [Service] ExecStart=/usr/bin/curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache

/usr/lib/systemd/system/roothints.timer contiendra :

[Unit] Description=Run root.hints monthly [Timer] OnCalendar=monthly Persistent=true [Install] WantedBy=timers.target

Maintenant, il faut lancer ce timer au démarrage de la machine par :

# systemctl enable --now roothints.timer

DNSSEC

Nous allons ici initialiser les clés de signature nécessaires par le processus DNSSEC de validation des réponses DNS. chroot est utilisé pour restreindre l’exécution de unbound dans le répertoire /etc/unbound. Le fichier des clés est donc placé dans le dossier /etc/unbound et l’utilisateur unbound doit y avoir les droits en écriture.

En tant que super-utilisateur, exécutez les 2 commandes suivantes :

# unbound-anchor -v -a /etc/unbound/root.key
# chown unbound /etc/unbound

Configuration de NTP

Si une donnée est périmée ou est datée dans le futur, unbound ne pourra pas résoudre le nom de domaine.

Il est donc important que l’horloge de votre système soit synchronisée avec les serveurs à travers le monde. Pour cela, nous allons utiliser le protocole NTP (Network Time Protocol).

Pour cela, lancer Mageia Control Center et aller dans le menu System tab. Ensuite, entrez dans le menu Manage date and time.

Comme montré ci-dessous, sélectionner la case Enable Network Time Protocol puis choisir un serveur NTP proche de chez vous. Cliquez sur Ok pour finir la configuration.

Activation of NTP server in MCC


Pour confirmer que NTP est activé, exécutez :

$ timedatectl

qui doit retourner quelque chose similaire à :

Local time: lun. 2021-07-12 21:02:39 CEST Universal time: lun. 2021-07-12 19:02:39 UTC RTC time: lun. 2021-07-12 19:02:39 Time zone: Europe/Paris (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no

System clock synchronized: yes et NTP service: active confirment que le paramétrage a bien été prise en compte.

Configuration

En préambule, si vous voulez être plus curieux, il est intéressant de faire le test standard du site DNS leak test.

Cela vous donnera la liste des serveurs DNS utilisés à ce point ; très probablement ceux de votre FAI. Vous comparerez les résultats avec ceux après l’activation de unbound.

Fichier de configuration de Unbound

Nous allons ici terminer la configuration de unbound et le démarrer.

Le fichier de configuration est /etc/unbound/unbound.conf. Une version allégée est déjà fournie par les développeurs de Mageia. Pour aller plus loin, vous pouvez aller voir la version complète /usr/share/doc/unbound/unbound.conf


Les modifications suivantes vont être faites :

  • Localisation du fichier des serveurs root.
  • Localisation du fichier des clés de signature pour DNSSEC.
  • Résolution de l’adresse de la box internet du FAI.
  • Ajout de serveur DNS tiers, dignes de confiance en termes de respect des données personnelles.
  • Préférence au protocole IPv4. Ceci parce que mon FAI ne gère pas complètement IPv6. Par contre, si vous le souhaitez, vous devriez pouvoir vous inspirer de ce wiki pour finaliser la configuration IPv6.


J’accède à ma box internet par une adresse du type mybox.myisp_domain

Le serveur DNS de mon FAI est capable de résoudre ce nom de domaine mais cela n’a été possible ni par les serveurs root et subséquents, ni par les serveurs DNS tiers. La solution est d’utiliser la section local-zone du fichier /etc/unbound/unbound.conf pour indiquer directement l’adresse IP de la box, court-circuitant ainsi le processus complet de résolution de noms de domaine.

Vous pouvez utiliser cette même section local-zone pour accéder directement à un serveur personnel local plus rapidement.

Remarque :
Si vous avez ce besoin de vous connecter à la box de votre FAI, dé-commentez et ajustez le paramétrage de local-data dans le fichier unbound.conf ci-dessous.

Par ailleurs, il s’avère que utiliser uniquement le chemin direct par les serveurs root ne suffise pas à empêcher des « fuites de trafic ». C’est-à-dire que les serveurs DNS de votre FAI peuvent quand même s’insérer (sournoisement :) ) dans le processus.

Pour empêcher cela, nous utiliserons la section forward-zone, pour indiquer les serveurs DNS tiers à utiliser pour compléter le processus de résolution. Je recommande, par exemple, les serveurs DNS de FDN ou OpenNIC project ou DNS.WATCH.

Je rappelle que chroot est actif, restreignant unbound à travailler dans le répertoire /etc/unbound

Les chemins pour accéder à root.hints et à root.key sont donc relatifs par rapport à /etc/nbound


Il est temps maintenant de modifier le fichier /etc/unbound/unbound.conf, en tant que super-utilisateur, pour qu’il devienne similaire à ci-dessous :

server: # the pid file. Can be an absolute path outside of chroot/work dir. pidfile: "/run/unbound/unbound.pid" # Prefer ipv4 upstream servers, even if ipv6 is available. prefer-ip4: yes do-tcp: yes # Detach from the terminal, run in background, "yes" or "no". # Set the value to "no" when unbound runs as systemd service. do-daemonize: no # file to read root hints from. # get one from https://www.internic.net/domain/named.cache root-hints: root.hints # Sent minimum amount of information to upstream servers to enhance # privacy. Only sent minimum required labels of the QNAME and set QTYPE # to A when possible. qname-minimisation: yes # Do not query the following addresses. No DNS queries are sent there. # List one address per entry. List classless netblocks with /size, # do-not-query-address: 127.0.0.1/8 # do-not-query-address: ::1 # if yes, the above default do-not-query-address entries are present. # if no, localhost can be queried (for testing and debugging). do-not-query-localhost: yes # If you want to perform DNSSEC validation, run unbound-anchor before # you start unbound (i.e. in the system boot scripts). And enable: # Please note usage of unbound-anchor root anchor is at your own risk # and under the terms of our LICENSE (see that file in the source). auto-trust-anchor-file: root.key ## DnsSpoof for your home server and router (exact domain name match) ## Do uncomment and set as required. Do keep . at the end of the address to indicate a strict name #local-data: "myserver.mydomain. IN A 192.168.x.y" #local-data: "mybox.myisp_domain. IN A 192.168.w.z" # Remote control config section. remote-control: # Enable remote control with unbound-control(8) here. # set up the keys and certificates with unbound-control-setup. control-enable: no # Forward zones # Create entries like below, to make all queries for 'example.com' and # 'example.org' go to the given list of servers. These servers have to handle # recursion to other nameservers. List zero or more nameservers by hostname # or by ipaddress. Use an entry with name "." to forward all queries. # If you enable forward-first, it attempts without the forward if it fails. # forward-zone: # name: "example.com" # forward-addr: 192.0.2.68 # forward-addr: 192.0.2.73@5355 # forward to port 5355. # forward-first: no # forward-zone: # name: "example.org" # forward-host: fwd.example.com ## ## dans l'exemple ci-dessous, les serveurs DNS de fdn.fr et de dns.watch sont fournis ## Vous pouvez aussi les mettre à jour avec des serveurs DNS fournis par https://www.opennic.org forward-zone: name: "." ## DNS de fdn.fr forward-addr: 80.67.169.12 forward-addr: 80.67.169.40 ## DNS de dns.watch forward-addr: 84.200.69.80 forward-addr: 84.200.70.40 forward-first: no


Pour vérifier qu'il n'y a pas d'erreur dans le fichier de configuration, vous pouvez exécuter la commande suivante en tant que super-utilisateur :

# unbound-checkconf /etc/unbound/unbound.conf

Nous terminons en démarrant le service dès la connexion. Exécutez la commande suivante en tant que super-utilisateur :

# systemctl enable --now unbound

Changement de DNS dans Drakconnect

Il faut maintenant indiquer au système d’utiliser unbound comme serveur DNS.


Pour cela, ouvrir l’applet net_applet de la barre d’outil ou ouvrir Mageia Control Center et son menu Network & Internet.

Cliquez sur l’interface (Filaire or Wifi) que vous utilisez puis sur Configure

Désélectionnez Get DNS servers from DHCP et saisir 127.0.0.1 dans le champ DNS server 1.

Ok pour fermer la fenêtre Network settings et Quit pour fermer celle de Network Center.

Set your machine as DNS

De façon optionnelle, pour plus de sécurité, vous pouvez désactiver IPv6 si vous n’avez pas configuré de serveur DNS IPv6.

Ouvrir à nouveau net_applet sur la barre d’outils ou ouvrir Mageia Control Center et son menu Network&Internet.

Cliquez sur Advanced settings et cochez la case Disable IPv6

Ok pour fermer la fenêtre Advanced network settings et Quit pour fermer celle de Network Center.

Disable IPv6 for your machine

Redémarrez l’interface réseau en exécutant en tant que super-utilisateur :

# systemctl restart network

Tests

Voici quelques tests pour s’assurer que la configuration fonctionne.


Déjà, regardons que unbound soit bien utilisé pour les requêtes DNS. Executez pour cela la commande :

$ dig mageia.org

qui doit retourner :

; <<>> DiG 9.11.31Mageia-1.1.mga8 <<>> mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36716 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mageia.org. IN A ;; ANSWER SECTION: mageia.org. 1800 IN A 163.172.148.228 ;; Query time: 37 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: mar. juil. 13 09:17:58 CEST 2021 ;; MSG SIZE rcvd: 55

Vous pouvez noter ici 2 choses :

  • SERVER: 127.0.0.1#53(127.0.0.1) indique que c'est bien unbound qui est utilisé pour la requête DNS.
  • Query time: 37 msec indique qu'il a fallu 37msec pour trouver l'adresse de mageia.org

Si vous exécutez une deuxième fois la commande

$ dig mageia.org

vous obtiendrez Query time: 0 msec qui indique que l'adresse a été trouvée directement dans le cache de unbound. Cela illustre le gain en performance quand vous naviguez souvent vers le même site.


Vous pouvez à nouveau exécuter le test standard de dnsleaktest.com

Vous devez obtenir la liste des DNS tiers que vous avez configurés (ici, ce sont ceux de www.fdn.fr).

DNS leak test results with www.fdn.fr DNS



Pour tester DNSSEC, allez à en.internet.nl et cliquer sur Start test dans la zone Test your connection.

Welcome page to start DNSSEC test

Vous obtiendrez des symboles verts dans la zone de validation de DNSSEC, en bas de la page. DNSSEC test passed


Spécialement si les tests ci-dessus ne sont pas satisfaisants, vous pouvez vérifier que le fichier /etc/resolv.conf soit bien conforme. Exécuter la commande suivante :

$ cat /etc/resolv.conf

qui doit retourner 127.0.0.1 comme DNS utilisé :

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search home


Vous pouvez aussi vérifier que unbound écoute bien le port 53 pour agir en tant que DNS. Exécutez en tant que super-utilisateur la commande suivante :

# lsof -i :53

Vous devez obtenir :

# lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME unbound 111747 unbound 3u IPv4 888557 0t0 UDP localhost:domain unbound 111747 unbound 4u IPv4 888558 0t0 TCP localhost:domain (LISTEN)

Vérification aussi de base est que le service unbound soit bien toujours actif. Vous pouvez le vérifier avec la commande

$ systemctl status unbound

Liens utiles