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

Un jour, j'ai été confronté à la tâche de donner à l'un de mes clients le droit de modifier les enregistrements PTR du sous-réseau /28 qui lui était attribué. Je n'ai pas d'automatisation pour modifier les paramètres BIND de l'extérieur. Par conséquent, j'ai décidé d'emprunter une voie différente : déléguer au client une partie de la zone PTR du sous-réseau /24.

Il semblerait - quoi de plus simple ? Nous enregistrons simplement le sous-réseau selon les besoins et le dirigeons vers le NS souhaité, comme cela se fait avec un sous-domaine. Mais non. Ce n’est pas si simple (même si en réalité c’est généralement primitif, mais l’intuition n’aidera pas), c’est pourquoi j’écris cet article.

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

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

1. Entraînez-vous. Zone de délégation /28

Disons 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.domaine).

Sur le DNS du fournisseur, vous devez trouver un fichier décrivant la zone inversée de ce sous-réseau. Qu'il en soit ainsi 9.8.7.in-adr.harpe.
Nous commentons les entrées de 240 à 255, s'il y en a. Et à la fin du fichier on écrit ce qui suit :

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

n'oubliez pas d'augmenter la zone série et de faire

rndc reload

Ceci termine la partie fournisseur. Passons au DNS du client.

Tout d'abord, créons un fichier /etc/bind/master/255-240.9.8.7.in-addr.arpa 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 nommé.conf ajoutez une 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émarre le processus de liaison.

/etc/init.d/named restart

Tous. Maintenant, vous pouvez 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 indiqué, mais également le CNAME. Voilà comment il devrait être. Si vous vous demandez pourquoi, alors bienvenue dans le prochain chapitre.

2. Théorie. Comment ça fonctionne.

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

Quand on délègue un sous-domaine dans un domaine domaine, alors nous écrivons quelque chose comme ceci :

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

Nous disons à tous ceux qui le demandent que nous ne sommes pas responsables de ce site et disons qui est responsable. Et toutes les demandes de client.domaine rediriger vers 7.8.7.8. Lors de la vérification, nous voyons l'image suivante (nous omettrons ce que le client a là-bas. Cela n'a pas d'importance) :

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

Ceux. nous avons été informés qu'il existe un tel enregistrement A et que son adresse IP est 7.8.9.241. Aucune information inutile.

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

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

Essayons de le saisir comme ceci :

255-240  IN  NS      7.8.7.8

Et... le miracle ne s'est pas produit. Nous ne recevons aucune demande de redirection. Le fait est que bind ne sait même pas que ces entrées dans le fichier de zone inversée sont des adresses IP, et encore plus ne comprend pas l'entrée de plage. Pour lui, il ne s'agit que d'une sorte de sous-domaine symbolique. Ceux. pour bind, il n'y aura aucune différence entre "255-240"Et"notresuperclient". Et pour que la requête aille là où elle doit aller, l'adresse dans la requête doit ressembler à ceci : 241.255-240.9.8.7.in-addr.arpa. Ou comme ceci si nous utilisons un sous-domaine de caractère : 241.notresuperclient.9.8.7.in-addr.arpa. C'est différent de l'habituel : 241.9.8.7.in-adr.harpe.

Il sera difficile de faire une telle demande manuellement. Et même si cela fonctionne, on ne sait toujours pas comment l’appliquer dans la vraie vie. Après tout, sur demande 7.8.9.241 Le DNS du fournisseur nous répond toujours, pas celui du client.

Et c'est là qu'ils entrent en jeu CNAME.

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 requête au DNS du client.

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

C'est pour les travailleurs =).

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

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

Demandez maintenant des informations à 7.8.9.241 de 241.9.8.7.in-adr.harpe sur le serveur DNS du fournisseur sera converti en 241.255-240.9.8.7.in-addr.arpa et va au client DNS.

Le côté client devra gérer ces demandes. En conséquence, nous créons une zone 255-240.9.8.7.in-addr.arpa. Dans celui-ci, nous pouvons, en principe, placer des entrées inversées pour n'importe quelle adresse IP de l'ensemble du sous-réseau /24, mais ils ne nous poseront de questions que sur celles que le fournisseur nous transmet, nous ne pourrons donc pas jouer =).
Pour illustrer, je vais encore une fois donner un exemple du contenu d'un fichier de zone inversée 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.

C’est parce que nous utilisons CNAME côté fournisseur que nous recevons les données suivantes en réponse à une requête : Adresse IP Deux entrées, pas une seule.

#>  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 s'approprier une zone PTR et de ne répondre à personne de l'extérieur =).

Source: habr.com

Délégation de zone inversée vers les sous-réseaux inférieurs à /24 dans BIND. Comment ça fonctionne

Youri Gagarine