view "lan" {
match-clients { view_lan; };
include "lan.conf";
};
view "dmz" {
match-clients { view_dmz; };
include "dmz.conf";
};
view "external" {
match-clients { any; };
include "external.conf";
};
------------------------------------------------------------------------
A noter que ce DNS fonctionne parfaitement, passe la vérification
zonecheck sans problèmes.
Mais en fait, rien qu'en lisant la config, on voit tout de suite le
problème : le secondaire, en DMZ reçoit ses infos de la view "dmz", et
lorsqu'il est interrogé de l'extérieur renvoie l'adresse privée, et non
l'adresse publique
QUESTION :
L'ordre de déclaration est-il pris en compte ? C'est à dire ceci
pourrait marcher ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
Xavier a écrit :
J'ai un petit souci avec mon DNS secondaire (en DMZ), et la façon dont les views du primaire lui transmettent leurs données.
Problème classique avec les vues. Il faut faire en sorte que les requêtes de mise à jour du secondaire correspondent à la bonne vue du primaire, par exemple en jouant sur l'adresse source ou destination. Cf. les options match-clients et match-destinations dans les définitions des vues du primaire et transfer-source dans les définitions de zones du secondaire.
Tu veux transférer sur le secondaire des zones d'une seule vue du primaire ou de plusieurs ?
L'ordre de déclaration est-il pris en compte ?
Oui, BIND utilise la première vue dont les critères correspondent à la requête.
J'en doute, car la première vue "external" va tout ramasser avec son "any".
Salut,
Xavier a écrit :
J'ai un petit souci avec mon DNS secondaire (en DMZ), et la façon dont
les views du primaire lui transmettent leurs données.
Problème classique avec les vues. Il faut faire en sorte que les
requêtes de mise à jour du secondaire correspondent à la bonne vue du
primaire, par exemple en jouant sur l'adresse source ou destination. Cf.
les options match-clients et match-destinations dans les définitions des
vues du primaire et transfer-source dans les définitions de zones du
secondaire.
Tu veux transférer sur le secondaire des zones d'une seule vue du
primaire ou de plusieurs ?
L'ordre de déclaration est-il pris en compte ?
Oui, BIND utilise la première vue dont les critères correspondent à la
requête.
J'ai un petit souci avec mon DNS secondaire (en DMZ), et la façon dont les views du primaire lui transmettent leurs données.
Problème classique avec les vues. Il faut faire en sorte que les requêtes de mise à jour du secondaire correspondent à la bonne vue du primaire, par exemple en jouant sur l'adresse source ou destination. Cf. les options match-clients et match-destinations dans les définitions des vues du primaire et transfer-source dans les définitions de zones du secondaire.
Tu veux transférer sur le secondaire des zones d'une seule vue du primaire ou de plusieurs ?
L'ordre de déclaration est-il pris en compte ?
Oui, BIND utilise la première vue dont les critères correspondent à la requête.
-- Xav The cracked brass bells will ring, To summon back the fire witch
xavier
Xavier wrote:
Ca, ça pourrait être la solution, effectivement.
C'est. Merci Pascal.
Je me serais épargné bien de la peine en allant consulter les excellents guides chez <http://www.zytrax.com/books/> . Tout le rete du site est une mine, d'ailleurs.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Xavier <xavier@groumpf.org> wrote:
Ca, ça pourrait être la solution, effectivement.
C'est. Merci Pascal.
Je me serais épargné bien de la peine en allant consulter les excellents
guides chez <http://www.zytrax.com/books/> . Tout le rete du site est
une mine, d'ailleurs.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Je me serais épargné bien de la peine en allant consulter les excellents guides chez <http://www.zytrax.com/books/> . Tout le rete du site est une mine, d'ailleurs.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
xavier
Xavier wrote:
> Ca, ça pourrait être la solution, effectivement.
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça marche plus pour les résolutions sur la machine "public_secondary" elle même. Elle reçoit ses réponses comme une machine externe, ce qu'elle n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Est-ce possible par les acl de différencier les transferts de zones des requêtes DNS simples ?
Merci,
-- Xav The cracked brass bells will ring, To summon back the fire witch
Xavier <xavier@groumpf.org> wrote:
> Ca, ça pourrait être la solution, effectivement.
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça
marche plus pour les résolutions sur la machine "public_secondary" elle
même. Elle reçoit ses réponses comme une machine externe, ce qu'elle
n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Est-ce possible par les acl de différencier les transferts de zones des
requêtes DNS simples ?
Merci,
--
Xav
The cracked brass bells will ring,
To summon back the fire witch
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça marche plus pour les résolutions sur la machine "public_secondary" elle même. Elle reçoit ses réponses comme une machine externe, ce qu'elle n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Est-ce possible par les acl de différencier les transferts de zones des requêtes DNS simples ?
Merci,
-- Xav The cracked brass bells will ring, To summon back the fire witch
Pascal Hambourg
Xavier a écrit :
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça marche plus pour les résolutions sur la machine "public_secondary" elle même. Elle reçoit ses réponses comme une machine externe, ce qu'elle n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Ah, j'avais prévenu qu'il y avait des effets de bord.
Est-ce possible par les acl de différencier les transferts de zones des requêtes DNS simples ?
Voir ma première réponse. Par exemple utiliser une adresse IP supplémentaire, soit sur le primaire comme destination, soit sur le secondaire comme source des requêtes liées au transfert de zone.
Xavier a écrit :
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça
marche plus pour les résolutions sur la machine "public_secondary" elle
même. Elle reçoit ses réponses comme une machine externe, ce qu'elle
n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Ah, j'avais prévenu qu'il y avait des effets de bord.
Est-ce possible par les acl de différencier les transferts de zones des
requêtes DNS simples ?
Voir ma première réponse. Par exemple utiliser une adresse IP
supplémentaire, soit sur le primaire comme destination, soit sur le
secondaire comme source des requêtes liées au transfert de zone.
Si ça fait bien ce que je veux pour le transfert de zones, par contre ça marche plus pour les résolutions sur la machine "public_secondary" elle même. Elle reçoit ses réponses comme une machine externe, ce qu'elle n'est pas. Et comme c'est un MX, ça fait un peu désordre ...
Ah, j'avais prévenu qu'il y avait des effets de bord.
Est-ce possible par les acl de différencier les transferts de zones des requêtes DNS simples ?
Voir ma première réponse. Par exemple utiliser une adresse IP supplémentaire, soit sur le primaire comme destination, soit sur le secondaire comme source des requêtes liées au transfert de zone.
