Gérer un domaine local avec Unbound
home.arpa sweet home.arpa
Rapide billet pour documenter une technique prolongeant le principe déjà étudié pour donner dans le blocage de parasites. Il va s'agir ici de se créer un domaine local, pour le réseau privé, ce qui est bien plus pratique que de retenir des IPs ou maintenir un fichier hosts
sur les machines où l'on y a accès.
Le principe est de profiter du RFC 8375, qui réserve le domaine home.arpa.
pour les protocoles de la famille Homenet (une série de protocoles pour les bidules connectés dont je n'avais pas entendu parlé avant) et donc d'attribuer un domaine à chaque machine du réseau local. On pourrait a priori également utiliser le domaine local.
, réservé pour le DNS multicast (mDNS) (qui est assez répandu et dont les implémentations les plus connues sont sans doutes Bonjour d'Apple et Avahi sous Linux — vous savez le truc bien souvent installé par défaut et qui hurle des insanités sur le port 5353 🙂), mais comme pour le coup il a un vrai usage, laissons le tranquille.
Le programme est assez simple : on liste les appareils du réseau, on note leurs adresses IPv4 et IPv6 (si cette dernière est fixe) et on passe le tout à Unbound.
On crée donc un fichier de configuration dans /etc/unbound/unbound.conf.d/
(sous Debian & dérivés. Pour les systèmes type Arch, on peut mettre cela dans le fichier de configuration principal ou bien dans un fichier à part que l'on inclut dans la conf principale via include
) et on y ajoute :
server:
local-zone: "home.arpa." transparent
# IPv4
local-data: "router.home.arpa. 86400 IN A 192.168.0.1"
local-data: "cthulhu.home.arpa. 86400 IN A 192.168.0.2"
local-data: "eth.azathoth.home.arpa. 86400 IN A 192.168.0.3"
local-data: "wifi.azathoth.home.arpa. 86400 IN A 192.168.0.4"
...
# IPv6
local-data: "router.home.arpa. 86400 IN AAAA 2001:db8:1a1a:ca11::1"
local-data: "cthulhu.home.arpa. 86400 IN AAAA 2001:db8:1a1a:ca11:0f:c700:100:1926"
...
# On ajoute les enregistrements PTR
# PTR IPv4
local-data-ptr: "192.168.0.1 86400 router.home.arpa."
...
# PTR IPv6
local-data-ptr: "2001:db8:1a1a:ca11::1 86400 router.home.arpa."
...
# Divers
local-data: 'azathoth.home.arpa. 86400 IN TXT "Une adresse par interface"'
Quelques commentaires :
- Le type
transparent
delocal-zone
a le fonctionnement suivant : si le domaine est listé dans leslocal-data
, Unbound répond avec ces données ouNODATA
si l'enregistrement demandé ne s'y trouve pas. Le mécanisme de résolution normal est utilisé si le domaine ne possède aucune donnée locale. Je l'utilise car, hébergeant une sonde RIPE Atlas, mon résolveur peut-être utilisé pour des tests et notamment des requêtes demanant leSOA
dehome.arpa.
(qui est un enregisrement qui existe dans les véritables NS du domaine). Donc, pour essayer d'éviter de révéler que ce domaine est utilisé localement,transparent
me semble une bonne solution. - Sans cette contrainte, le type
static
(le résolveur intercepte toutes requêtes pour tout l'arbrehome.arpa.
, sert les données qu'il possède, répondsNODATA
ouNXDOMAIN
sinon) est parfaitement adapté. - On peut ajouter tout type d'enregistrements — non liés à DNSSEC évidemment. On peut donc mettre un enregistrement
TXT
pour chaque machine qui fournirait une petite description de celle-ci. Dans l'exemple ci-dessus, j'ajoute un enregistrement pourazathoth.home.arpa.
principalement car sinon, le domaine étant vide, seuls les 2 sous-domaines existent et les requêtes pour ce parent suivraient le mécanisme de résolution récursif. - Attention par ailleurs à la syntaxe pour ajouter un enregistrement
TXT
: utilisation de guillemets simples pour l'enregisrement complet et double pour le texte à passer.
Une fois tout configuré et Unbound relancé, on peut faire quelques tests :
$ dig cthulhu.home.arpa ; <<>> DiG 9.11.14-3-Raspbian <<>> cthulhu.home.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59243 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cthulhu.home.arpa. IN A ;; ANSWER SECTION: cthulhu.home.arpa. 86400 IN A 192.168.0.2 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: sam. févr. 29 02:42:28 CET 2020 ;; MSG SIZE rcvd: 57
Et le PTR
:
$ dig -x 192.168.0.2 ; <<>> DiG 9.11.14-3-Raspbian <<>> -x 192.168.0.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16057 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;2.0.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 2.0.168.192.in-addr.arpa. 86400 IN PTR cthulhu.home.arpa. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
On a bien, dans les 2 cas, l'indication AA (Authoritative Answer) dans les réponses. Le résolveur fait donc autorité et nous a bien servi les enregistrements configurés. Continuons :
$ dig AAAA azathoth.home.arpa ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33254 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;azathoth.home.arpa. IN AAAA ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
Le bit AA et une réponse vide (statut NOERROR
et ANSWER
de 0), ce qui est bien ce qui est attendu. Dernier test :
$ dig SOA home.arpa ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15498 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,ADDITIONAL: 1 ... ;; ANSWER SECTION: home.arpa. 300 IN SOA prisoneriana.org. hostmaster.root-servers.org. 2002040800 1800 900604800 604800 ;; Query time: 32 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
Cette fois-ci, pas de bit AA dans la réponse, Unbound est donc allé chercher la réponse via le mécanisme récursif habituel.
On peut enfin configurer son routeur, si ce dernier le permet, pour utiliser ce domaine (notamment pour la recherche) et dire aux appareils du réseau de l'utiliser. De quoi avoir cette entrée dans /etc/resolv.conf
:
domain home.arpa
search home.arpa
Si votre routeur ne le permet pas ou est incomplet (comme le mien qui ne permet pas de dire sur quel domaine faire la recherche), il est possible de forcer ces paramètres via le client DHCP de chaque machine.
Et voilà, on peut faire ping
et traceroute
sur le réseau local en s'aidant du DNS 😁.