Délégation d'une zone de sous-réseau inverse inférieure à / 24 dans BIND. Comment ça marche

Une fois, j'ai été confronté à la tâche de donner à l'un des clients le droit de modifier les enregistrements PTR du sous-réseau qui lui était attribué / 28. Je n'ai pas d'automatisation pour éditer les paramètres BIND de l'extérieur. J'ai donc décidé d'aller dans l'autre sens - de déléguer au client un morceau de la zone de sous-réseau PTR / 24.

Il semblerait - quoi de plus simple? Nous prescrivons simplement le sous-réseau de la bonne manière et le dirigeons vers le NS souhaité comme cela se fait avec le sous-domaine. Mais non. Ce n'est pas si simple (bien qu'en réalité c'est généralement primitif, mais l'intuition n'aidera pas), c'est pourquoi j'écris cet article.

Qui veut le découvrir lui-même peut lire le RFC
Qui veut une solution toute faite, bienvenue chez cat.

Afin de ne pas retarder ceux qui aiment la méthode du copier-coller, je posterai d'abord la partie pratique, puis la partie théorique.

1. Pratique. Zone de délégation / 28

Disons que nous avons un sous-réseau de 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, vous devez trouver un fichier qui décrit la zone inverse de ce sous-réseau. Que ce soit 9.8.7.in-addr.arpa .
Les messages de 240 à 255 sont commentés, le cas échéant. Et à la fin du fichier, écrivez ce qui suit:

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

n'oubliez pas d'augmenter les zones série et de faire

 rndc reload 

Sur ce point, la partie fournisseur est terminée. Nous passons au client DNS.

Créez d' abord 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 ; serial 3H ; refresh 15M ; retry 1W ; expiry 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, ajoutez 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"; }; 

B redémarrez le processus de liaison.

 /etc/init.d/named restart 

C’est tout. Vous pouvez maintenant 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. 

Veuillez noter que non seulement l'enregistrement PTR est fourni, mais également CNAME. Il devrait en être ainsi. Si vous vous demandez pourquoi, bienvenue dans le chapitre suivant.

2. Théorie. Comment ça marche?

Il est difficile de configurer et de déboguer une boîte noire. Beaucoup plus facile si vous comprenez ce qui se passe à l'intérieur.

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

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

Nous disons à tout le monde que nous ne sommes pas responsables de ce site et nous disons qui est responsable. Et toutes les demandes vers client.domain sont redirigées vers 7.8.7.8. Lors de la vérification, nous voyons l'image suivante (omettez ce que le client a là. Cela n'a pas d'importance):

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

C'est-à-dire nous avons été informés qu'il existe un tel enregistrement A et son ip 7.8.9.241. Aucune information inutile.

Mais comment faire la même chose avec un sous-réseau?

Parce que Étant donné que notre serveur DNS est enregistré dans RIPE, lors de la demande d'une adresse IP PTR à partir de notre réseau, la première demande nous sera toujours envoyée. La logique est la même que pour les domaines. Mais comment entrer le sous-réseau dans le fichier de zone?

Nous essayons de le saisir comme ceci:

 255-240 IN NS 7.8.7.8 

Et ... un miracle ne s'est pas produit. Nous ne recevons aucune redirection de demande. Le fait est que bind n'est pas du tout conscient que ces entrées dans le fichier de zone inverse sont des adresses IP et plus encore, elles ne comprennent pas l'entrée de plage. Pour lui, ce n'est qu'un sous-domaine symbolique. C'est-à-dire pour bind, il n'y aura pas de différence entre " 255-240 " et " oursuperclient ". Et la demande pour que la demande aille là où elle devrait être, l'adresse dans la demande devrait ressembler à ceci: 241.255-240.9.8.7.in-addr.arpa . Ou comme ceci si nous utilisons un sous-domaine de caractères: 241.oursuperclient.9.8.7.in-addr.arpa . C'est différent de l'habituel: 241.9.8.7.in-addr.arpa .

Mains une telle demande sera problématique. Et si cela fonctionne, on ne sait toujours pas comment l'appliquer dans la vie réelle. Après tout, à la demande du 7.8.9.241 , le fournisseur DNS, et non le client, nous répond toujours.

Et ici CNAME entre en jeu.

Du côté du fournisseur, vous devez créer un alias pour toutes les adresses IP du sous-réseau dans un format qui transmettra la demande au DNS client.

 255-240 IN NS ns1.client.domain. 241 IN CNAME 241.255-240 242 IN CNAME 242.255-240  .. 

C'est pour travailler dur =).

Et pour les paresseux, le design ci-dessous est plus adapté:

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

À présent, une demande d'informations au 7.8.9.241 de 241.9.8.7.in-addr.arpa sur le serveur DNS du fournisseur sera convertie en 241.255-240.9.8.7.in-addr.arpa et ira au client DNS.

Le client devra traiter ces demandes. En conséquence, nous créons une zone de 255-240.9.8.7.in-addr.arpa . Dans ce document, nous pouvons essentiellement publier des enregistrements inversés pour n'importe quelle adresse IP de l'ensemble du sous-réseau / 24, mais nous ne serons interrogés que sur ceux que le fournisseur nous redirigera, de sorte que vous ne pourrez pas jouer avec =).
Pour illustrer, je vais donner un exemple du contenu du fichier de zone inverse côté client:

 $ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 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. 

Ici, du fait que nous utilisons CNAME de la part du fournisseur, nous recevons deux enregistrements en réponse à une demande de données par adresse IP, et non 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 l'ACL. Parce que cela n'a aucun sens de prendre une zone PTR pour vous-même et de ne répondre à personne de l'extérieur =).