J'ai configuré une zone avec des vues sur mon DNS principal (Debian
Lenny, Bind9 :
acl "vlan7" { 192.168.20.0/23; } ;
view "vlan7" {
match-clients { "vlan7"; };
include "/etc/bind/named.conf.root";
include "/etc/bind/named.conf.localnet";
zone "filer.localnet" IN {
type master;
file "db.vlan7.filer.localnet";
allow-transfer { key master-slave.tsig.eve; };
};
};
view "default" {
match-clients { any; };
include "/etc/bind/named.conf.root";
include "/etc/bind/named.conf.localnet";
zone "filer.localnet" IN {
type master;
file "db.default.filer.localnet";
allow-transfer { key master-slave.tsig.eve; };
};
};
Ca fonctionne sans surprise sur ce serveur : les machines du domaine
filer.localnet ont bien des IP différentes en fonction du vlan des clients.
Je souhaite donc maintenant configurer mes DNS esclaves afin qu'ils
puissent faire des tranfert de zone et ainsi récupérer les nouveau
fichiers de zone :
acl "vlan7" { 192.168.20.0/23; } ;
view "vlan7" {
match-clients { "vlan7"; };
include "/etc/bind/named.conf.root";
include "/etc/bind/named.conf.localnet";
zone "filer.localnet" IN {
type slave;
file "db.vlan7.filer.localnet";
masters { 192.168.1.1; };
};
};
view "default" {
match-clients { any; };
include "/etc/bind/named.conf.root";
include "/etc/bind/named.conf.localnet";
zone "filer.localnet" IN {
type slave;
file "db.default.filer.localnet";
masters { 192.168.1.1; };
};
};
Et là c'est beaucoup moins bien... le serveur maitre autorise bien le
transfert de zone, selon une seule vue, puisque le serveur esclave est
alors vu comme un client ! Du coup mes fichiers de zone
"db.vlan7.filer.localnet" et "db.default.filer.localnet" sont
identiques, ce qui n'est pas vraiment le résultat souhaité...
J'ai potassé mes différentes sources de documentation de bind, mais sans
succès :(
Une idée ?
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,
Eric Belhomme a écrit :
J'ai configuré une zone avec des vues sur mon DNS principal (Debian Lenny, Bind9 :
[...]
Je souhaite donc maintenant configurer mes DNS esclaves afin qu'ils puissent faire des tranfert de zone et ainsi récupérer les nouveau fichiers de zone :
[...]
Et là c'est beaucoup moins bien... le serveur maitre autorise bien le transfert de zone, selon une seule vue, puisque le serveur esclave est alors vu comme un client ! Du coup mes fichiers de zone "db.vlan7.filer.localnet" et "db.default.filer.localnet" sont identiques, ce qui n'est pas vraiment le résultat souhaité...
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle vue) ?
J'ai potassé mes différentes sources de documentation de bind, mais sans succès :( Une idée ?
On peut différencier les vues en jouant sur l'adresse source de la requête de transfert de zone (option "transfer-source" de la zone esclave). Ça implique que l'esclave ait une adresse correspondant à chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître recevant la requête de transfert (option "masters" de la zone esclave).
Salut,
Eric Belhomme a écrit :
J'ai configuré une zone avec des vues sur mon DNS principal (Debian
Lenny, Bind9 :
[...]
Je souhaite donc maintenant configurer mes DNS esclaves afin qu'ils
puissent faire des tranfert de zone et ainsi récupérer les nouveau
fichiers de zone :
[...]
Et là c'est beaucoup moins bien... le serveur maitre autorise bien le
transfert de zone, selon une seule vue, puisque le serveur esclave est
alors vu comme un client ! Du coup mes fichiers de zone
"db.vlan7.filer.localnet" et "db.default.filer.localnet" sont
identiques, ce qui n'est pas vraiment le résultat souhaité...
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle
vue) ?
J'ai potassé mes différentes sources de documentation de bind, mais sans
succès :(
Une idée ?
On peut différencier les vues en jouant sur l'adresse source de la
requête de transfert de zone (option "transfer-source" de la zone
esclave). Ça implique que l'esclave ait une adresse correspondant à
chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître
recevant la requête de transfert (option "masters" de la zone esclave).
J'ai configuré une zone avec des vues sur mon DNS principal (Debian Lenny, Bind9 :
[...]
Je souhaite donc maintenant configurer mes DNS esclaves afin qu'ils puissent faire des tranfert de zone et ainsi récupérer les nouveau fichiers de zone :
[...]
Et là c'est beaucoup moins bien... le serveur maitre autorise bien le transfert de zone, selon une seule vue, puisque le serveur esclave est alors vu comme un client ! Du coup mes fichiers de zone "db.vlan7.filer.localnet" et "db.default.filer.localnet" sont identiques, ce qui n'est pas vraiment le résultat souhaité...
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle vue) ?
J'ai potassé mes différentes sources de documentation de bind, mais sans succès :( Une idée ?
On peut différencier les vues en jouant sur l'adresse source de la requête de transfert de zone (option "transfer-source" de la zone esclave). Ça implique que l'esclave ait une adresse correspondant à chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître recevant la requête de transfert (option "masters" de la zone esclave).
Eric Belhomme
Pascal Hambourg a écrit :
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle vue) ?
l'esclave voit la vue par défaut
On peut différencier les vues en jouant sur l'adresse source de la requête de transfert de zone (option "transfer-source" de la zone esclave). Ça implique que l'esclave ait une adresse correspondant à chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître recevant la requête de transfert (option "masters" de la zone esclave).
c'est une bonne idée. Mais je crois que j'ai trouvé une autre alternative plus élégante...
En fait, le problème à résoudre est de fournir une vue unifiée pour mes auto-montages NFS, quel que soit le VLAN sur lequel se trouve le client (les serveurs NFS sont multi-homés, une patte sur chaque VLAN). J'avais pensé spontanément au vues pour résoudre ce problème, mais en re-potassant la doc de bind pour résoudre mon problème de tranfert de zone des vues, je suis tombé sur le classement d'adresses avec la directive "sortlist"...
Au final, je m'en suis sorti à coups de sortlist et de rrset-order et ca marche comme je le souhaite (c'est même plus simple à maintenir puisque je n'ai pas toutes mes zones à maintenir en parallèle pour chaque vue !)
-- Rico
Pascal Hambourg a écrit :
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle
vue) ?
l'esclave voit la vue par défaut
On peut différencier les vues en jouant sur l'adresse source de la
requête de transfert de zone (option "transfer-source" de la zone
esclave). Ça implique que l'esclave ait une adresse correspondant à
chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître
recevant la requête de transfert (option "masters" de la zone esclave).
c'est une bonne idée. Mais je crois que j'ai trouvé une autre
alternative plus élégante...
En fait, le problème à résoudre est de fournir une vue unifiée pour mes
auto-montages NFS, quel que soit le VLAN sur lequel se trouve le client
(les serveurs NFS sont multi-homés, une patte sur chaque VLAN).
J'avais pensé spontanément au vues pour résoudre ce problème, mais en
re-potassant la doc de bind pour résoudre mon problème de tranfert de
zone des vues, je suis tombé sur le classement d'adresses avec la
directive "sortlist"...
Au final, je m'en suis sorti à coups de sortlist et de rrset-order et ca
marche comme je le souhaite (c'est même plus simple à maintenir puisque
je n'ai pas toutes mes zones à maintenir en parallèle pour chaque vue !)
Quelle est la vue de la zone transférée (en gros l'esclave voit quelle vue) ?
l'esclave voit la vue par défaut
On peut différencier les vues en jouant sur l'adresse source de la requête de transfert de zone (option "transfer-source" de la zone esclave). Ça implique que l'esclave ait une adresse correspondant à chaque vue. Ou on peut jouer sur l'adresse destination du serveur maître recevant la requête de transfert (option "masters" de la zone esclave).
c'est une bonne idée. Mais je crois que j'ai trouvé une autre alternative plus élégante...
En fait, le problème à résoudre est de fournir une vue unifiée pour mes auto-montages NFS, quel que soit le VLAN sur lequel se trouve le client (les serveurs NFS sont multi-homés, une patte sur chaque VLAN). J'avais pensé spontanément au vues pour résoudre ce problème, mais en re-potassant la doc de bind pour résoudre mon problème de tranfert de zone des vues, je suis tombé sur le classement d'adresses avec la directive "sortlist"...
Au final, je m'en suis sorti à coups de sortlist et de rrset-order et ca marche comme je le souhaite (c'est même plus simple à maintenir puisque je n'ai pas toutes mes zones à maintenir en parallèle pour chaque vue !)
