{{indexmenu_n>40}}
# Configuration des reverses
Pour le reste de la page, on suppose que le [dépôt dédié au DNS](https://gitlab.utc.fr/picasoft/projets/zonefile-picasoft) est cloné dans `/etc/bind/picasoft.net`.
Une **[résolution DNS inverse](https://en.wikipedia.org/wiki/Reverse_DNS_lookup)** (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..
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 [[technique:adminsys:dns:principal|l'ajout d'une zone]]).
## Zone pour IPv4
```
// 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.
Alors pourquoi on a une syntaxe bizarre avec un `84/32` ?
Bonne question!
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 ?
La réponse se trouve dans la [documentation de Tetaneutral](https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Bind#D%C3%A9l%C3%A9gation-dun-reverse-classless-).
Mais qu'est-ce-que Tetaneutral vient faire là-dedans ? Pour les serveurs DNS, on configure pas dans le [[technique:adminsys:dns:delegation|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](https://apps.db.ripe.net/db-web-ui/query?searchtext=91.224.148.84) 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.
## Zone pour IPv6
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.
## Exemple de fichier de zone IPv4
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](https://gitlab.utc.fr/picasoft/projets/zonefile-picasoft/-/tree/master/reverse).
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".