Configuration Dynamic DNS + DHCP

Support Debian
,
Tags: #<Tag:0x00007f63f37c3f18> #<Tag:0x00007f63f37c3db0>
#1

Bonjour à tous,

Après avoir passé des heures sur le problème, impossible de le résoudre.
Je suis sous Jessie 8.11.
J’ai configuré sur la même machine un DHCP et un Serveur Dynamic-DNS, avec clé rndc.
Le serveur DHCP et le serveur DNS en tant que tels fonctionnent, mais la mis à jour des enregistrement ne fonctionne pas.
J’ai sans cesse le message suivant (en surveillant avec la commande “tail”):

Dec 15 12:34:48 skynet dhcpd: Unable to add forward map from t800.cyberdyne.local to 10.1.2.20: timed out

Est-ce que quelqu’un a une idée, sachant que j’ai essayé les solutions suivantes:

  • Mettre les droits en écriture du dossier /var/cache/bind
  • Changement de propriétaire du même dossier au groupe ‘bind’

Mon fichier de configuration dhcpd.conf:

#DNS
authoritative;
ddns-updates on;
ddns-update-style interim;
ignore client-updates;
update-static-leases on;
allow-unknown-clients;
default-lease-time 21600;
max-lease-time 7200;
option domain-name "cyberdyne.local";
option domain-name-servers 10.1.2.250;
include "/etc/bind/rndc.key";


#log DHCP
log-facility local7;

zone cyberdyne.local. {
        primary 10.1.2.250;
        key rndc-key;
}

zone 2.1.10.in-addr.arpa. {
        primary 10.1.2.250;
        key rndc-key;
}

#Etendue 1
subnet 10.1.2.0 netmask 255.255.255.0 {
        range 10.1.2.20 10.1.2.50;
        option routers 10.1.2.254;
        option broadcast-address 10.1.2.255;
}

Mon fichier de configuration de zones named.conf.local:

// Gérer les fichiers de logs
include "/etc/bind/named.conf.log";

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

include "/etc/bind/rndc.key";

controls {
        inet 127.0.0.1 port 953
        allow { 127.0.0.1;} keys {"rndc-key";};
};

zone "cyberdyne.local" {
        type master;
        allow-update { key "rndc.key"; };
        allow-query { any; };
        notify yes;
        file "/var/cache/bind/db.cyberdyne.local";
        forwarders{};
};

zone "2.1.10.in-addr.arpa" {
        type master;
        allow-update { key "rndc.key"; };
        allow-query { any; };
        notify yes;
        file "/var/cache/bind/db.cyberdyne.local.inv";
        forwarders{};
};

Voilà !
Si quelqu’un a une idée, ce serait vraiment cool car je ne m’en sors pas…

Bonne journée,

Flitox

#2

Bonjour,

Je voudrais savoir si tes deux services DHCP et DNS sont sur la même machine (hôte). Si c’est le cas il faudrait corriger tes lignes :

zone cyberdyne.local. {
        primary 10.1.2.250;
        key rndc-key;
}

zone 2.1.10.in-addr.arpa. {
        primary 10.1.2.250;
        key rndc-key;
}

en

zone cyberdyne.local. {
        primary 127.0.0.1;
        key rndc-key;
}

zone 2.1.10.in-addr.arpa. {
        primary 127.0.0.1;
        key rndc-key;
}
#3

Bonjour,

Oui ils sont sur la même machine.
J’ai en effet essayé aussi de mettre l’adresse de loopback et j’ai le même résultat…
J’ai même refait à l’instant le serveur, sans intégrer la notion de clé rndc, donc juste pour faire les mises à jour des enregistrements dans les zones, et j’ai encore la même erreur… Je ne comprends pas…
Je me pose la question du port 953, faut-il qu’il soit à l’écoute même si on ne se sert pas de la clé rndc ? car dans les deux cas en faisant un netstat -an, je ne le vois pas à l’écoute…

#4

Ok donc il a sûrement un problème avec ton serveur bind9. Vérifie bien qu’il est bien lancé ! Et chez moi ma ligne est :

controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { rndc-key; };
};

Je n’ai pas spécifié le port vue qu’il est déjà 953 par défaut.

#5

Arrête de te prendre la tête avec un serveur beugué et utilise dnsmasq, ça va te changer la vie.
Si tu as besoin d’aide, c’est avec un grand plaisir que je pourrais t’aider.

#6

Bonjour,
J’ai lu un petit peu ce que fait dnsmasq, ça a l’air pas mal en effet.
Même si j’ai finalement réussi à faire fonctionner mon infrastructure, je suis ouvert au changement et je veux bien que tu me dises comment ça fonctionne.
Ce qui m’intéresse c’est le côté dynamique du dns.

#7

Si tu as réussi à résoudre le problème ce serait sympa d’expliquer comment et ce qui n’allait pas.

D’autre part je signale qu’utiliser le domaine .local est une très mauvaise idée car ce domaine est réservé à mDNS (multicast DNS), un protocole de résolution de nom concurrent de DNS. Ne t’étonne donc pas si la résolution ne fonctionne pas, le système essayant de la faire via mDNS au lieu de DNS.

#8

Bonjour Pascal,

Ayant répondu tôt ce matin au réveil, je n’ai pas pris le temps d’expliquer ce que j’ai fait pour résoudre mon problème, mais j’allais bien sur le faire.
J’ai tout simplement remplacé l’adresse ip 10.1.2.250 par l’adresse de bouclage 127.0…0.1 dans la commande allow-update.
Par ailleurs, je ne savais pas du tout que le tld “.local” était utilisé par autre chose… Je le saurai…

#9

Comment ça ? Il n’y avait pas d’adresse 10.1.2.250 dans les options allow-update de ton message initial :

#10

J’avais mis par la suite l’adresse 10.1.2.250, ca ne fonctionnait pas.
Quand j’ai ensuite mis l’adresse de loopback, ca a fonctionné.