Je viens de faire la manip… donc voici un petit résumé.
- Introduction
Disons qu’on nous a alloué lé réseau 1.2.3.192/27.
Ceci nous donne la plage utilisable de 1.2.3.193 à 1.2.3.222.
Vérifions quels sont les PTR actuels pour ce range:
$ for i in seq 193 222; do echo $i && dig -x 1.2.3.$i +short && echo "---"; done
Vérifions les serveurs DNS en charge d’une IP du range (prenons la .202):
$ dig ptr 202.3.2.1.in-addr.arpa
[...]
;; AUTHORITY SECTION:
3.2.1.in-addr.arpa. 170940 IN NS ns1.provider.test.
3.2.1.in-addr.arpa. 170940 IN NS ns0.provider.test.
Vérifions les serveurs DNS en charge de la zone (le /24):
$ dig ns 3.2.1.in-addr.arpa. +short
ns1.provider.test.
ns0.provider.test.
$
Donc les noms associés à nos IPs sont gérés dans les DNS de notre provider.
- La problèmatique
Nous souhaitons avoir nous même authorité sur les reverse d’IPs de notre /27.
C’est à dire gérer nous-même les PTR sans avoir à demander à provider.test.
Comme nous avons le /27 et non pas le /24, on est obligé de ruser un peu pour ne pouvoir donner délégation que sur une partie de la zone 3.2.1.in-addr.arpa.
La “technique” consiste à passer par des CNAME et une nouvelle zone…
Voici les manipulations à réaliser:
Sur les serveurs DNS nsX.provider.test. il faut
- Supprimer les
PTRexistants - Créer les
CNAMEsuivants
[...]
202.3.2.1.in-addr.arpa. IN CNAME 202.192-223.3.2.1.in-addr.arpa.
203.3.2.1.in-addr.arpa. IN CNAME 203.192-223.3.2.1.in-addr.arpa.
etc...
- Créer les NS suivants
192-223.3.2.1.in-addr.arpa. IN NS dns1.monDomaine.test.
192-223.3.2.1.in-addr.arpa. IN NS dns2.monDomaine.test.
Le nom de la zone 192-223.3.2.1.in-addr.arpa. est plus ou moins au libre choix de l’administrateur.
Sur nos serveurs DNS dnsX.monDomaine.test.
- Créer la zone
192-223.3.2.1.in-addr.arpa. - Créer les
PTRdans cette zone
[...]
202.192-223.3.2.1.in-addr.arpa. IN PTR cequejeveux.monDomaine.test.
203.192-223.3.2.1.in-addr.arpa. IN PTR autretrucquejeveux.monDomaine.test.
etc...