Bind synchro entre slave et master

[Kane]

Bonjour à tous,

Je me demande comment configurer Bind sur mon piti réseau et le transfert de zone est une question assez importante, surtout au niveau du "sens".

Posons le décor : IPCOP avec interfaces rouge (192.168.3.x) - orange (192.168.2.x) - verte (192.168.1.x)
Je souhaite que mon/mes serveur(s) DNS soi(en)t configuré(s) pour les zones orange et verte.
Je me suis donc dit qu'il men fallait 2, un dans la réseau vert et l'autre dans orange, mais j'ai ptet tort

Si j'ai raison (ça peut arriver on sait jamais), quel serveur DNS doit être master et lequel doit être slave ? J'ai lu que le c'était le master qui envoyait le "Notify" mais que c'était le slave qui initiait le transfert.

J'avoue que je me pose des questions au niveau sécurité, le plus simple aurait été un seul serveur DNS dans la DMZ Orange qui gérait les 2 zones, possible ?

Merci pour vos réponses

[jdh]

(pas facile à lire ...)


Bind est un serveur dns quand même assez lourd. Il est en revanche très puissant.

Par exemple :
- la syntaxe des fichiers n'est pas instantanée,
- il permet de faire des split view : adaptation de la réponse selon le demandeur.


En multisites, on peut avoir N serveurs dns (et dhcp). En monosite, c'est un peut du gaspillage ...

[ccnet]

Ôtez moi d'un doute : ce ou ces serveur dns ne sont pas destinés à être primaire et secondaire sur internet ? Peut être avez vous raison , mais je ne comprend pas ce qui justifie une solution, certes puissante, mais aussi lourde, pour gérer quelques noms d'hôtes sur un petit réseau. Car vous avez bien dit petit.

[Kane]

(pas facile à lire ? ah... désolé, schéma mal posé peut être ?)
Je suis d'accord qu'en mono site pour 10 machines qui se battent en duel c'est du gaspillage. Il serait donc possible de monter un seul serveur Bind dans la DMZ sans souci de "sécurité" ?

Je me réponds un peu tout seul (= réfléchir à haute voix), un PC 192.168.1.10 (sur le LAN donc) contacte mon serveur DNS qui est dans la DMZ 192.168.2.2 mais qui fait autorité sur les zones 192.168.1.* et 192.168.2.*. il demande à aller sur google.com, le serveur DNS connait et lui répond. Jusque là tout va bien.

En réfléchissant comme ça, je ne vois plus où était mon problème et pourquoi j'hésitais sur un ou deux serveurs DNS. Au niveau sécurité un seul est très bien puisque la réponse se fait sur "demande" (donc connexion établie) mais niveau redondance, je n'en ai pas (est-ce important pour un si petit réseau ?).

Bon je vais tester et je verrais. Par contre, la question sur le sens de la "synchronisation" (terme sans doute mal choisi) est toujours valable.
C'est juste pour savoir lequel mettre en DMZ et lequel mettre sur le LAN, ouvrir l'accès dans le sens LAN vers DMZ, ok mais dans l'autre, je suis loin d'être chaud.

Merci jdh pour la "provocation de réflexion"

[Kane]

Ôtez moi d'un doute : ce ou ces serveur dns ne sont pas destinés à être primaire et secondaire sur internet ? Peut être avez vous raison , mais je ne comprend pas ce qui justifie une solution, certes puissante, mais aussi lourde, pour gérer quelques noms d'hôtes sur un petit réseau. Car vous avez bien dit petit.

Oula non, c'est juste pour mon organisation "perso" pour le moment, juste en serveur de cache. Par contre le but final est quand même d'essayer de devenir primaire pour une zone définie (mon nom de domaine).

Mais le but reste essentiellement d'apprendre.

[jdh]

Un exemple :

- une petite entreprise,
- un réseau interne de 6 micros fixes, 4 portables, 1 serveur Windows 2003, 1 serveur linux (Debian/Postfix),
- un firewall, une dmz avec un relais mail et un serveur web.

Pour ce cas, le W2K3 peut largement être dhcp et dns. (De base le dns sera dynamique).


Quelle intérêt à avoir un serveur dns privé pour la dmz ? Aucun dans l'exemple que je cite.


Autre exemple :

- un hébergement (nom, site web, boites mails) chez un hébergeur connu,
- un réseau local de 5 micros,
- un firewall (avec une zone Fonera)
- un serveur de mail local avec boites locales alimentées par fetchmail,
- le même nom dns pour le réseau interne.

