Délégation et gestion des sous-domaines avec Bind9 [WikiElosys]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" aria-hidden="true" focusable="false" width="1em" height="1em" preserveAspectRatio="xMidYMid meet" viewBox="0 0 24 24" class="iconify mr-1" data-icon="mdi:arrow-left" style="vertical-align: -0.125em; transform: rotate(360deg);"><path d="M20 11v2H8l5.5 5.5l-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5L8 11h12z" fill="currentColor"></path></svg>{{tag> dns bind subdomains}}

===== Délégation et gestion des sous-domaines avec Bind9 =====

Il est possible de déléguer la gestion d'un sous domaine à des serveurs DNS auto hébergés.

Sur l'interface [[https://www.amen.fr/|Amen]] par exemple, il faudra créer **au minimum** 3 enregistrements.

  * On assigne le sous-domaine lui-même à **un** enregistrement de **type A**
  * On attribue à ce sous-domaine  **deux** enregistrements **NS** (name server).

Les deux enregistrements NS pointent vers des serveurs Bind que nous gérons nous-mêmes.

<code csv>
"NOM"                            "TTL" "TYPE"  "VALEUR"
"ns1.example.net."               900   "A"     "41.42.43.81"
"ns2.example.net."               900   "A"     "51.52.53.81"

"bobo.example.net."              900   "A"     "31.32.33.81"
"bobo.example.net."              900   "NS"    "ns1.example.net."
"bobo.example.net."              900   "NS"    "ns2.example.net."
</code>

Les serveurs DNS fonctionnent en maître-esclave, c'est le minimum requis pour qu'une délégation soit possible.

==== Sur le serveur maître ====

<code c /etc/bind/named.conf.options>
options {
        directory "/var/cache/bind";
        querylog yes;
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035

        listen-on {
             127.0.0.1;
             41.42.43.81;    # l'adresse publique du serveur courant (maître)
        };

        allow-transfer {
             51.52.53.81;    # l'adresse publique du serveur esclave
        };
};
</code>

<code c /etc/bind/named.conf.local>
// Enregistrement de résolution DIRECTE (hostname --> IP)
zone "bobo.example.net" IN {
     type master;
     file "/etc/bind/zones/bobo.example.net";
     notify yes;
     check-names warn;
     allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave
};

// Enregistrements de résolution INVERSES (PTR)
zone "43.42.41.in-addr.arpa" {
        type master;
        file "/etc/bind/zones/ns1.example.net.rev";
        notify yes;
        allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave
};

zone "53.52.51.in-addr.arpa" {
        type master;
        file "/etc/bind/zones/ns2.example.net.rev";
        notify yes;
        allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave
};
</code>

<code c /etc/bind/zones/bobo.example.net>
$ORIGIN .
$TTL 3600       ; 1 hour
bobo.example.net         IN SOA  ns1.example.net. admin.ns1.example.net. (
                                201        ; serial
                                600        ; refresh (10 minutes)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )

        IN              NS      ns1.example.net.
        IN              NS      ns2.example.net.
        IN              A       31.32.33.81

$ORIGIN bobo.example.net.

ns1                     A       41.42.43.81
ns2                     A       51.52.53.81
*                       CNAME   bobo.example.net.
</code>

<code c /etc/bind/zones/ns1.example.net.rev>
$TTL    3600
43.42.41.in-addr.arpa.        IN SOA        ns1.example.net. admin.ns1.example.net. (
                              106          ; Serial
                              1h           ; Refresh [1h]
                              10m          ; Retry   [10m]
                              1d           ; Expire  [1d]
                              10m)         ; Negative Cache TTL [10m]

; Name Server
43.42.41.in-addr.arpa.        IN      NS       ns1.example.net.

; PTR Records
81.43.42.41.in-addr.arpa.     IN      PTR      ns1.example.net.
</code>

<code c /etc/bind/zones/ns2.example.net.rev>
$TTL    3600
53.52.51.in-addr.arpa.        IN SOA        ns2.example.net. admin.ns2.example.net. (
                              106          ; Serial
                              1h           ; Refresh [1h]
                              10m          ; Retry   [10m]
                              1d           ; Expire  [1d]
                              10m)         ; Negative Cache TTL [10m]

