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
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-240n'oubliez pas d'augmenter la zone série et de faire
rndc reloadCeci 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 restartTous. 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.8Nous 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.241Ceux. 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.8Et... 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-240Demandez 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 du côté du fournisseur, et en réponse à une demande de données par adresse IP, nous recevons deux enregistrements, pas 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 s'approprier une zone PTR et de ne répondre à personne de l'extérieur =).
Source: habr.com