Ici, on utilise le même nom que celui défini sur Internet mais on a pas les mêmes valeurs : localement le MX est le serveur de mail local = pas d'aller et retour sur Internet pour envoyer d'une boite à l'autre.

[Kane]

Dans le premier exemple, quel est le DNS des serveurs en DMZ ? le W2K3 ?

Allons au bout des choses, j'ai déjà une AD sous W2K3 mais j'avais plutôt envie de le laisser tourner dans son coin et ne pas me servir de son DNS (mise à part la partie authentification sur le domaine qui ne touche que peu de postes sur mon réseau).
IPCop fait très bien son office en déclarant les hôtes statiques et relaye bien les demandes vers l'extérieur (livebox puis DNS Orange). Mais j'aimerais aussi décharger IPCop de cette tâche.

Je comprends très bien "l'inutilité" de tout ça. D'ailleurs je me suis mis il y a peu à la virtualisation pour palier au nombre de machines en constante évolution

Donc pour résumer un peu vos réponses, un seul serveur DNS peut faire autorité sur mes 2 zones DMZ et LAN sans "trou" de sécurité. Sa place doit être dans la DMZ dans ce cas je pense, surtout si je veux faire autorité sur mon nom de domaine Internet plus tard.

Merci pour vos réponses, j'avance doucement dans ma réflexion et la mise en place devrait commencer sous peu. Si vous avez d'autres idées, commentaires, réflexion, je suis toujours preneur, on apprend toujours plus en échangeant

[Kane]

Re bonjour ici, je reviens vers vous toujours pour la même question car je ne trouve pas la réponse sur le net : le sens du transfert de zone.
Après avoir lu quelques tutoriels dont http://www.linux-france.org/article/serveur/dns-bind/, il semble que je puisse "synchroniser" un BIND en DMZ avec mon DC sous Windows 2003 sur le LAN.

Est-ce "dangereux" d'ouvrir le port 53 dans le sens DMZ -> LAN ? Je pense que oui (j'en suis même sûr ), mais existe-t-il réellement un 'sens" pour la mise à jour des zones entre le master d'une zone et son slave ?

Merci de votre aide

[Kane]

premier début de piste, ce blog : http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architecture-dns-d-entreprise qui dit :

Ports DNS et Firewall
Voici un petit mémento sur les ports utilisés pour les requêtes DNS :

* envoi de la requête port > 1023 vers port 53 en tcp ou udp ;
* réponse à la requête : port 53 vers port > 1023 en tcp ou udp.

On dit généralement que l'udp est utilisée pour les requêtes simples et tcp pour les transferts de zones. Mais, en fait, en fonction de la taille de la réponse, tcp peut être obligatoire même pour les requêtes simples.

Donc si je comprends bien, que ce soit une requête DNS classique, par un client qui veut résoudre ixus.net par exemple, ou que ce soit une "synchronisation" entre DNS maître et esclave, les mêmes ports sont utilisés, je me trompe ?

La question reste toujours valide : qui envoie la requête et qui répond entre le DNS maître et l'esclave ?

à suivre...

[ccnet]

Toutes les opérations dns, y compris les transferts de zone, se font pour l'écoute sur le port UDP 53 et > 1023 pour l'émission.

La question reste toujours valide : qui envoie la requête et qui répond entre le DNS maître et l'esclave ?

Le rôle du serveur (master, slave, ...) est spécifié dans named.conf pour chaque zone.

Si vous regardez l'enregistrement SOA pour db.votrezone de votre serveur esclave vous verrez que c'est lui qui contient les informations sur la périodicité de la connexion, c'est donc bien l'esclave qui lance la connexion vers le serveur maître. Les nombres qui suivent, entre parenthèses, le débt de l'enregistrement SOA liste successivement : le numéro de série, le délai de rafraichissement, le délai pour nouvel essai, delai obsolescence, TTL minimum. Toutes les valeurs sont en secondes.

Si vous le trouvez encore je vous conseille la lecture de "dns et bind" chez Oreilly. Tout y est, c'est le livre de référence.

PS: je ne suis pas persuadé que les serveurs maître et esclaces doivent se trouver dans des sous réseaux différents. Nous sommes bien d'accord sur l'aspect purement didactique de votre configuration. Sur le plan pratique cela n'a aucune raison d'être et la liste d'hôtes statiques d'ipcop fait largement l'affaire ainsi la fonction de cache dns pour la résolution externe.

[Kane]

Merci pour votre réponse, et merci pour l'info bibliographique. Malgré internet je reste un adepte de cette source d'informations.

Pour votre P.S, oui nous sommes parfaitement d'accord, mais ce n'est pas "drôle"