Résolveur DNS Unbound
Les serveurs DNS sont des machines discutant entre elles afin de se communiquer les correspondances entre nom de domaine et adresses IP.
Prérequis
À partir de la version 209, systemd contient un démon de configuration réseau nommé systemd-networkd qui peut être utilisé pour la configuration basique du réseau. De plus, depuis la version 213, la résolution de nom DNS peut être prise en charge par systemd-resolved au lieu d’un fichier /etc/resolv.conf statique. Ces deux services sont activés par défaut
Si vous utilisez un résolveur local (par exemple bind, dnsmasq, unbound, etc), ou tout autre logiciel générant un fichier /etc/resolv.conf (par exemple resolvconf), le service systemd-resolved ne doit pas être utilisé.
Pour désactiver systemd-resolved, exécutez la commande suivante :
sudo systemctl disable systemd-resolved
Effacer puis recréer un fichier /etc/resolv.conf
avec une directive dns, par exemple
nameserver 1.1.1.1
Installer unbound
Passage en mode super utilisateur
sudo -s # ou su
Désinstaller bind
apt remove --purge bind* -y
rm -r /var/cache/bind/
Installation des outils dns et du paquet Unbound :
apt install dnsutils unbound -y
Serveurs de nom racine
unbound possède une liste de serveurs racine pour la résolution des adresses. Cette liste pouvant évoluer dans le temps, il est préférable d’installer la dernière version lors de l'installation
Télécharger le fichier named.cache sur le site internic.net et le placer dans le répertoire /var/lib/unbound/ sous le nom root.hints
curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
chown unbound:unbound /var/lib/unbound/root.hints
Indiquer l’adresse du fichier dans la configuration de unbound
créer le fichier root-hints.conf :
nano /etc/unbound/unbound.conf.d/root-hints.conf
# Fichier des serveurs root à télécharger env tous les 6 mois :
# curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
#
server:
root-hints: "/var/lib/unbound/root.hints"
Vérifier le fichier
unbound-checkconf /etc/unbound/unbound.conf.d/root-hints.conf
unbound-checkconf: no errors in /etc/unbound/unbound.conf.d/root-hints.conf
Redémarrer unbound
systemctl restart unbound.service
La mise à jour peut-être effectuée automatiquement en utilisant systemd, selon la méthode décrite ci-dessous et reprise du wiki ArchLinux unboud : Roothints systemd timer, la mise à jour s’effectuera tous les 6 mois
Créer un fichier service
nano /etc/systemd/system/roothints.service
[Unit]
Description=Update root hints for unbound
After=network.target
[Service]
ExecStart=/usr/bin/curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
Créer un fichier timer
nano /etc/systemd/system/roothints.timer
[Unit]
Description=Run root.hints semiannually
[Timer]
OnCalendar=semiannually
Persistent=true
[Install]
WantedBy=timers.target
Tester le chargement du fichier
mv /var/lib/unbound/root.hints /var/lib/unbound/root.hints.BU
systemctl start roothints.service
ls -ls /var/lib/unbound/root.hints*
4 -rw-r--r-- 1 root root 3314 août 25 18:38 /var/lib/unbound/root.hints
4 -rw-r--r-- 1 unbound unbound 3314 août 25 18:31 /var/lib/unbound/root.hints.BU
Démarrer le timer roothints.timer
systemctl enable roothints.timer
systemctl start roothints.timer
Configurer unbound
Les fichiers de configuration sont situés sous /etc/unbound/unbound.conf.d/
root-auto-trust-anchor-file.conf est créé par défaut à l’installation
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: "/var/lib/unbound/root.key"
qname-minimisation.conf est créé par défaut à l’installation
server:
# Send minimum amount of information to upstream servers to enhance
# privacy. Only sends minimum required labels of the QNAME and sets
# QTYPE to NS when possible.
# See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
# details.
qname-minimisation: yes
NOTE: La configuration par défaut est suffisante lors de la mise en place sur un serveur
Ajout d’un fichier de configuration dns-yan.conf (si nécessaire)
nano /etc/unbound/unbound.conf.d/dns-yan.conf
server:
interface: 0.0.0.0 # 0.0.0.0 unbound sur plusieurs interfaces
interface: ::0
access-control: 0.0.0.0/0 allow
access-control: ::/0 allow
verbosity: 0 # 0 messages (erreurs uniquement)
#qname-minimisation: yes
num-threads: 2
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
rrset-cache-size: 100m
msg-cache-size: 50m
outgoing-range: 465
so-rcvbuf: 4m
so-sndbuf: 4m
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
harden-referral-path: yes
use-caps-for-id: yes
prefetch: yes
Pour vérifier si le fichier de configuration est valide
unbound-checkconf /etc/unbound/unbound.conf.d/dns-yan.conf
Démarrer et vérifier unbound
Si vous n’utilisez pas l’application resolvconf pour la résolution des noms, il faut modifier le fichier /etc/resolv.conf
nameserver 127.0.0.1
Redémarrer le service dnsunbound
systemctl restart unbound
Les commandes suivantes ne fonctionneront que si le paquet “dnsutils” est installé sur votre système Debian!
dig @127.0.0.1 afnic.fr +short +dnssec
192.134.5.25
A 8 2 600 20180406223409 20180307194345 64860 afnic.fr. lhw7AmNSkeZOtNN/9rJuGYxTdUcXSR3xlbsKz2xjNbFxQT5FwKILTW+E WWawrrbjo79uaG7kAvfMWrah4ijWtz9qGyd76qTr3XVdXB3+pbIsRr6X /I/ryQAy9w8tP3FvXHHU7IxihP+Ei2M5licCYitt1YZUyXuNFdNpdhq7 FRT+tq78yn1PEm121f32IRQ2Fjy9qZz9O0LU7roYZ6XFoPU9x3PU590J mpkywT9t6LpyeW5GK5zSL+Zb5eiFhfp33abkMf7b6Pc7xixcGN8h8SDQ Ry98Ne0EIqHKnyh/zzRszc1kBfP5kJXmcY/X3+4xLvKmvKNnBLT0dsn1 q1Hl1A==
Si la commande dig-command a fonctionné, vous pouvez maintenant définir Unbound comme premier résolveur DNS pour votre système de messagerie , paragraphe suivant
Résolution des noms avec resolvconf sous Linux Debian
- Article original Résolution des noms avec resolvconf sous Linux Debian du 27/08/2106
En fonction du type de connexion utilisé, il est parfois nécessaire de faire appel à différents serveurs de noms (DNS). Par exemple, lors d’une connexion à son lieu de travail, il faut utiliser le serveur DNS de son réseau, mais lors d’une connexion à internet, il faut utiliser les serveurs DNS de son fournisseur d’accès. Dans ce cas, le paquet “resolvconf” sous Debian permet de résoudre ces problèmes.
Rappel sur l’utilité du fichier « /etc/resolv.conf »
Ce fichier permet d’indiquer le ou les domaines de recherche et les différents serveurs DNS à utiliser.
Par exemple, dans un réseau local, nous pourrions avoir un serveur DNS à l’adresse 192.168.0.1 chargé de gérer le domaine « mon-domaine.local ». En cas de défaillance du DNS local, nous pourrions faire appel aux serveurs DNS de notre fournisseur d’accès. Dans ce cas, le contenu du fichier « /etc/resolv.conf », pourrait ressembler à cela :
nameserver 192.168.0.1
nameserver 212.27.53.252
nameserver 212.27.52.252
search mon-domaine.local
La première ligne indique l’adresse du serveur DNS du réseau local. En cas de défaillance de ce serveur, les serveurs suivants seront utilisés (Serveurs du fournisseur d’accès à Internet).
La dernière ligne permet d’indiquer le nom du domaine géré par le serveur DNS local. Par exemple, si nous cherchons à contacter le serveur « MonServeur », le système cherchera en fait à contacter l’adresse complète « MonServeur.mon-domaine.local », car le nom du serveur indiqué ne comportait pas le domaine de recherche.
Présentation et installation de resolvconf
Le programme resolvconf garde la trace des informations du système sur les serveurs de noms de domaine actuellement disponibles. Il ne faut pas le confondre avec le fichier de configuration resolv.conf qui porte malencontreusement presque le même nom. Le programme resolvconf est optionnel sur les systèmes Debian.
Le fichier de configuration resolv.conf contient des informations sur les serveurs de noms de domaine que le système doit utiliser. Néanmoins, quand plusieurs programmes doivent modifer dynamiquement le fichier de configuration resolv.conf, ils peuvent se chevaucher et le fichier peut ne plus être synchronisé. Le programme resolvconf s’occupe de ce problème. Il agit comme un intermédiaire entre les programmes qui fournissent des informations sur les serveurs de noms de domaine (par exemple les clients dhcp) et les programmes qui les utilisent (par exemple resolver).
Quand resolvconf est correctement installé, le fichier de configuration resolv.conf du répertoire /etc/resolv.conf est remplacé par un lien symbolique pointant vers le fichier /etc/resolvconf/run/resolv.conf et le résolveur utilise plutôt le fichier de configuration qui est généré dynamiquement par resolvconf à cet emplacement /etc/resolvconf/run/resolv.conf.
Le programme resolvconf est en général seulement nécessaire quand un système a plusieurs programmes qui ont besoin de modifier de façon dynamique les informations sur les serveurs de noms de domaine. Sur un système simple où les serveurs de noms de domaine ne changent pas souvent ou bien ne sont modifiés que par un programme, le fichier de configuration resolv.conf est suffisant.
Si le programme resolvconf est installé, vous n’aurez pas à modifier à la main le fichier de configuration resolv.conf car il sera changé de façon dynamique par les programmes. Si vous avez besoin de définir vous-même les serveurs de noms de domaine (comme avec une interface statique), ajoutez au fichier de configuration interfaces du répertoire /etc/network/interfaces une ligne comme celle-ci :
dns-nameservers 127.0.0.1 80.67.169.12 80.67.169.40
Mettez la ligne indéntée dans un paragraphe iface, par exemple juste après la ligne gateway. Entrez les adresses IP des serveurs de noms de domaine dont vous avez besoin après dns-nameservers, toutes sur la même ligne, séparées par des espaces. N’oubliez pas le “s” à la fin de dns-nameservers.
Le programme resolvconf est un ajout plutôt récent à Debian et plusieurs anciens programmes ont besoin d’être mis à jour ou reconfigurés pour fonctionner correctement avec lui . Si vous rencontrez des problèmes, regardez /usr/share/doc/resolvconf/README qui contient beaucoup d’informations sur la manière de faire fonctionner resolvconf avec d’autres programmes.
apt install resolvconf -y
echo "nameserver 127.0.0.1" >> /etc/resolvconf/resolv.conf.d/head
Une fois le paquet « resolvconf » installé, il ne faut plus modifier le fichier « /etc/resolv.conf », car le contenu de celui-ci sera automatiquement géré et remplacé par « resolvconf ».
Structure réseau debian
tree /etc/network/
/etc/network/
├── if-down.d
│ ├── resolvconf
│ └── upstart
├── if-post-down.d
├── if-pre-up.d
├── if-up.d
│ ├── 000resolvconf
│ ├── openssh-server
│ └── upstart
├── interfaces
├── interfaces.d
│ └── 50-cloud-init.cfg
└── interfaces.save
Le résultat de la commande
nslookup afnic.fr | grep Server
devrait ressembler à ceci:
Server: 127.0.0.1
Vérifier la résolution de nom à partir du serveur :
dig @127.0.0.1 afnic.fr
; <<>> DiG 9.10.3-P4-Debian <<>> @127.0.0.1 afnic.fr
; (1 server found)
...
;; SERVER: 127.0.0.1#53(127.0.0.1)
...
La résolution fonctionne
Maintenant, vous disposez de votre propre résolveur DNS.
Mise à jour serveurs de nom racine
Mise à jour automatique des serveurs DNS de la racine ,créer un bash
nano /etc/unbound/dnsunbound-update-root-dns.sh
#!/bin/sh
TmpName=$(mktemp)
TmpDiff=$(mktemp)
TmpErr=$(mktemp)
REPORT_EMAIL="admin"
URL="https://www.internic.net/domain/named.cache"
wget -nv $URL -O $TmpName 2> $TmpErr
# On intercepte toute erreur
# et on stoppe le script dans ce cas
# On continue sinon
if [ "$?" -ne 0 ];then
printf "\nScript was stopped at this point. A manual action may be required.\n" >> $TmpErr
mail -s "[DNS - $(uname -n)] Root hints file download failed" $REPORT_EMAIL < $TmpErr
rm $TmpErr
rm $TmpDiff
rm $TmpName
exit 0
else
rm $TmpErr
shaTMP=$(sha512sum $TmpName | awk '{print $1}')
shaHINTS=$(sha512sum /var/lib/unbound/root.hints | awk '{print $1}')
if [ $shaTMP = $shaHINTS ]; then
# Si le fichier récupéré est identique à celui
# utilisé par Unbound, on fait... rien
rm $TmpName
exit 0
else
printf "A new root hints file was spotted on InterNIC server.\nFile downloaded and old root.hints file replaced.\nHere is the diff:\n\n" > $Tmp$
diff $TmpName /var/lib/unbound/root.hints >> $TmpDiff
printf "\n\n" >> $TmpDiff
mv -f $TmpName /var/lib/unbound/root.hints
chown unbound: /var/lib/unbound/root.hints
chmod 644 /var/lib/unbound/root.hints
sleep 5
service unbound restart
printf "Unbound status is $(service unbound status | grep Active | awk '{print $2 " " $3}')\n" >> $TmpDiff
mail -s "[DNS - $(uname -n)] Update in Root Hints" $REPORT_EMAIL < $TmpDiff
rm $TmpDiff
fi
fi
exit 0
Droits en exécution
chmod +x /etc/unbound/dnsunbound-update-root-dns.sh
Planification journalière
crontab -e
Ajouter en fin de fichier
# Mise à jour automatique des serveurs DNS de la racine
50 02 * * * /etc/unbound/dnsunbound-update-root-dns.sh > /dev/null
Bloquer la publicité
Générer une liste des domaines ou sites à bloquer à partir d’une liste existante (https://github.com/StevenBlack/hosts) , créer un bash /etc/unbound/unbound.conf.d/liste-domaines-bloques.sh
nano /etc/unbound/unbound.conf.d/liste-domaines-bloques.sh
#!/bin/bash
# list of ads domain names
wget --quiet https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/fakenews-gambling-porn-social/hosts -O w
grep -v " #\|<td>\|<p>\|<meta>\|<link>\|<title>\|href\|title=\|=\|<" w > adsList.txt
rm w # remove host syntax and clean file
sed -i 's/0.0.0.0//g' adsList.txt
sed -i 's/127.0.0.1//g' adsList.txt
sed -i 's/localhost//g' adsList.txt
sed -i 's/.localdomain//g' adsList.txt
# remove commentary after domain name
sed -i 's/#.*//' adsList.txt
# remove tabulation character and carriage return
sed -i "s/\t//g" adsList.txt
sed -i "s/\r//g" adsList.txt
# remove useless space
sed -i 's/ //g' adsList.txt
# remove empty lines
sed -i '/^\s*$/d' adsList.txt
# add prefix and suffix for unbound
sed -i "s/.*/local-zone: \"&\" static/" adsList.txt
cat adsList.txt >> adsListFinal.txt
# order list by name, it didn't cost a lot and could maybe increase unbound performance
sort adsListFinal.txt -o adsListFinal.txt
# remove duplicate ads domain in order to avoid warning with Unbound
uniq adsListFinal.txt > adslist.txt
# remove tempory files
rm adsListFinal.txt adsList.txt
# fichier copié puis effacé
cp adslist.txt /etc/unbound/unbound.conf.d/
rm adslist.txt
# Redémarrer unbound
systemctl restart unbound
exit 0
Droits en exécution
chmod +x /etc/unbound/unbound.conf.d/liste-domaines-bloques.sh
Planification journalière
crontab -e
Ajouter en fin de fichier
# Générer une liste des domaines à bloquer
40 02 * * * /etc/unbound/unbound.conf.d/liste-domaines-bloques.sh > /dev/null
Le paramètre local-zone accepte les types suivants :
- deny : n’envoie pas de réponse et jette la requête, sauf si un enregistrement local-data est trouvé, auquel cas ce dernier est servi.
- refuse : renvoie un code de réponse REFUSED à la requête, sauf si un enregistrement local est trouvé, auquel cas ce dernier est servi.
- static : Si une donnée local-data est trouvée, celle-ci est servie. Sinon, la requête se voit répondre NODATA ou NXDOMAIN. Dans ce cas là, si un enregistrement local SOA est défini, ce dernier est également servi.
- always_deny : comme deny mais ignore tout enregistrement local.
La liste des domaines à bloquer adslist.txt est configuré avec static
Ajouter la prise en charge en fin de fichier configuration /etc/unbound/unbound.conf.d/dns-yan.conf
include: /etc/unbound/unbound.conf.d/adslist.txt
Pour vérifier si le fichier de configuration est valide
unbound-checkconf /etc/unbound/unbound.conf.d/dns-yan.conf
Redémarrer le service dnsunbound
systemctl restart unbound
Test avec un site qui est dans la liste
dig ad2.adfarm1.adition.com
; <<>> DiG 9.10.3-P4-Debian <<>> ad2.adfarm1.adition.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48255
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
La requête DNS n’est pas servie et se voit répondre NXDOMAIN
Blocage des DMP (Data Management Platforms) avec Unbound
Configuration nécessaire pour Unbound afin de bloquer certaines « Data Management Platforms » (DMP) utilisées par de plus en plus de sites (liberation.fr, oui.scnf, lemonde.fr, fnac.com…) et qui échappent – pour l’instant aux bloqueurs de traqueurs traditionnels (uBlock Origin ou uMatrix par exemple)https://gitea.cinay.eu/yann/blocage-dmp-unbound
Le cœur du problème
Dernièrement, une conjoncture d’éléments est venue semer le trouble chez nos aspirateurs :
- L’entrée en vigueur du RGPD en Europe
- La part de plus en plus grande d’internautes utilisant des bloqueurs de publicités
- La volonté des éditeurs de navigateurs web (Chrome et Firefox – et donc leurs dérivés) de bloquer par défaut les traqueurs ou les cookies tiers.
Un mouchard est dit tiers – ou 3rd-party quand on est disruptif – quand il n’est pas chargé depuis le domaine (ou un de ses sous domaines) que vous visitez. Par exemple quand on visite https://liberation.fr/, le script chargé depuis www.google-analytics.com est tiers. Si le même mouchard est chargé depuis un sous-domaine de liberation.fr, il est dit 1st-party (primaire a priori en bon français). Le hic, pour nos amis start-uppers est que les mouchards/cookies tiers sont triviaux à bloquer. Ne pas charger les cookies tiers est d’ailleurs une option répandue dans les navigateurs depuis des années.
La fourberie
La technique développée par les marketeux pour ne pas voir les juteuses données personnelles leur échapper est à la fois techniquement très simple et redoutable. Il suffit de transformer les crasses 3rd-party en 1st-party afin de les cacher sous le cyber-tapis pour reprendre l’expression de Reflets. Et pour se faire passer par le DNS et ses possiblités.
Bloquer les indésirables avec Unbound
On entre dans la partie technique, pour faire court, on va décréter à Unbound que nous contrôlons les domaines indésirables (eulerian.net par exemple) afin de faire échouer la résolution DNS. La technique est développée plus en détail sur un blog.
Pour mémoire :
- On crée un fichier de zone (blocked.zone) où l’on met un enregistrement SOA.
- On l’associe à chaque domaine à bloquer dans la configuration d’Unbound (adblock-war.conf)
Cette technique sera valable, pour les versions d’Unbound supérieures à 1.7.0.
/var/lib/unbound/blocked.zone
$TTL 10800
@ IN SOA localhost. nobody.invalid. (
1
3600
1200
604800
10800
)
/etc/unbound/unbound.conf.d/adblock-war.conf
# À n'utiliser qu'avec une version d'Unbound supérieure à la 1.7.0
auth-zone:
name: "eulerian.net."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "eulerian.fr."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "eulerian.com."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "dnsdelegation.io."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "a.20mn.fr."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "at-o.net."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "keyade.com."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "storetail.io."
zonefile: "/var/lib/unbound/blocked.zone"
auth-zone:
name: "omtrdc.net."
zonefile: "/var/lib/unbound/blocked.zone"
Redémarrer unbound
systemctl restart unbound
Vérifier
dig v.oui.sncf
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> v.oui.sncf
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;v.oui.sncf. IN A
;; ANSWER SECTION:
v.oui.sncf. 2822 IN CNAME voyages-sncf.eulerian.net.
;; AUTHORITY SECTION:
eulerian.net. 10021 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ven. nov. 15 16:07:19 CET 2019
;; MSG SIZE rcvd: 137
La requête n’est pas servie (NXDOMAIN)
Activer les logs
Modifier le fichier de configuration unbound
logfile: /var/log/unbound.log
verbosity: 1
log-queries: yes
Créer le fichier log avec les droits
touch /var/log/unbound.log
chown unbound:unbound /var/log/unbound.log
Relancer le service unbound
systemctl restart unbound
Visualiser les logs
tail -f /var/log/unbound.log
Liens
- Changer de DNS
- Qu’est-ce qu’un serveur DNS et comment en installer un ?
- Unbound : un résolveur cache DNS (DNSSEC + DNS/TLS)
- unbound sur Raspberry Pi : un serveur DNS sur votre réseau local
- Unbound DNS Tutorial A validating, recursive, and caching DNS server → Traduction FR-Lien HS
- Unbound : redirecteur, cache et blacklist DNS
- Tuto : Créer son résolveur DNS avec Unbound sur Debian
- http://www.bortzmeyer.org/search?pattern=unbound
- Résolveur de nom de domaines Unbound
unbound/wireguard
Le fichier de configuration unbound wireguard
server:
num-threads: 4
# enable logs
verbosity: 1
# liste des serveurs DNS racine
root-hints: "/var/lib/unbound/root.hints"
# Répondre aux requêtes DNS sur toutes les interfaces
interface: 0.0.0.0 # 0.0.0.0 unbound sur plusieurs interfaces
interface: ::0
max-udp-size: 3072
# IPs authorised to access the DNS Server
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.56.0.0/16 allow
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: ::ffff:127.0.0.1 allow
access-control: fe80::/10 allow
access-control: fdac:8289:4ac0:8f25::0/48 allow
local-zone: "56.10.in-addr.arpa." transparent
# not allowed to be returned for public Internet names
# private-address: 10.52.16.0/24
#hide DNS Server info
hide-identity: yes
hide-version: yes
# limit DNS fraud and use DNSSEC
harden-glue: yes
harden-dnssec-stripped: yes
harden-referral-path: yes
# add an unwanted reply threshold to clean the cache and avoid, when possible, DNS poisoning
unwanted-reply-threshold: 10000000
# have the validator print validation failures to the log
val-log-level: 1
# minimum lifetime of cache entries in seconds
cache-min-ttl: 1800
# maximum lifetime of cached entries in seconds
cache-max-ttl: 14400
prefetch: yes
prefetch-key: yes
Denis Szalkowski Formateur Consultant
Liens Pastebin
DoT DoH
- Article original DNS-over-TLS à la maison avec Unbound-Posted by Médéric Ribreux 🗓 2019-08-28 In blog/Sysadmin/
- Le DNS over TLS : le meilleur protocole de sécurité
- DoT, DoH : le chiffrement du DNS en pratique
- Documentation technique de mon résolveur DoH
Avantages et inconvénients du DNS over TLS
Puisque le DNS traditionnel ne propose aucune mesure de sécurité, on n’encourt pas davantage de risques avec le DoT. Le système de cryptage empêche désormais les cybercriminels d’utiliser ce service pour leurs attaques. De même, les gouvernements ne peuvent plus utiliser le DNS pour régulariser leurs mesures de censure, du moins en théorie. Le DNS over TLS est critiqué par de nombreux experts, car il utilise un port spécifique. Ainsi, même s’il est impossible de déterminer quel site Web il faut consulter, il est cependant évident qu’une requête DNS a été envoyée. Cela pose un problème aux responsables en charge de la protection des données. Cependant, de nombreux administrateurs réseau considèrent cette étape comme importante, afin de bénéficier d’une meilleure vue d’ensemble des activités du réseau.
Actuellement, des problèmes se posent également en raison de l’utilisation encore trop rare du DNS over TLS. Tous les systèmes d’exploitation, à l’exception d’Android 9, doivent être équipés de logiciels supplémentaires. Côté serveur, cette technologie n’est pas (encore) très répandue : certes, on trouve déjà plusieurs prestataires, mais ils ne sont pas aussi nombreux que pour le DNS traditionnel. Par conséquent, certains experts redoutent l’émergence d’un monopole. À ce jour, les fournisseurs d’accès Internet fournissent une grande partie des serveurs de noms. Cependant, d’autres sociétés, certes nettement moins à l’international, pourraient bientôt être en mesure de regrouper les requêtes DNS.
Dot vs. DoH
En marge du DoT, une autre technologie fait actuellement débat, qui pourrait améliorer la sécurité de la résolution de noms : DNS over HTTPS (DoH). Ces deux solutions ont en commun le fait de crypter les communications. La plus grande différence réside dans le port qui est utilisé. Et ce qui semblait anodin a conduit à un profond clivage entre les différents experts : alors que le DNS over TLS utilise son propre port, le DoH utilise le port 443, utilisé également pour toutes les autres connexions HTTPS, par exemple pour de simples visites de sites Internet. Ce qui veut dire qu’une requête DNS ne peut pas se différencier du reste du trafic lors de la navigation sur le Web.
C’est un avantage du point de vue de la protection des données : si aucune requête DNS n’est détectée, aucune tentative ne peut être faite pour la bloquer. Certains administrateurs réseaux redoutent néanmoins de perdre le contrôle sur le trafic du réseau et de ne plus pouvoir gérer correctement la communication.
Deux camps se sont ainsi formés, chacun souhaitant promouvoir sa propre solution. Derrière le DoT on trouve en première ligne l’IETF, une organisation en charge du développement d’Internet. L’IETF élabore des normes qui, dans de nombreux cas, sont reprises par les autres acteurs du World Wide Web. Le DNS over HTTPS bénéficie du soutien d’autres sociétés et organisations. Citons à ce titre, la Mozilla Foundation et Google qui sont partisans de cette solution.