(bind9) Serveur DNS innaccessible

Je ne sais plus où chercher, j’ai tellement essayé de solutions que je ne sais même plus quels bouts étaient fonctionnels.
Donc je vais poser un état des lieux (pelle-mele tout le contenu obtenu juste après le redémarrage), mes connaissances en administration système et réseau atteignant leurs limites, je m’en remet à vous pour me souligner ce que j’ai sans doute foiré et me renseigner quelques pistes plus précise à explorer, car je ne sais plus ou donner de la tête.

Effets du problème :
J’ai une (vielle) machine qui me sert de serveur (Debian Squeeze) derrière une BBox. Mon serveur DNS ne semble pas répondre. Pourtant depuis l’extérieur, tous les autres services (irc, ssh, web) sont accessibles depuis mon adresse IP publique (donc aucun problème depuis les règles NAT de ma box).

J’ai noté quelques pistes (sérieuses ?) :
-Le syslog nous indique qu’au démarrage NetworkManager attribut différentes valeurs par défaut (hostname ‘Host-001’ nameserver ‘192.168.1.254’ domain name ‘lan’)[Vers la ligne 103], il faudrait sans doute modifier ce comportement pour que mes conf ne rentre pas en conflit (?)
-Beaucoup de “permission denied” avec les fichiers de log et le rndc de BIND

Voici les éléments de configuration générale :

Adresses:
89.0.0.209 > IP Publique
192.168.1.1 > IP Locale serveur
192.168.1.254 > Gateway BBox
AEServer > Nom serveur

$ uname -a Linux AEServer 2.6.32-5-686 #1 SMP Mon Sep 23 23:00:18 UTC 2013 i686 GNU/Linux

/var/log/syslog

/etc/hosts

[code]127.0.0.1 localhost localhost.localdomain
127.0.1.1 AEServer
192.168.1.1 mon-domaine.tk

The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters[/code]

Ce fichier est généré a chaque démarrage

etc/resolv.conf

# Generated by NetworkManager domain lan search lan nameserver 192.168.1.254
Mais il ne fonctionne pas

@AEServer:~$ dig mon-domaine.tk ;; connection timed out; no servers could be reached

Une fois modifié comme ceci

etc/resolv.conf

domain mon-domaine.tk search mon-domaine.tk nameserver 192.168.1.1
Mon serveur DNS réagit SEULEMENT depuis localhost.

[code]@AEServer:~$ dig mon-domaine.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27022
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;mon-domaine.tk. IN A

;; AUTHORITY SECTION:
mon-domaine.tk. 600 IN SOA mon-domaine.tk. aezaerth.mon-domaine.tk. 2014010101 1800 600 1800 600

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Jan 5 20:52:05 2014
;; MSG SIZE rcvd: 71[/code]

Voici la configuration de bind :

bind/named.conf.local

[code]// Gérer les fichiers de logs
include “/etc/bind/named.conf.log”;

// Gestion du domaine example.com
// ------------------------------
// - Le serveur est défini comme maître sur ce domaine
// - Il n’y a aucun forwarder pour ce domaine car nous avons la main mise dessus.
// Pour tous les autres domaines, nous utiliserons le forwarder mentionné dans named.conf.options
// - Les entrees sur le domaine peuvent être ajoutées dynamiquement avec le clef ns-example-com_rndc-key
zone “mon-domaine.tk” {
type master;
file “/etc/bind/mon-domaine.db”;
forwarders {};
allow-update { key mon-domaine_rndc-key; };
};
zone “1.168.192.in-addr.arpa” {
type master;
file “/etc/bind/mon-domaine.db.inv”;
forwarders {};
allow-update { key mon-domaine_rndc-key; };
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
include “/etc/bind/zones.rfc1918”;[/code]

bind/mon-domaine.db

[code]$TTL 30m
@ IN SOA mon-domaine.tk. aezaerth.mon-domaine.tk. (
2014010101 ; Serial
30m ; Refresh
10m ; Retry
30m ; Expire
10m ) ; Negative Cache TTL [10m]
;
@ IN NS ns01.mon-domaine.tk.
@ IN MX 10 ns01.mon-domaine.tk.

ns01 IN A 89.0.0.209

www IN CNAME ns01
irc IN CNAME ns01[/code]

bind/named.conf.default-zones

[code]// Gérer les acls
acl internals { 127.0.0.0/8; 192.168.1.1/24; };

// Charger les options
include “/etc/bind/named.conf.options”;

// Déclaration de la clef TSIG utilisée pour la mise à jour dynamique
include “/etc/bind/mon-domaine_rndc-key”;

// Configurer le canal de communication pour administrer BIND9 avec rndc
// Par défaut, la clef est située dans le fichier rndc.key et utilisée par
// rndc et bind9 sur localhost
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { “rndc-key”; };
};

