Brouillons d'un g33k

Categories

01 Jan 0001, 00:00

Share

Orga générale

Plusieurs serveurs DNS racines gérés par différentes entités (Verisign, NASA, ICANN, universités américaines etc) https://www.iana.org/domains/root/servers

Un serveur DNS stocke en dur les IP de ces serveurs dans le fichier /usr/share/dns/root.hints (par défaut sous Debian en tout cas). C’est le début de la récursivité.

On ne peut interroger directement les serveur racines pour résoudre un nom de domaine. Ceux-ci vont simplement nous rediriger vers le serveur qui gère le TLD demandé.

Exemple : on demande au serveur racine A (IP : 198.41.0.4) de résoudre l’adresse “memo.raphaelguetta.fr” :
dig @198.41.0.4 memo.raphaelguetta.fr
Il nous répond simplement :
fr. 172800 IN NS f.ext.nic.fr.
soit “voici le serveur qui gère le .fr, va lui demander”.

On lui demande donc de résoudre, à nouveau :
dig @f.ext.nic.fr. memo.raphaelguetta.fr
et il nous répond :
raphaelguetta.fr. 3600 IN NS ns103.ovh.net.
soit “voici le serveur qui gère la zone DNS de raphaelguetta.fr, va lui demander”

On redemande donc :
dig @ns103.ovh.net. memo.raphaelguetta.fr
et on obtient enfin la réponse des serveurs OVH, qui sont effectivement ceux que j’utilise pour configurer mes (sous-)domaines :
memo.raphaelguetta.fr. 86400 IN A 82.64.166.200

Configuration

Config dans /etc/bind/.

Fichiers pré-remplis :
named.conf avec seulement includes
named.conf.options pour les options (attention, 1 seul groupe options { }; est autorisé, on ne peut pas le splitter dans différents fichiers)
named.conf.default-zones définit le fichier contenant les IP des serveurs racines (/usr/share/dns/root.hints) ; ainsi que les zones concernant localhost (DNS et rDNS)

Fichier pour une personnalisation du serveur :
named.conf.local
Par défaut, il est vide ; il set à définir des zones DNS custom.
Supposons que je souhaite définir, en local, un zone DNS sur le TLD .bidouille (qui n’existe pas officiellement) Je rentre dans ce fichier

zone "bidouille" {
        type master;
        file "/etc/bind/zones/db.bidouille";
};

Ainsi je définis que mon serveur DNS est “maître” (il fait autorité pour le TLD .bidouille, ce qui est nécessaire, car aucun autre serveur ne connaîtra ce TLD) Je définis que sa zone sera définie dans le fichier “/etc/bind/zones/db.bidouille”

Docker

version: '3'

services:

  bind9:
    image: internetsystemsconsortium/bind9:9.18
    restart: always
    container_name: bind9
    stdin_open: true
    tty: true
    ports:
      - 53:53/tcp
      - 53:53/udp
# For RNDC :
      - "127.0.0.1:953:953/tcp"
    volumes:
    volumes:
      - ./config/zones:/etc/bind/zones
      - ./config/named.conf.local:/etc/bind/named.conf.local
      - ./config/named.conf.options:/etc/bind/named.conf.options
      - ./cache/:/var/cache/bind/
      - ./lib/:/var/lib/bind/
      - ./log/:/var/log/

Connectivité des autres réseaux

Par défaut, bind n’accepte de répondre qu’aux requêtes qui proviennent du même hôte ou du même réseau.
Comme il esy dockerisé, il faut l’autoriser à résoudre depuis + de sources. Pour ceci, dans le bloc d’options, ajouter

Connectivité des autres conteneurs Docker

Si le serveur hôte s’utilise lui-même comme resolver dans /etc/resolv/conf, il faut qu’il s’appelle sur 127.0.0.1 ; s’il utilise son IP externe (par exemple 192.168.1.10 ), les conteneurs ne pourront probablement pas faire de résolution DNS.

Ceci semble venir du fait que les conteneurs récupèrent le resolveur interne de Docker (127.0.0.11), qui va lui-même récupérer les informations du resolv.conf de l’hôte. Et si il est défini en IP externe, cela ne fonctionne pas.

RNDC

Remote Name Daemon Control
port 953

Cache