; Name Server
53.52.51.in-addr.arpa.        IN      NS       ns2.example.net.

; PTR Records
81.53.52.51.in-addr.arpa.     IN      PTR      ns2.example.net.
</code>

Si nous optons pour faire tourner Bind dans docker, voici le ''docker-compose.yml'' nécessaire :

<code yaml docker-compose.yml>
version: '3.4'

services:
  bind:
    network_mode: host
    restart: always
    image: sameersbn/bind:latest
    container_name: bind
    environment:
      - WEBMIN_ENABLED=false
    volumes:
      - ./bind:/data
</code>

<WRAP round info>

Il faut veiller à utiliser ''network_mode: host''

L'image docker ''internetsystemsconsortium/bind9:9.18'' est également à considérer car produite par l'[[https://www.isc.org/|Internet Systems Consortium]] responsable du développement de Bind9.

</WRAP>

==== Sur le serveur esclave ====

La configuration sur le serveur esclave est un miroir de la configuration du serveur maître avec quelques différences importantes.

D'abord nous allons tester  que le serveur maître répond aux requêtes de transfert de zone. C'est le mécanisme par lequel le serveur esclave duplique automatiquement les configurations du maître.

Sur un terminal ((
veiller à exécuter cette commande sur le serveur esclave, seul autorisé à émettre une requête de transfert de zones (voir l'instruction ''allow-transfer'' du fichier ''named.conf.options'' sur le serveur maître)
)) exécuter la commande suivante (remplacer l'ip du serveur maître)

<code bash>
dig @41.42.43.81 bobo.example.net. axfr
</code>

<code c /etc/bind/named.conf.options>
options {
        directory "/var/cache/bind";
        dnssec-validation auto;
        auth-nxdomain no;    /* # conform to RFC1035 */
        allow-query {
             127.0.0.1;
             41.42.43.81;
             51.52.53.81;
        };

        listen-on {
             127.0.0.1;
             51.52.53.81; // Adresse publique du serveur courant (esclave)
        };

        allow-transfer {
             41.42.43.81; // Adress publique du serveur maître
        };
};
</code>

<code c /etc/bind/named.conf.local>
zone "bobo.example.net" IN {
     type slave;
     file "/var/lib/bind/zones/bobo.example.net";
     masters { 41.42.43.81; }; // Adresse du serveur maître
};

zone "43.42.41.in-addr.arpa" {
        type slave;
        file "/var/lib/bind/zones/ns1.example.net.rev";
        masters { 41.42.43.81; }; // Adresse du serveur maître
};

zone "53.52.51.in-addr.arpa" {
        type slave;
        file "/var/lib/bind/zones/ns2.example.net.rev";
        masters { 41.42.43.81; }; // Adresse du serveur maître
};
</code>

La différence entre les fichiers ''named.conf.local'' sur les serveurs maître et esclave, c'est l'emplacement des fichiers de zones.

Si sur le maître, les fichiers peuvent se trouver dans le dossier ''/etc/bind'' comme

<code c>
zone "bobo.example.net" IN {
     type master;
     file "/etc/bind/zones/bobo.example.net"; ////////////// <--------- ICI
     notify yes;
     check-names warn;
     allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave
};
</code>

Ça ne peut être le cas sur le serveur esclave. Les fichiers doivent se trouver à un emplacements inscriptible par l'utilisateur bind. C'est pour cela que les fichier sont conservés dans le dossier ''/var/lib/bind'' comme ceci :

<code c>
zone "bobo.example.net" IN {
     type slave;
     file "/var/lib/bind/zones/bobo.example.net";
     masters { 41.42.43.81; }; // Adresse du serveur maître
};
</code>

Autrement, le transfert automatique de zone entre le maître et l'esclave va échouer en raison des autorisations d'écriture.

Les fichiers de zones sur le serveur esclave sont créés automatiquement par le transfert de zone. Il n'y a pas lieu de les créer manuellement.