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 :

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 😁.