Les vues DNS pour fluidifier la gestion de vos applications
Par Nicolas Steinmetz. vendredi 6 novembre 2009, 00:18. Intégration bind dns mutualisation répartition vue | Lien permanent.
Contexte / Objectifs
Imaginer :
- Vous êtes dans un grosse PME multi-sites ou avec un hébergement multi-sites
- Un applicatif est soit réparti sur chaque site, soit il est porté globalement en multi-site (ex un serveur de mail, une application web, etc)
- Votre but est de minimiser la gestion de ces équipements tout en gardant une homogénéité au niveau de la conf (tout le monde utilise par ex mail.maboite.tld pour accéder au webmail mais cela pointe en fait sur chaque serveur de mail local).
Deux modes de gestion :
- Au niveau de chaque site, vous avez la solution de déployer un serveur DNS qui gère les entrées correspondantes et faire ainsi la gestion de N dns lors de la modification d'une entrée.
- Vous utilisez les vues DNS et vous déployez un serveur maitre et les vues se transmettront aux esclaves par simple transfert de zone.
Mais au fait, c'est quoi une vue DNS ???
Kezako une vue DNS ?
Pour un serveur DNS donné, celui-ci peut répondre des informations différentes suivant le client ou bien l'IP du serveur DNS utilisée pour faire sa requête.
Dans le cas de mon webmail :
- Suppsons que la répartition entre le site A et le site B se fasse par round robin
- le client arrive sur un Reverse Proxy (RP) qui le dispatche ensuite parmi plusieurs frontaux
- Quand un client arrive sur le site A, le RP doit renvoyer sur les frontaux 10.8.0.102 à 10.8.0.104
- Quand un client arrive sur le site B, le RP doit renvoyer sur les frontaux 10.9.0.102 à 10.9.0.104
Construisons une petite matrice de flux :
| Vue Site A | Vue Site B | |
| Frontaux Site A | X | |
| Frontaux Site B | X | |
| RP Site A | X | |
| RP Site B | X | |
| Transfert de zone | X | X |
Equipements
Soit 5 serveurs ayant les rôles suivants :
- srv101 / 10.8.0.1 : RP + DNS Master site A
- srv102 / 10.8.0.102 : Serveur Mail Site A 1
- srv103 / 10.8.0.103 : Serveur Mail Site A 2
- srv104 / 10.8.0.104 : Serveur Mail Site A 3
- srv201 / 10.9.0.1 - 10.9.0.2 : RP + DNS Slave site B
- srv202 / 10.9.0.102 : Serveur Mail Site B 1
- srv203 / 10.9.0.103 : Serveur Mail Site B 2
- srv204 / 10.9.0.104 : Serveur Mail Site B 3
Mise en place de la configuration DNS
Note
- Le DNS ne doit plus écouter sur le port local
- Il ne doit pas y avoir de règle sur localhost
- Si localhost autorisé, alors localhost == 127.0.0.1 == IP1.DU.SERVEUR.FQDN == IP2.DU.SERVEUR.FQDN == ... => /etc/resolv.conf à renseigner avec l'IP locale sur lequel le serveur DNS écoute.
- Pour permettre le transfert de zone, le DNS slave doit se synchroniser avec le serveur maitre en faisant des requêtes sur 2 ip distinctes pour voir les 2 vues :
- Si le DNS slave interroge le DNS maitre avec son IP principale (10.9.0.1), alors il obtient la vue du site B
- Si le DNS slave interroge le DNS maitre avec son IP secondaire (10.9.0.2), alors il obtient la vue du site A
- Mise en place du transfert sur le DNS slave :
- Installer Bind
- Mettre en place le fichier named.conf
- Lancez bind, il récupère alors les fichiers de zone automatiquement du serveur maitre
Conf DNS Master
Contenu de /etc/named.conf
acl "trusted" {
localhost;
10.0.0.0/8;
};
options {
directory "/var/named";
listen-on {
10.8.0.1;
};
auth-nxdomain no;
allow-query { trusted; };
allow-recursion { trusted; };
};
# Define ACL for views
acl "frontaux_siteb" {
10.9.0.102;
10.9.0.103;
10.9.0.104;
};
acl "frontaux_sitea" {
10.8.0.102;
10.8.0.103;
10.8.0.104;
};
acl "rpdns_sitea" {
10.8.0.1;
};
acl "rpdns_siteb" {
10.9.0.1;
};
acl "rpdns_siteb_ext" {
10.9.0.2;
};
# Views definitions
view "site_a" {
match-clients { frontaux_sitea; rpdns_sitea; };
# Vue locale
zone "domaine.tld" IN {
type master;
file "sitea.domaine.tld.zone";
allow-update { none; };
allow-transfer { 10.9.0.2; };
notify yes;
};
};
view "dns_slave" {
match-clients { rpdns_siteb_ext; };
# Vue locale
zone "domain.tld" IN {
type master;
file "siteb.domaine.tld.zone";
allow-update { none; };
allow-transfer { 10.9.0.2; };
notify yes;
};
};
view "site_b" {
match-clients { frontaux_siteb; rpdns_siteb; };
# Vue locale
zone "cyclo.priv" IN {
type master;
file "pla.cyclo.priv.zone";
allow-update { none; };
allow-transfer { 10.9.0.1; };
notify yes;
};
};
Conf DNS Slave
acl "trusted" {
localhost;
10.0.0.0/8;
};
options {
directory "/var/named";
listen-on {
10.8.0.1;
};
auth-nxdomain no;
allow-query { trusted; };
allow-recursion { trusted; };
};
# Define ACL for views
acl "frontaux_siteb" {
10.9.0.102;
10.9.0.103;
10.9.0.104;
};
acl "frontaux_sitea" {
10.8.0.102;
10.8.0.103;
10.8.0.104;
};
acl "rpdns_sitea" {
10.8.0.1;
};
acl "rpdns_siteb" {
10.9.0.1;
};
acl "rpdns_siteb_ext" {
10.9.0.2;
};
# Views definitions
view "site_a" {
match-clients { frontaux_sitea; rpdns_sitea; };
# Vue locale
zone "domaine.tld" IN {
type slave;
file "sitea.domaine.tld.zone";
masters { 10.8.0.1; };
transfer-source 10.9.0.2;
};
};
view "dns_slave" {
match-clients { rpdns_siteb_ext; };
# Vue locale
zone "domain.tld" IN {
type slave;
file "sitea.domaine.tld.zone";
masters { 10.8.0.1; };
transfer-source 10.9.0.1;
};
};
view "site_b" {
match-clients { frontaux_siteb; rpdns_siteb; };
# Vue locale
zone "cyclo.priv" IN {
type slave;
file "siteb.domaine.tld.zone";
masters { 10.8.0.1; };
transfer-source 10.9.0.1;
};
};
Conf Zone sitea.domaine.tld.zone
$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
2009100101
3600
3600
3600
3600 )
@ IN NS domaine.tld.
dns IN A 10.8.0.1
www2 IN A 10.8.0.102
www2 IN A 10.8.0.103
www2 IN A 10.8.0.104
webmail IN CNAME www2
Conf Zone siteb.domaine.tld.zone
$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
2009100101
3600
3600
3600
3600 )
@ IN NS domaine.tld.
dns IN A 10.8.0.1
www2 IN A 10.9.0.102
www2 IN A 10.9.0.103
www2 IN A 10.9.0.104
webmail IN CNAME www2
Conf OS
/etc/resolv.conf
Serveurs du site A :
search domaine.tld nameserver 10.8.0.1
Serveurs du site B :
search domaine.tld nameserver 10.9.0.1
Tests
Depuis le site A
La commande dig @10.8.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.8.0.x
Depuis le site B
La commande dig @10.9.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.9.0.x
Transfer de zone
Lorsque vous démarrez le DNS esclave, il doit récupérer automatiquement les deux fichiers de zone avec un contenu identique à celui décrit plus haut.
Sources
Pour conclure...
J'espère que c'est pas trop confus et que cela vous aura donner des idées.
Dans mon cas, j'utilise ça avec en plus une zone privée :
- les internautes arrivent de l'extérieur avec une url publique
- ils transitent sur le réseau interne via des urls privées