Forum Clubic

Dynamic DNS - sur plusieurs zones DNS différentes

Bonjour,
je rencontre des difficultés dans la mise en place de mon architecture utilisant DynamicDNS.

Je possède deux serveur et des clients dans deux réseau différents :

Un réseau en 10.7.0.0/24 qui correspond à une zone que je nome fr.test.

Un réseau en 10.0.0.0/24 qui correspond à une zone que je nome ge.test.

Sur chaque réseau il y a une machine Linux Fedora core 4 faisant tourner des serveurs DNS (bind-9.3.1-4) et DHCP (dhcp-3.0.2-12). Chaque serveur DNS est maître sur la zone de son réseau ("ge.test." ou "fr.test.") ainsi que sur les zones reverse ("0.0.10.IN-ADDR.ARPA" ou "0.7.10.IN-ADDR.ARPA"). Les adresses IP des serveur DHCP/DNS sont 10.0.0.10 et 10.7.0.1

Mes clients appartiennent chacun à l’un des réseau “fr.test.” ou “ge.test.”, aussi on t il un fqdn de la forme “toto.fr.test.”, “toto.ge.test.” ou titi.fr.test.".

Je voudrais que la mobilité des clients soit totale. C’est à dire qu’un client puisse changer de réseau et donc d’adresse ip sans changer de FQDN et que par DynDNS les serveur DNS soient renseignés comme il convient.
Par exemple si “toto.ge.test.” sort du réseau 10.0.0.0/24 pour aller dans le réseau 10.7.0.0/24, il récupère une adresse ip (ex 10.7.0.200), puis le serveur DHCP renseigne la zone maître de “ge.test.” sur le serveur 10.0.0.10 et la zone reverse “0.7.10.IN-ADDR.ARPA” sur le serveur 10.7.0.1 .

Comme l’enregistrement dans la zone reverse de la machine est toujours locale, cela ne semble pas poser de problème. Par contre l’enregistrement dans la zone forward ne marche pas correctement : la machine est toujours enregistrée dans la zone définie par “ddns-domainname” dans /etc/dhcpd.conf et non pas dans la zone déduite de son fqdn. Si je supprime la ligne ddns-domainname, dhcpd prend “option domain-name” à la place. Si je supprime aussi “option domain-name” alors le dyndns ne marche plus du tout.
Quel mécanisme ou quelle configuration n’ais je pas assimilé qui permettrais d’obtenir une complète mobilité ?

Voici ma configuration :

Zone ge.test.
fichier dhcpd.conf :


ddns-update-style interim;
authoritative;
default-lease-time 60;
max-lease-time 60;
one-lease-per-client on;

subnet 10.0.0.0 netmask 255.255.255.0 {
	range dynamic-bootp 10.0.0.128 10.0.0.200;
	option routers 10.0.0.10;
	option domain-name-servers 10.0.0.10;
	option domain-name "ge.test";

#	DynDNS
	ignore-client-updates;
	ddns-updates on;
	ddns-ttl 180;
	ddns-domainname "ge.test";
	ddns-rev-domainname "in-addr.arpa";
}

 

fichier named.conf :


options {
	query-source address 10.0.0.10 port 53;
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
};
zone "fr.test." IN {
	type forward;
	forwarders { 10.7.0.11; };
};
zone "0.0.10.IN-ADDR.ARPA." IN {
	allow-update { 10.0.0.10; };
	type master;
	file "10.0.0.db";
};
zone "ge.test." IN {
	allow-update {10.0.0.10; 10.7.2.1;};
	type master;
	file "ge.test.db";
};
 

Zone fr.test.
fichier dhcpd.conf :


ddns-update-style interim;
authoritative;
default-lease-time 60;
max-lease-time 60;
one-lease-per-client on;

subnet 10.7.0.0 netmask 255.255.255.0 {
	range dynamic-bootp 10.7.0.128 10.7.0.200;
	option routers 10.7.0.1;
	option domain-name-servers 10.7.0.1;
	option domain-name "fr.test";

#	DynDNS
	ignore-client-updates;
	ddns-updates on;
	ddns-ttl 180;
	ddns-domainname "fr.test";
	ddns-rev-domainname "in-addr.arpa";
}
 

fichier named.conf :