// prime the server with knowledge of the root servers
zone “.” {
type hint;
file “/etc/bind/db.root”;
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone “localhost” {
type master;
file “/etc/bind/db.local”;
};
zone “127.in-addr.arpa” {
type master;
file “/etc/bind/db.127”;
};
zone “0.in-addr.arpa” {
type master;
file “/etc/bind/db.0”;
};
zone “255.in-addr.arpa” {
type master;
file “/etc/bind/db.255”;
};[/code]

bind/named.conf.options

[code]options {
directory “/etc/bind”;

    // Port d'échange entre les serveurs DNS
    query-source address * port *;

    // Transmettre les requêtes à 192.168.1.254 si ce serveur ne sait pas résoudre ces adresses.
    // On pourrait aussi bien renseigner les serveurs DNS du FAI plutôt que de renseigner
    // l'adresse IP du routeur (xxxbox)
    forward only;
    forwarders { 192.168.1.254; };

    auth-nxdomain no;    # conform to RFC1035

    // Ecouter sur les interfaces locales uniquement (IPV4)
    listen-on-v6 { none; };
    listen-on { 127.0.0.1; 192.168.1.1; 89.0.0.209; };

    // Ne pas transférer les informations de zones aux DNS secondaires
    allow-transfer { none; };

    // Accepter les requêtes pour le réseau interne uniquement
    allow-query { internals; 89.0.0.209; };

    // Autoriser les requêtes récursives pour les hôtes locaux
    allow-recursion { internals; };

    // Ne pas rendre publique la version de BIND
    version none;

};[/code]

Et enfin voici ce que donne l’état de mes connexions :

[code]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination[/code]

# netstat -uta -u UDP -t TCP Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp 0 0 *:6697 *:* LISTEN tcp 0 0 localhost:mysql *:* LISTEN tcp 0 0 *:ircd *:* LISTEN tcp 0 0 *:pop3 *:* LISTEN tcp 0 0 *:imap2 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:41876 *:* LISTEN tcp 0 0 mon-domaine.tk:7029 *:* LISTEN tcp 0 0 mon-domaine.tk:domain *:* LISTEN tcp 0 0 localhost:domain *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 localhost:ipp *:* LISTEN tcp 0 0 localhost:postgresql *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 localhost:953 *:* LISTEN tcp 0 0 *:imaps *:* LISTEN tcp 0 0 *:8067 *:* LISTEN tcp 0 0 mon-domaine.tk:7029 mon-domaine.tk:59755 ESTABLISHED tcp 0 0 mon-domaine.tk:59755 mon-domaine.tk:7029 ESTABLISHED tcp6 0 0 [::]:www [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN tcp6 0 0 ip6-localhost:ipp [::]:* LISTEN udp 0 0 mon-domaine.tk:domain *:* udp 0 0 localhost:domain *:* udp 0 0 *:bootpc *:* udp 0 0 *:50640 *:* udp 0 0 *:978 *:* udp 0 0 *:mdns *:* udp 0 0 *:sunrpc *:* udp 0 0 *:ipp *:* udp 0 0 localhost:58510 localhost:58510 ESTABLISHED udp 0 0 localhost:921 *:* udp 0 0 *:40486 *:* udp6 0 0 [::]:mdns [::]:* udp6 0 0 [::]:53497 [::]:*

Précisions :
Pour faire les tests depuis une autre machine (sous GNU/Linux) sur le réseau local j’ai modifié le fichier /etc/hosts en y ajoutant

Cependant, la commande dig ne trouve aucune correspondance.

Merci de votre patience !

Gérer l’interface réseau avec NetworkManager sur un serveur, il faut oser, surtout en DHCP, surtout un serveur DNS… Si tu tiens à NetworkManager, configure plutôt l’interface en statique avec les bons paramètres DNS et autres.

Messages “Permission denied” : ils concernent les fichiers de log dans /var/log. Vérifie dans /etc/default/bind9 sous quel utilisateur named se lance, par défaut c’est “bind” qui n’a pas les droits en écriture dans /var/log. Tu peux écrire les logs dans un sous-répertoire /var/log/bind auquel tu donnes les droits en écriture pour l’utilisateur “bind”.

BIND lui-même n’utilise pas le fichier /etc/hosts, la résolution DNS (par exemple avec dig) non plus. Si le serveur DNS gère la zone mon-domaine.tk, je déconseille de définir des noms d’hôtes en mon-domaine.tk dans /etc/hosts, cela n’apporte rien sauf un risque de conflit avec le contenu de la zone DNS.

Quand on teste un serveur DNS avec dig, on spécifie son adresse IP avec @adresse afin d’être sûr que la requête est envoyée au bon serveur.

Note : le fichier de zone n’a pas d’enregistrement d’adresse pour le nom mon-domaine.tk. Par conséquent ta requête a renvoyé 0 réponse (et une autorité, le SOA).

bind/named.conf.options :
Il n’y a pas lieu de mettre l’adresse IP publique dans l’option listen-on car cette adresse appartient à la box et non au serveur.

De même je ne vois pas l’intérêt de la mettre dans l’option allow-query : pourquoi des requêtes DNS parviendraient-elles de l’adresse externe de la box ? Si la zone mon-domaine.tk est publique, les requêtes pour cette zone doivent être acceptées depuis n’importe quelle adresse IP source.

La sortie de netstat serait plus claire avec l’option -n pour laisser les adresses et les ports sous forme numérique.

Bonjour,
Est-il vrai que bind9 n’utilise plus le fichier /etc/default/bind9 quant on le lance ?
J’ai modifié le paramètre OPTIONS pour ne pas avoir ipv6 mais cela ne marchait pas.

D’après le contenu du paquet, cela dépend de la façon dont BIND est lancé.
Le fichier est pris en compte dans le script d’init SysV traditionnel, mais pas dans l’unité de service de systemd.
Ma connaissance de systemd ne me permet pas de dire lequel de ces deux mécanismes a la priorité dans un système Debian avec systemd.

Sous systemd :

root@bind9:~# systemctl cat bind9
# /lib/systemd/system/bind9.service
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
EnvironmentFile=/etc/default/bind9
ExecStart=/usr/sbin/named -f $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

Il est donc toujours utilisé.
Ma question sous-entendait pourquoi faut-il faire plein de modifs dans plein de fichiers juste pour dire de ne pas utiliser ipv6 !

  • /etc/default/bind9
  • /etc/sysctl.conf
  • /lib/system/bind9.service

C’est à dire? Qu’est-ce que tu as fait comme modifications?

Qu’est ce que tu as modifié dans ce fichier?

Quelle distribution/version ? Le fichier /lib/systemd/system/bind9.service de Jessie est différent et ne fait pas référence à /etc/default/bind9 :

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

Autant pour moi c’est vrai j’ai pas pensé à ça :

root@bind9:~# apt-cache policy bind9
bind9:
  Installé : 1:9.10.3.dfsg.P4-12
  Candidat : 1:9.10.3.dfsg.P4-12
 Table de version :
 *** 1:9.10.3.dfsg.P4-12 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

sous Debian Sid :confused:

Voici les modif faites

/etc/default/bind9:
OPTIONS=”-4 –u bind”
/etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
/lib/systemd/system/bind9.service:
ExecStart=/usr/sbin/named -4 -f -u bind

apt-cache policy bind9 donne:

bind9:
  Installé : 1:9.9.5.dfsg-9+deb8u10
  Candidat : 1:9.9.5.dfsg-9+deb8u10
 Table de version :
 *** 1:9.9.5.dfsg-9+deb8u10 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:9.9.5.dfsg-9+deb8u8 0
        500 http://debian.ethz.ch/debian/ jessie/main amd64 Packages

uname -a:

Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux

Et malgré cela j’ai toujours des queries AAAA !

Ces manipulations désactivent l’utilisation d’IPv6 pour le transport, pas le traitement des requêtes DNS de type AAAA qui est juste un type d’enregistrement DNS comme un autre.