Bug 24282 - Enabling DDNS in dhclient.conf
Enabling DDNS in dhclient.conf
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: DHCP
UCS 2.4
Other Linux
: P5 enhancement (vote)
: UCS 3.0-2
Assigned To: Lukas Walter
Philipp Hahn
: interim-2
Depends on:
Blocks: 27829
  Show dependency treegraph
 
Reported: 2011-11-01 10:04 CET by Roman Asendorf
Modified: 2012-07-20 15:24 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
univention-network-manager_ddns.patch (2.97 KB, patch)
2012-01-03 07:44 CET, Stefan Gohmann
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Asendorf univentionstaff 2011-11-01 10:04:52 CET
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)
Comment 1 Ingo Steuwer univentionstaff 2011-11-02 15:23:03 CET
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
Comment 2 Stefan Gohmann univentionstaff 2012-01-03 07:44:08 CET
Created attachment 4054 [details]
univention-network-manager_ddns.patch
Comment 3 Jürgen Kahrs univentionstaff 2012-06-07 12:55:58 CEST
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.
Comment 4 Jürgen Kahrs univentionstaff 2012-06-07 12:58:38 CEST
Korrektur zu meinem Kommentar:

Das Abschalten von DDNS geht mit:
  ucr set dhclient/options/ddns=off
Comment 5 Philipp Hahn univentionstaff 2012-07-03 11:06:11 CEST
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.
Comment 6 Philipp Hahn univentionstaff 2012-07-03 14:53:56 CEST
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
Comment 7 Philipp Hahn univentionstaff 2012-07-03 15:21:24 CEST
(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".
Comment 8 Stefan Gohmann univentionstaff 2012-07-04 11:41:05 CEST
Bitte wie von Philipp vorgeschlagen umsetzen.
Comment 9 Lukas Walter univentionstaff 2012-07-04 16:00:02 CEST
Ä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)
Comment 10 Philipp Hahn univentionstaff 2012-07-04 21:01:38 CEST
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.
Comment 11 Stefan Gohmann univentionstaff 2012-07-20 15:24:10 CEST
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".