Délégation de la zone inverse d'un sous-réseau de moins de /24 dans BIND. Comment cela fonctionne

Un jour, j'ai été confronté à la tâche de donner à un de mes clients le droit d'éditer les enregistrements PTR de son sous-réseau /28. Je n'ai pas d'automatisation pour modifier les paramètres de BIND de l'extérieur. J'ai donc décidé d'aborder le problème d'une autre manière — déléguer un morceau de la zone PTR du sous-réseau /24 au client.

À première vue — rien de plus simple ? Il suffit de spécifier le sous-réseau et de le diriger vers le bon NS comme on le fait avec un sous-domaine. Mais non. Ce n'est pas si simple (bien que cela soit en réalité assez primaire, mais l'intuition ne sera pas d'une grande aide), c'est pourquoi j'écris cet article.

Pour ceux qui souhaitent approfondir, vous pouvez lire. RFC
Pour ceux qui veulent une solution toute prête, bienvenue sous le cat.

Pour ne pas faire attendre ceux qui aiment la méthode du copier-coller, je vais d'abord publier la partie pratique, suivi de la théorique.

1. Pratique. Délégation de la zone /28

Supposons que nous avons un sous-réseau 7.8.9.0/24. Nous devons déléguer le sous-réseau 7.8.9.240/28 au client DNS 7.8.7.8 (ns1.client.domain).

Sur le DNS du fournisseur, il faut trouver le fichier décrivant la zone inverse de ce sous-réseau. Appelons-le 9.8.7.in-addr.arpa.
Nous commentons les enregistrements de 240 à 255, si présents. Et à la fin du fichier, nous écrivons ce qui suit :

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

n'oublions pas d'augmenter le numéro de série de la zone et faisons

rndc reload

C'est là que la partie fournisseur se termine. Passons au DNS client.

Tout d'abord, créons le fichier /etc/bind/master/255-240.9.8.7.in-addr.arpa avec le contenu suivant :

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; numéro de série
                        3H              ; rafraîchissement
                        15M             ; essai
                        1W              ; expiration
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

Et dans named.conf nous ajoutons la description de notre nouveau fichier :

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9-8.7.in-addr.arpa";
};

Nous redémarrons le processus bind.

/etc/init.d/named restart

Voilà. Maintenant, nous pouvons vérifier.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Notez que non seulement l'enregistrement PTR est retourné mais aussi le CNAME. C'est normal. Si vous êtes curieux de savoir pourquoi, bienvenue dans le prochain chapitre.

2. Théorie. Comment cela fonctionne.

Il est difficile de configurer et de déboguer une boîte noire. C'est beaucoup plus simple quand on comprend ce qui se passe à l'intérieur.

Lorsque nous déléguons un sous-domaine dans le domaine domain, nous écrivons quelque chose comme cela :

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

Nous informons tous ceux qui demandent que nous ne sommes pas responsables de cette zone et disons qui est responsable. Et toutes les demandes pour client.domain sont redirigées vers 7.8.7.8. En vérifiant, nous voyons la situation suivante (omettons ce que le client a, ce n'est pas important) :

# host test.client.domain
test.client.domain has address 7.8.9.241

C'est-à-dire que l'on nous a informés qu'il y a un enregistrement A et que son IP est 7.8.9.241. Pas d'informations superflues.

Et comment faire la même chose avec une sous-réseau ?

Étant donné que notre serveur DNS est inscrit dans RIPE, la première requête PTR de l'adresse IP de notre réseau sera toujours adressée à nous. La logique est la même que pour les domaines. Mais comment inscrire un sous-réseau dans le fichier de zone ?

Nous essayons de l'inscrire ainsi :

255-240  IN  NS      7.8.7.8

Et… le miracle ne s'est pas produit. Nous ne recevons aucune redirection de la requête. Le problème est que bind n'est pas du tout au courant que ces enregistrements dans le fichier de zone inverse sont des adresses IP et ne comprend pas non plus l'enregistrement de plage. Pour lui, c'est simplement un sous-domaine symbolique. C'est-à-dire qu'il n'y aura pas de différence pour bind entre «255-240» et «oursuperclient« . Et pour que la requête soit envoyée où il faut, l'adresse dans la requête doit apparaître comme suit : 241.255-240.9.8.7.in-addr.arpa. Ou ainsi, si nous utilisons un sous-domaine symbolique : 241.oursuperclient.9.8.7.in-addr.arpa. Cela se distingue de l'ordinaire : 241.9.8.7.in-addr.arpa.

Il sera problématique d'exécuter une telle requête manuellement. Et même si cela fonctionne, il reste à savoir comment l'appliquer dans la vie réelle. En effet, lors de la requête 7.8.9.241 c'est toujours le DNS du fournisseur qui répond, et non celui du client.

Et c'est ici qu'interviennent CNAME.

Du côté du fournisseur, il faut créer un alias pour toutes les adresses IP du sous-réseau dans un format qui redirigera la requête vers le DNS client.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
et ainsi de suite.

C'est pour les travailleurs =).

Pour les paresseux, la construction ci-dessous sera plus appropriée :

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

Maintenant, la requête d'informations à l'adresse 7.8.9.241 de 241.9.8.7.in-addr.arpa sur le serveur DNS du fournisseur sera transformée en 241.255-240.9.8.7.in-addr.arpa et sera envoyée au client DNS.

Du côté du client, il faudra traiter de telles requêtes. En conséquence, nous créons une zone 255-240.9.8.7.in-addr.arpa. Dans celle-ci, nous pouvons en principe placer des enregistrements inverses pour n'importe quelle IP de tout le sous-réseau /24, mais on ne nous interrogera que sur celles que le fournisseur nous redirige, donc pas de distractions =).
Pour illustrer, je donne encore une fois un exemple du contenu du fichier de zone inverse du côté client :

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; numéro de série
                        3H              ; rafraîchissement
                        15M             ; essai
                        1W              ; expiration
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

C'est en raison de l'utilisation du CNAME de notre côté en tant que fournisseur que nous recevons en réponse à la demande de données par adresse IP deux enregistrements au lieu d'un.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Et n'oubliez pas de configurer correctement les ACL. Car il est inutile de récupérer la zone PTR sans répondre à quiconque de l'extérieur =).

Source : habr.com