sous zones bind 9

[eaglesly]

Hello.

J'ai une demande un peu particulière à satisfaire et je n'ai pas trouvé comment la résoudre. Voilà l'archi DNS :

Un DNS principal qui a décrit l'intranet et route les requêtes vers l'internet. Dans l'intranet, plusieurs zones et sous zones (appli1.zone, appli2.zone, appli3.zone2, appli4.zone2).
J'ai un proxy d'accès internet qui pointe sur ce DNS là et tout fonctionne nickel chrome.

Pour des utilisateurs venant d'un extranet, j'ai un autre proxy, qui lui pointe sur un autre DNS. Ce DNS, qu'on appellera dnspeer, il a une fonction de forward vers le dns principal pour quasiment toutes les requêtes. En effet, il contient une zone qu'on retrouve dans le DNS principal, pour laquelle les enregistrements peuvent différer de la zone principale. Je m'explique : le dnspeer contient une zone appli2.zone, qui contient des entrées différentes de celles de la zone appli2.zone du DNS Principal. Toutefois, les utilisateurs extranet doivent quand même, quand ils ne trouvent pas d'information dans la zone décrite sur le dnspeer, trouver l'enregistrement dans le DNS principal. En clair, je souhaite que ces utilisateurs utilisent le dnspeer comme DNS par défaut et que ce dns, s'il retourne une réponse 'pas d'enregistrement' dans la zone appli2.zone, forwarde la requête sur le DNS principal.

La zone appli2.zone que j'ai créée sur le dnspeer est une zone principale avec les paramètres par défaut (créée par webmin).

J'ai pensé faire de l'insertion dans le etc/hosts, mais c'est pas possible pour des raisons de maintenance...

Quelqu'un peut-il m"aider ?

Merci d'avance.

[doohanjoe]

Dnspeer à son lancement considère qu'il est maitre de la zone appli2.zone, s'il ne trouve pas d'entrée correspondante en local, il considère à juste titre qu'elle n'existe pas

Le seul moyen pour palier cela, c'est de déclarer la zone appli2.zone dans dnspeer et dans le dns principal en ne mettant que les enregistrement que tes utilisateurs ont besoin dans dnspeer. Ca s'applique aux zones communes aux 2 dns, car un dns ne peut pas être le responsable d'une partie d'une zone.

Sinon, s'il y a un autre moyen, je suis preneur aussi.

Cordialement.

[eaglesly]

Merci pour la réponse

Dnspeer à son lancement considère qu'il est maitre de la zone appli2.zone, s'il ne trouve pas d'entrée correspondante en local, il considère à juste titre qu'elle n'existe pas

Jusque là, je suis... et je suis d'accord.

Le seul moyen pour palier cela, c'est de déclarer la zone appli2.zone dans dnspeer et dans le dns principal en ne mettant que les enregistrement que tes utilisateurs ont besoin dans dnspeer. Ca s'applique aux zones communes aux 2 dns, car un dns ne peut pas être le responsable d'une partie d'une zone.

Là, j'ai eu un petit peu plus de mal. Mais si j'ai bien compris, tu me parles de recoller dans le dnspeer les enregistrements du dns principal que les utilisateurs extranet sont susceptibles d'utiliser spécifiquement...

Le problème que ca pose c'est pour la maintenance de cette zone dans le dns principal : les modifs ne seront pas répercutées dans le dnspeer... Et c'est là, tout mon problème... En fait, je ne veux mettre dans le zone appli2.zone du dnspeer que les enregistrements spécifiques dont l'adresse diffère pour les utilisateurs extranet des utilisateurs intranet. Ces enregistrements prévaudraient sur ceux du dns principal.

En gros, le dnspeer serait un dns "de premier niveau" : on lui pose la question. S'il dit qu'il sait, on prend sa réponse. S'il dit qu'il ne sait pas, il transmet au "deuxième niveau" (dns principal), et restitue la réponse du deuxième niveau. C'est schématiquement ce que je voudrais...

Sinon, s'il y a un autre moyen, je suis preneur aussi.

Cordialement.

[doohanjoe]

Ca veut dire que les utilisateurs de l'extranet (qui pointent sur dnspeer) ne devront jamais avoir accès aux enregistrements du dns principal, au moins pour la zone appli2.zone. Pour de possibles enregistrement commun il te faudra les dupliquer sur le dns principal et sur dnspeer.

En fait, je ne veux mettre dans le zone appli2.zone du dnspeer que les enregistrements spécifiques dont l'adresse diffère pour les utilisateurs extranet des utilisateurs intranet. Ces enregistrements prévaudraient sur ceux du dns principal.

J'ai du raté une marche , j'ai compris que les utilisateurs de l'intranet pointaient sur le dns principal et que ceux de l'extranet pointaient sur le dnspeer, si je comprends bien, les utilisateurs intranet et extranet pointent sur dnspeer.

Partant de là, pour qu'il y ait des réponses différentes en fonction de l'adresse, il te suffit de créé des vues (view) dans le named.conf et de faire pointer les zones appli2.zone vers des fichiers différents.

J'espère que ça réponds un peu à ta question

[eaglesly]

Ca veut dire que les utilisateurs de l'extranet (qui pointent sur dnspeer) ne devront jamais avoir accès aux enregistrements du dns principal, au moins pour la zone appli2.zone. Pour de possibles enregistrement commun il te faudra les dupliquer sur le dns principal et sur dnspeer.

Justement ce que je voudrais éviter d'avoir à faire.

J'ai du raté une marche , j'ai compris que les utilisateurs de l'intranet pointaient sur le dns principal et que ceux de l'extranet pointaient sur le dnspeer, si je comprends bien, les utilisateurs intranet et extranet pointent sur dnspeer.

Non... t'avais tout bien compris du premier coup. Les intra pointent sur le DNS principal. les extra pointent sur le peer. le peer ne joue le role de 1er niveau que pour les extra.

On va peut être régler le problème à la racine : changer le domaine pour les extras... on sera tranquille comme ca

Merci.

[doohanjoe]

C'est effectivement peut être mieux, j'ai été confronté au même type de problème et j'ai du dupliquer certains enregistrements dans les 2 dns.

Bon courage en tout cas!

[tomtom]

Salut,

j'ai peutetre raté un truc, mais à mon avis tu peux essayer de definir un forwarder pour chaque zone...

Sur le peer :

Code: Tout sélectionner

zone "appli2.zone" {
     type master;
     file "appli2.zone.dat"
     forwarder { ip_dns_principal; };
}


Bon, jamais testé, mais je vois pas pourquoi ca ne marcherait pas. Il y a surement un peu de config à faire cote allow_transfer;

Sinon, il me semble que ta conception est bancale. Quand on fait un split dns, c'est pas pour reproduire des infos de la zone interne sur la zone externe. Le principe du split est que l'on ne va pas fournir la même information selon l'origine de la requete pour une même demande. On peut le faire avec un seul serveur et des ACL judicieuses, ou alors comme tu le fais avec un second serveur. Mais dans ce cas, sur le second serveur, tu dois creer toute la zone, pas juste une partie et l'autre tu renvoies vers le premier.... Rien n'enmpeche d'avoir des enregistrements communs dans les 2 zones, mais il faut reconnaitre que lorsque 'un hote change, la modification doit etre reperutée sur les deix zones... C'est logique.


t.