Aller au contenu

Views - bind

Dans le cas d'une infrastructure multi-sites, il est parfois intéressant d'utiliser les views des NS.

Pourquoi ?

Pour un même record DNS, il est possible d'avoir 2 ou plusieurs zones avec des pointages IPs différents, appelés en fonction de l'ip source.

Exemple

Image title
Schéma d'exemple

Ici, nous avons :

  • le premier site en production avec ces subnets :

    • 10.1.0.0/24
    • 10.1.1.0/24
    • 10.1.2.0/24

  • le second de secours avec ces subnets :

    • 10.2.0.0/24
    • 10.2.1.0/24
    • 10.2.2.0/24

Les utilisateurs, via leur VPN SSL se connectent depuis des subnets différents selon le site :

  • pour la production : 192.168.0.0/24
  • pour le secours : 192.168.1.0/24

Le point commun entre les 2 ?

Nous avons une contrainte : les pointages DNS doivent être identiques ! Peu importe l'origine de la demande (production ou secours)

Pour cela, bind permet de le faire via ses views (vues).

Mise en application

Nous avons l'environnement suivant :

  • 1 ns master sur la production (10.1.3.10 - ns1.dyndata.fr)
  • 1 ns slave sur la production (10.1.3.2 - n2.dyndata.fr)
  • 2 ns slave sur le secours (10.10.3.10 et 10.10.3.20 - ns3.dyndata.fr et ns4.dyndata.fr)

Configuration du master

/etc/bind/named.conf :

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

/etc/bind/named.conf.local :

view "infra_prod" {
    match-clients {192.168.0.0/24; }; # le subnet vpn ssl production
    zone "dyndata" {
    type secondary;
    masters { 10.1.3.10; }; # le ns master
      file "/etc/bind/zones/db.dyndataprod";
    };

view "infra_secours" {
    match-clients {192.168.1.0/24; }; # le subnet vpn ssl secours
    zone "dyndata" {
    type secondary;
    masters { 10.1.3.10; }; # le ns master
      file "/etc/bind/zones/db.dyndatasecours";
    };

La zone /etc/bind/zones/db.dyndataprod :

$TTL    604800
@       IN      SOA     dyndata. admin.dyndata.fr. (
                             1702464222
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

; name servers - NS records
    IN      NS      ns1.dyndata.fr.
    IN      NS      ns2.dyndata.fr.
    IN      NS      ns3.dyndata.fr.
    IN      NS      ns4.dyndata.fr.

; name servers - A records
ns1.dyndata.fr.        IN      A       10.1.3.10
ns2.dyndata.fr.        IN      A       10.1.3.20
ns3.dyndata.fr.        IN      A       10.10.3.10
ns4.dyndata.fr.        IN      A       10.10.3.20

smtp.dyndata.fr.        IN       A       10.1.0.10
web.dyndata.fr        IN       A       10.1.1.10
mysql.dyndata.fr        IN      A       10.1.2.10

La zone /etc/bind/zones/db.dyndatasecours :

$TTL    604800
@       IN      SOA     dyndata. admin.dyndata.fr. (
                             1702464222
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

; name servers - NS records
    IN      NS      ns1.dyndata.fr.
    IN      NS      ns2.dyndata.fr.
    IN      NS      ns3.dyndata.fr.
    IN      NS      ns4.dyndata.fr.

; name servers - A records
ns1.dyndata.fr.        IN      A       10.1.3.10
ns2.dyndata.fr.        IN      A       10.1.3.20
ns3.dyndata.fr.        IN      A       10.10.3.10
ns4.dyndata.fr.        IN      A       10.10.3.20

smtp.dyndata.fr.        IN       A       10.2.0.10
web.dyndata.fr        IN       A       10.2.1.10
mysql.dyndata.fr        IN      A       10.2.2.10

La configuration sera synchronisée sur les slaves, si le bind est correctement configuré.

Conséquence

Si j'ai l'IP 192.168.0.10 et que je réalise une résolution DNS :

# host web.dyndata.fr
10.1.1.10

Si j'ai l'IP 192.168.1.10 et que je réalise une résolution DNS :

# host web.dyndata.fr
10.2.1.10

J'ai un même record (web.dyndata.fr) qui pointe sur 2 IPs, bind me répond en fonction de ma propre ip source. Nous avons pris l'exemple d'une ip source du vpn SSL d'un utilisateur, mais cela s'applique aussi pour les services sur l'infrastructure. Il suffit d'adapter le "match-clients".