DNS inversé dans un monde CIDR


24

Le DNS inversé semble être fortement lié aux limites des classes, quelles méthodes existent maintenant que le CIDR est la norme pour déléguer l'autorité pour un sous-réseau? S'il existe plusieurs méthodes, laquelle est la meilleure? Avez-vous besoin de gérer la délégation différemment selon le serveur DNS (Bind, djbdns, Microsoft DNS, autre)? Disons que j'ai le contrôle d'un réseau de classe B 168.192.in-addr.arpa, veuillez fournir des exemples pour:

  • Comment déléguer l'autorité pour un / 22?
  • Comment déléguer l'autorité pour un / 25?

Réponses:


31

Déléguer un / 22 est facile, c'est la délégation des 4/24. A / 14 est la délégation des 4/16, etc.

La RFC2317 couvre les cas spéciaux avec un masque de réseau plus long que / 24. Fondamentalement, il n'y a pas de moyen super propre de faire la délégation des zones in-addr.arpa sur autre chose que les limites d'octets, mais vous pouvez contourner cela. Disons que je veux déléguer 172.16.23.16/29, qui serait les adresses IP 172.16.23.16 -> 172.16.23.23.

En tant que propriétaire de la zone 23.16.172.in-addr.arpa, je pourrais le mettre dans mon fichier de zone 23.16.172.rev pour déléguer cette plage à mon client:

16-29              IN NS  ns1.customer.com
16-29              IN NS  ns2.customer.com
16                 IN CNAME    16.16-29.23.16.172.in-addr.arpa.
17                 IN CNAME    17.16-29.23.16.172.in-addr.arpa.
18                 IN CNAME    18.16-29.23.16.172.in-addr.arpa.
19                 IN CNAME    19.16-29.23.16.172.in-addr.arpa.
20                 IN CNAME    20.16-29.23.16.172.in-addr.arpa.
21                 IN CNAME    21.16-29.23.16.172.in-addr.arpa.
22                 IN CNAME    22.16-29.23.16.172.in-addr.arpa.
23                 IN CNAME    23.16-29.23.16.172.in-addr.arpa.

Ainsi, vous pouvez voir que je définis une nouvelle zone (16-29.23.16.172.in-addr.arpa.) Et que je la délègue aux serveurs de noms de mon client. Ensuite, je crée des CNAME à partir des adresses IP à déléguer au numéro correspondant sous la zone nouvellement déléguée.

En tant que client à qui ceux-ci ont été délégués, je ferais quelque chose comme ce qui suit dans named.conf:

zone "16-29.23.16.172.in-addr.arpa" { 
    type master;
    file "masters/16-29.23.16.172.rev";
};

Et puis dans le fichier .rev, je ferais juste des PTR comme n'importe quelle zone in-addr.arpa normale:

17                 IN PTR office.customer.com.
18                 IN PTR www.customer.com.
(etc)

C'est en quelque sorte la façon la plus simple de le faire et cela rend les clients avertis heureux parce qu'ils ont une zone in-addr.arpa pour y mettre les PTR, etc. Vous ne voulez pas configurer une zone entière, c'est simplement enregistrer individuellement CNAME avec des noms similaires dans leur zone principale.

Dans ce cas, nous, en tant que délégués, aurions quelque chose comme ceci dans notre fichier 23.16.172.rev:

16                 IN CNAME    16.customer.com.
17                 IN CNAME    17.customer.com.
18                 IN CNAME    18.customer.com.
19                 IN CNAME    19.customer.com.
20                 IN CNAME    20.customer.com.
21                 IN CNAME    21.customer.com.
22                 IN CNAME    22.customer.com.
23                 IN CNAME    23.customer.com.

Le concept est donc similaire à l'autre idée, mais au lieu de créer une nouvelle zone et de la déléguer au client, vous nommez les enregistrements avec des noms dans la zone principale déjà existante du client.

Le client aurait quelque chose comme ça dans son fichier de zone customer.com:

office             IN A   172.16.23.17
17                 IN PTR office.customer.com.
www                IN A   172.16.23.18
18                 IN PTR www.customer.com.
(etc)

Cela dépend simplement du type de client. Comme je l'ai dit, cela dépend simplement du type de client. Un client avisé préférera créer sa propre zone in-addr.arpa et trouvera très étrange d'avoir des PTR dans une zone de nom de domaine. Un client non averti voudra qu'il "fonctionne tout simplement" sans avoir à faire une tonne de configuration supplémentaire.

Il existe probablement d'autres méthodes, détaillant simplement les deux que je connais.


Je pensais juste à ma déclaration sur la façon dont / 22 et / 14 sont faciles et je réfléchissais à pourquoi c'est vrai mais tout ce qui se situe entre 25 et 32 ​​est difficile. Je n'ai pas testé cela, mais je me demande si vous pourriez déléguer la totalité / 32 au client comme ceci:

16                 IN NS ns1.customer.com.
17                 IN NS ns1.customer.com.
(etc)

Ensuite, du côté client, vous attrapez l'ensemble / 32:

zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)

Et puis dans le fichier individuel, vous auriez quelque chose comme ceci:

@            IN PTR office.customer.com.

L'inconvénient évident est qu'un fichier par / 32 est un peu brut. Mais je parie que ça marcherait.

Tout ce que j'ai mentionné est du DNS pur, si un serveur DNS ne vous a pas laissé le faire, c'est parce qu'il restreint toutes les fonctionnalités du DNS. Mes exemples utilisent évidemment BIND, mais nous avons fait le côté client en utilisant Windows DNS et BIND. Je ne vois aucune raison pour laquelle cela ne fonctionnerait avec aucun serveur.


1
Vous pensez probablement à rfc2317 ( tools.ietf.org/html/rfc2317 )
Zoredache


0

BIND a la macro $ GENERATE propriétaire pour créer des séquences d'enregistrements PTR, mais il suppose également un monde de classe et ne vous sera pas très utile. Je ne connais aucun autre serveur ayant un support spécial pour les zones inverses CIDR, bien que je soupçonne qu'il y a une demande!

PowerDNS a une belle interface backend qui vous permettrait d'écrire la vôtre si le problème est suffisamment important pour que cela en vaille la peine. Vous pouvez également prototyper en utilisant le "PipeBackend". Vous pouvez même faire des choses SQL magiques via les interfaces MySQL / PostgreSQL - d'autant plus que Postgres a un type de données "cidr".


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.