options {
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
};
zone "ge.test." IN {
	type forward;
	forwarders { 10.0.0.10 port 53; };
};
zone "0.7.10.IN-ADDR.ARPA." IN {
	allow-update {10.7.0.1;};
	type master;
	file "10.7.0.rev";
};
zone "fr.test" IN {
	allow-update {10.7.0.1;};
	type master;
	file "fr.test.zone";
};

zone "1.7.10.in-addr.arpa" IN {
	type master;
	file "10.7.1.rev";
};

zone "2.7.10.in-addr.arpa" IN {
	type master;
	file "10.7.2.rev";
};
 

fichier /etc/dhcclient.conf :


send host-name "clientdell.ge.test.";
send fqdn.fqdn "clientdell.ge.test.";
send fqdn.encoded on;
send fqdn.server-update on;
 

Voilà j’ai trouvé le problème il faut dans dhcpd.conf :

	ddns-domainname = pick (option domain-name);

et dans dhclient.conf

send domain-name "fr.test.";

:ouch: c’est a croire que tu cherche le problème ultra spécifique :paf:

j’ai jamais réussi a faire marcher ddns aprés le premier essai sur redhat 9…
ta pas eu de soucis avec la clé rndc ?

Salut, non je n’ai pas implémenté la sécurité pour le moment. On verra les rndc key plus tard.
Sinon ça marche bien avec des clients Linux, mais pas avec des clients Windows. En effet, le clients DHCP de M$ n’envoient par défaut que le FQDN, impossible de leur spécifier d’envoyer le Domain-name (option 15 voir RFC 2132) comme le fait très bien le client dhcp de linux. Ou alors je trouve pas la clé de registre à changer puisque que chez M$ la documentation c’est souvent très léger.

j’ai pas vu cette question a l’epoque (ni la resolution d’ailleurs) et c’est tres tres tres interessant.
C’est le genre de choses que je commence a avoir envie de coller dans mon reseau et c’est bien agreable de voir une telle qualite dans la question et la solution.

Pour ceux que ça interesse, je crois que je suis arrivé proche d’une solution pour les clients Linux et Windows.
Je laisse maintenant tomber l’option 15 (domain name) pour l’option 81 (FQDN), qui n’est pas encore officialisée par une RFC et reste un élément du projet RFC Internet “Interaction between DHCP and DNS”, en cours de révision par le groupe de travail IETF pour DHCP (ça pourait évoluer en septembre). Mais bon visiblement tout le monde l’implémente déjà.

Voici donc la configuration du dhcp-client.conf sous Linux :

send fqdn.fqdn "clientdell.fr.cit.";
send fqdn.encoded off;
send fqdn.server-update on;
send fqdn.no-client-update on;

Sous Windows XP ça se configure dans « propriété de la connexion au réseau local > propriété du protocole internet > avancé ». Il faut inscrire le nom de domaine dans le champ « Suffixe pour cette connexion » et cocher les cases « Enregistrer les adresses de cette connexion dans le système DNS » et « Utiliser le suffixe DNS de cette connexion pour l’enregistrement DNS ».
Le FQDN envoyé par Windows sera la concaténation du nom de l’ordinateur (onglet “Nom de l’ordinateur” dans le module système du panneau de configuration) et du suffixe pour la connexion.

Maintenant la configuration du dhcpd.conf du serveur DHCP :

ddns-update-style interim;
authoritative;
default-lease-time 60;
max-lease-time 60;
one-lease-per-client on;

subnet 10.7.0.0 netmask 255.255.255.0 {
range dynamic-bootp 10.7.0.128 10.7.0.200;
option routers 10.7.0.1;
option domain-name-servers 10.7.0.1;
option domain-name "fr.test";

# DynDNS
ignore-client-updates;
ddns-updates on;
ddns-ttl 180;
ddns-hostname = option fqdn.hostname;
ddns-domainname = option fqdn.domainname;
ddns-rev-domainname "in-addr.arpa";
}

Seul bémol, avec cette configuration le client Windows tente de mettre à jour lui même le serveur DNS ce qui, s’il y arrive, peut provoquer un conflit avec la mise à jour par le serveur DHCP. Il faut donc bien veiller à ce que le serveur DNS n’accepte les mise à jour que de la part des éléments de réseau autorisés.
Si quelqu’un trouve le moyen de forcer Windows à envoyer son FQDN dans la requete DHCP sans pour autant éffectuer derrière une requete DNS Update, je suis interessé par la solution. C’est pas grave en soit mais ça fait pas très clean, c’est vrai…

Calment