Configuration des reverses

Attention:

Pour le reste de la page, on suppose que le dépôt dédié au DNS est cloné dans /etc/bind/picasoft.net.

Une résolution DNS inverse (ou reverse DNS lookup) est une technique visant à récupérer un nom de domaine à partir d’une adresse IP, grâce à des enregistrements PTR. Son utilisation est entièrement optionnelle et doit faire l’objet d’une configuration spécifique..

Question:

Pourquoi une recherche inverse ?

Dans certains cas, cela peut augmenter la sécurité. Par exemple, les serveurs mail vérifient souvent le reverse : s’ils ont reçus un email d’une IP qui prétend émettre de mail.picasoft.net, ils vont vérifier que le reverse de l’IP est bien mail.picasoft.net au niveau des serveurs DNS ayant autorité sur la zone.

Dans le fichier named.conf.local, on peut ajouter autant de zone que d’IP dont on veut qu’elles aient un reverse (voir l'ajout d'une zone).

// Reverse 91.224.148.84 (alice)
zone "84/32.148.224.91.in-addr.arpa" IN {
        type  master;
        file  "/etc/bind/picasoft.net/reverse/alice.v4";
        allow-transfer{91.224.148.85; 51.158.76.113;};
};

La syntaxe est un peu spéciale. Tous les reverses V4 ont le suffixe spécial .in-addr.arpa, et on construit ensuite le nom de domaine en inversant les nombres décimaux composant l’IP concernée.

Question:

Alors pourquoi on a une syntaxe bizarre avec un 84/32 ?

Bonne question!

A Savoir:

Historiquement, les adresses IP étaient divisées en classes. Pour faire simple, les fournisseurs d’accès à Internet allouaient aux clients des blocs d’IP (par exemple, des blocs de 256 IP pour une classe C). Une IP de classe C s’écrivait en deux parties : une partie qui désignait le bloc entier (les trois premiers octets) et une partie qui désignait une machine de ce bloc (le dernier octet).

Ainsi, supposons que Tetaneutral nous allouait le bloc 91.224.148.0. Nous aurions pu alors créer la zone 148.224.91.in-addr.arpa, et ajouter des enregistrements PTR pour chacune des IP de la zone : 1 pour 91.224.148.1, 2 pour 91.224.148.2… On voit ainsi l’astuce d’inverser l’IP : le “numéro de machine” devient un peu comme un sous-domaine.

Mais ces notions de classes sont obsolètes. Tetaneutral nous alloue les IP une par une, alors comment faire pour nous déléguer le reverse pour une unique IP ?

Lien:

La réponse se trouve dans la documentation de Tetaneutral.

Question:

Mais qu’est-ce-que Tetaneutral vient faire là-dedans ? Pour les serveurs DNS, on configure pas dans le registar ?

Le registrar nous fournit notre nom de domaine, c’est donc lui qui va pouvoir dire où aller chercher la correspondance avec les IP.

Mais ici, c’est Tetaneutral qui nous fournit les IP, c’est donc vers lui qu’on va se tourner pour les reverses ! Par exemple, la base de donnée RIPE nous apprend que l’IP d’Alice (91.224.148.84) fait partie du bloc 91.224.148.0 - 91.224.149.255, alloué à Tetaneutral.

Pour tout ce qui est dans le bloc 91.224.148.0/24, les clients DNS demanderont donc à Tetaneutral, qui finit par déléguer à notre serveur DNS les requêtes pour les IP nous concernant, avec l’astuce vue plus haut.

Pour IPv6, c’est le même principe :

// Reverse 2a03:7220:8080:5400::/56 (alice)
zone "4.5.0.8.0.8.0.2.2.7.3.0.a.2.ip6.arpa" IN {
        type  master;
        file  "/etc/bind/picasoft.net/reverse/alice.v6";
        allow-transfer{91.224.148.85; 51.158.76.113;};
};

On inverse symbole par symbole l’adresse hexadécimale, on sépare par des points, on omet les zéros finaux, on complète par le suffixe spécial ip6.arpa.

On n’a pas ici l’histoire de classes, et Tetaneutral délivre un bloc de 256 IPv6 pour chaque IPv4. Ils délèguent simplement la gestion de la zone concernant ce bloc à un de nos serveur DNS.

Une fois notre serveur configuré pour le reverse de chaque IP, il ne reste plus que à créer un fichier de zone pour chaque délégation reverse que nous fait Tetaneutral. Comme il y en a un certain nombre, ils sont tous versionnés dans le dossier reverse du dépôt Git.

Par exemple le fichier alice.v4 contient la configuration suivante :

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;; SOA record ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
$ORIGIN .
$TTL    7200                            ; TTL - 2H - Durée expiration cache DNS client
84/32.148.224.91.in-addr.arpa IN SOA ns01.picasoft.net. contact.picasoft.net. (
                        2018012801      ; Serial - Format AAAAMMJJXX où XX est incrémenté de 01 à 99
                        300             ; Refresh - 5 minutes - Fréquence d'actualisation des DNS secondaires
                        3600            ; Retry - 1 heure - Fréquence de nouvel essai quand actualisation DNS échoue
                        2419200         ; Expire - 28 Jours - Durée après laquelle les DNS secondaire non actualisés expirent
                        10800           ; Negative Cache TTL - 3 heures - TTL de l'information de non présence d'un enregistrement dans le domaine
)

; Set origin
$ORIGIN 84/32.148.224.91.in-addr.arpa.

; NS records
     IN NS   ns01.picasoft.net.
     IN NS   ns02.picasoft.net.
     IN NS   ns03.picasoft.net.

; PTR record
84   IN PTR  alice.picasoft.net.

La ligne la plus importante est la dernière. C’est elle qui enregistre l’IP 91.224.148.84 comme ayant le nom de alice.picasoft.net. (le dernier point est très important). Le reste du fichier est très similaire à celui d’un fichier de zone DNS “classique”.

  • technique/adminsys/dns/reverse.txt
  • de qduchemi