Univention Bugzilla – Bug 24282
Enabling DDNS in dhclient.conf
Last modified: 2012-07-20 15:24:10 CEST
The DHCP configuration usually does not provide a ddns setup. The necessary configuration entries in /etc/dhcp3/dhclient.conf should look similar to this: send host-name "<hostname>"; send fqdn.fqdn "<hostname>.<domainname>"; send fqdn.server-update off; send fqdn.encoded on; These entries will try to set the forward and reverse entries in the zone files at the dns server. This assumes the dns server enables modification of the zone files by dhcp clients. As this feature is not required essentially it should be possible to enable it on demand. Therefor two UCRV should be implemented: 1. Enabling ddns (yes/no) - default: empty (means: no) 2. Set the fqdn-domainname explicitly - default: empty (means: domainname)
implemented in scope, used UCR variables: dhclient/options/ddns (yes, no): enable/disable DDNS, default: no (unset) dhclient/options/ddns/zone: overwrite DNS zone, if not set "domainname" is used
Created attachment 4054 [details] univention-network-manager_ddns.patch
Ich habe den patch eingebaut und einige Kleinigkeiten korrigiert: +univention-network-manager (3.0.14-1) unstable; urgency=low + + * Added UCRV to enable and handle DDNS in dhclient.conf (Bug: #24282) + This patch was written by Roman Asendorf and applied by Juergen Kahrs + while working on Bug #24282. + * Renamed path etc/dhcp3 in original patch to etc/dhcp to make it fit. + * conffiles/etc/dhcp/dhclient.conf: + Used configRegistry.is_true('dhclient/options/ddns', False) for reading. + * Updated version number of original patch from 1.1.0.1 to 3.0.14-1. + * Updated Copyright notes from 2011 to 2012 in dozens of files. + * debian/univention-ifplugd.univention-config-registry, + debian/univention-network-manager.univention-config-registry: + Added hostname and domainname to keep ucslint satisfied. Das neue Paket habe ich funktional getestet. ucr set dhclient/options/ddns=on Danach enthielt die Datei /etc/dhcp/dhclient.conf exakt die o.g. zusätzlichen Zeilen. Auch das separate Setzen der ddns/zone hat funktioniert. ucr set dhclient/options/ddns/zone=moin Dieser Wert wurde in die Datei /etc/dhcp/dhclient.conf übertragen. Auch das Abschalten von DDNS klappt. ucr set dhclient/options/ddns=on Danach sind die DDNS-Zeilen aus /etc/dhcp/dhclient.conf wieder entfernt. Die DDNS-Funktionalität konnte ich nicht mit einem DHCP-server testen, weil meine Umgebung nur mit statischen IP-Adressen arbeitet.
Korrektur zu meinem Kommentar: Das Abschalten von DDNS geht mit: ucr set dhclient/options/ddns=off
OK: ChangeLog svn13383 FAIL: univention-network-manager svn33463 Das ganze funktioniert soweit, allerdings ist noch eine kleine Anpassung notwendig: Nach dhcp-options(5) und dem "DHCP FQDN"-RFC <http://tools.ietf.org/html/rfc4702> gibt es prinzipiell zwei Modi: 1. Der Server aktualisiert sowohl den A-Record in der Forward-Zone als auch den PTR-Record in der Reverse-Zone. Hier kann dich der Client zwar einen Namen wünschen, allerdings liegt es letztendlich in der Hand des Servers, welchen Namen der Client bekommt. Auf Client-Seite wird das über "send fqdn.server-update on;" aktiviert. Auf Server-Seite wird das über "policies/dhcp_dnsupdate.clientUpdates=deny" erzwungen. Typischer Anwendungsfall sind hier Firmennotebooks, die dynamisch ihre IP-Adresse bekommen, aber alle in der selben Firmen-Domain beheimatet sind. 2. Der Server aktualisiert nur den PTR-Record in der Reverse-Zone, der Client aktualisiert seinen A-Record (irgendwie) selber. Hier kann der Client sich seinen eigenen Namen geben, der ggf. nichts mit der Domain des DHCP-Servers zu tun hat: Da der DHCP-Server keine Credentials für das Update der Client-Domain besitzt, kann das nur der Client selber machen. Auf Client-Seite wird das über "send fqdn.server-update off;" aktiviert. Auf Server-Seite muß das über "policies/dhcp_dnsupdate.clientUpdates=allow" ermöglicht werden. Typischer Anwendungsfall sind öffentliche Hotspots, wo der Gast-PC temporär eine öffentliche IP-Adresse bekommt, die er auf seinen Namen einträgt. Beide Modi werden comment #0 vermischt: Dort wird der Server per "send fqdn.server-update off;" angewiesen, den A-Record in der Forward-Zone _nicht_ zu aktualisieren, im Text wird aber davon gesprochen, daß "forward _and_ reverse" Einträge aktualisiert werden. Um beide Betriebsmodi zu ermöglichen sollte auch "fqdn.server-update" per UCR-Variable konfigurierbar sein. Vorschlag: [dhclient/options/ddns/serverupdate] Description[de]=Ersucht den DHCP-Server den A-Record in der Forward-Zone zu aktualisieren (Standard: yes) Description[en]=Request DHCP server to update the A record in the forward zone (default: yes) Type=bool Als Standard würde ich "yes" vorschlagen: * Bei einem falsch konfigurieren Client würde nur der PTR-Record aktualisiert werden und der A-Record vergessen werden. * Damit der Client seinen A-Record selber aktualisieren kann ist weitere Konfiguration notwendig (i.d.R. Credentials) * In Unternehmen ist vermutlich Variante 1 der Normalfall. Die Konfiguration der Server-Seite ist in <https://hutten.knut.univention.de/mediawiki/index.php/Philipp_memo/DHCP#DNS_Aktualisierung> beschrieben.
Für das clientseitige DDNS sollte man in in "dhclient.conf(5)" auch den Abschnitt über "DYNAMIC DNS" beachten. Nach Rücksprache mit Stefan lösen wir das jetzt wie folgt: 1. Wir belassen die Konfigurationsmöglichkeit per UCR im Paket, denn darüber lässt dich zumindest das serverseitige DDNS konfigurieren. 2. Zusätzlich wird in der /etc/dhcp/dhclient.conf für das clientseitige DDNS sinngemäß folgendes ergänzt: | import os.path | ... | LOCAL = "/etc/dhcp/local.conf" | ... | if os.path.exist(LOCAL): | print "include %s;" % (LOCAL,) Wir sollten eine leer Datei mitliefern. Eine funktionierende Datei sieht dann wie folgt aus: | key "XXXXX.ddns.pmhahn.de" { | algorithm hmac-md5; | secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; | }; | zone ddns.pmhahn.de. { | primary 213.239.197.57; | key "XXXXX.ddns.pmhahn.de"; | } # ucr set hostname=XXXXX dhclient/options/ddns/zone=ddns.pmhahn.de Zum Testen von DDNS: # nsupdate -y XXXXX.ddns.pmhahn.de:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > server 213.239.197.57 > zone ddns.pmhahn.de. > update add XXXXX.ddns.pmhahn.de 3600 IN A 1.2.3.4 > send > update delete XXXXX.ddns.pmhahn.de 3600 IN A 1.2.3.4 > send > quit
(In reply to comment #6) > | LOCAL = "/etc/dhcp/local.conf" Es gibt bereits eine local.conf Datei, allerdings wird die vom DHCP-Server benutzt. Von daher "dhclient.conf.local".
Bitte wie von Philipp vorgeschlagen umsetzen.
Änderungsvorschläge wurden übernommen. In Tests wurde dhclient.conf gemäß dem gewünschten Verhalten geschrieben. univention-network-manager (3.0.21-1) unstable; urgency=low * added differentiation between server side ddns and client side ddns in dhclient configuration (Bug #24282)
OK: dhclient/options/ddns/serverupdate=1 funktioniert: Der Server trägt sowohl den A-Record in der Forward-Zone als auch den PTR-Record in der Reverse-Zone ein. OK: dhclient/options/ddns/serverupdate=0 funktioniert: Der Server trägt nur den PTR-Record in der Reverse-Zone ein, der Client aktualisiert selber seinen A-Record über die in /etc/dhcp/dhclient.conf.local zusätzlich angegebenen Credentials. In /var/log/syslog ist dazu folgendes zu lesen: dhclient: Added new forward map from XXXXX.ddns.pmhahn.de to 10.200.17.56 OK: svn33964, univention-network-manager_3.0.22-1.86-201207041652 OK: ChangeLog Allerdings sind die Beschreibungen für die UCR-Variablen in den Datein debian/univention-{ifplugd,network-manager}.univention-config-registry{,-variables} nicht synchron, weshalb die Beschreibung bei "ucr info" fehlt. Da das ein generisches Problem von dem Paket ist, habe ich das in Bug #27829 ausgelagert.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".