Univention Bugzilla – Bug 301
DHCP: Dynamic DNS Updates
Last modified: 2015-12-18 07:40:51 CET
S. 14 - 19 S. 14: ad-hoc update scheme is deprecated and does not work. In future it will not likely be available. S. 15: does not work with the failover protocol => ad-hoc will Stefan wieder rausschmeissen. Die Option "ddns-hostname" habe ich nur bei ad-hoc gefunden, könnte dann also auch raus. (Optionsbeschreibung auf S. 26) Es gibt für Dynamic DNS Updates noch keinen Standard. Wir sollten das also verfolgen und anpassen, wenn ein Standard beschlossen wird. Die Option "allow/deny client-updates" befindet sich zurzeit auf der Karteikarte Scope, sollte aus inhaltlichen Gründen evtl. auf die Karteikarte DNS Update verschoben werden? Gerade wenn das ganze Dynamic DNS Update eine Funktion für Fortgeschrittene sein soll, sollten andere nicht damit behelligt werden. (S. 16 "By default, client update are allowed." Sollten wir solche defaults irgendwie deutlich machen? Z.B. indem wir den Defaultwert zur Vorgabe machen, also automatisch eintragen? Problematisch, falls sich das extern vorgegebene Defaultverhalten ändert. In der Mouseover-Hilfe und/oder im Handbuch darauf hinweisen? Verlangen, dass der Anwender das selbst weiß? Statt Auswahlliste mit allow und deny Auswahlkästchen mit dem Nicht-Default-Wert? Funktioniert nicht bei mehr als zwei Möglichkeiten.) Der Client muss mit einem Flag einer FQDN-Option deutlich machen, dass er seinen ARecord im DNS selbst updaten möchte. => Clients sollten entsprechend eingestellt werden können im admin, z.B. auf der Karteikarte DNS beim Rechner hinzufügen/bearbeiten? (Sollen sie auch ihren fqdn (fully-qualified domain name) eintragen können für die entsprechende Option? In der man-page ist ein Beispiel mit einem Client aus einer anderen DNS-Domäne, für den die Option wichtig wäre. Laut Peter für uns kein Thema.) S. 17: "The DNS server must be configured to allow updates for any zone that the DHCP server will be updating." Die named.conf (? bzw. unsere ensprechende Datei) muss für Dynamic DNS Update angepasst werden, Keys zur Verschlüsselung sollten eingesetzt werden. S. 18: Ebenso muss die dhcpd.conf angepasst werden. Mit dem primary-Statement muss die IP/der Name des DNS-Servers, der upgedatet werden soll, angegeben werden. (S. 27: do-forward-updates enabled by default. Has no effect unless ddns-update-style interim. Will still honor the settings of the client -updates flag.) S. 34: "The update-static-leases statement update-static-leases flag; The update-static-leases flag, if enabled, causes the DHCP server to do DNS updates for clients even if those clients are being assigned their IP address using a fixed-address statement - that is, the client is being given a static assignment. This can only work with the interim DNS update scheme. It is not recommended because the DHCP server has no way to tell that the update has been done, and therefore will not delete the record when it is not in use. Also, the server must attempt the update each time the client renews its lease, which could have a significant performance impact in environments that place heavy demands on the DHCP server." (Hervorhebungen von Barbara) Soll diese Option weiterhin angeboten werden im admin?
Barbara, den aktuellen Stand kannst Du Dir auf testing anschauen. Ich habe einiges geaendert/behoben. Bzgl. der verschiedenen update styles ist anzumerken, dass wir zunaechst einmal nur die Konfiguration abbilden, was der DHCP Server daraus macht, koennen wir nicht in allen Einzelheiten vorher abfangen. Teilweise kann es auch sein, dass Kunden gewisse Fehlfunktionen offenbar in Kauf nehmen bzw. Fehlkonfigurationen oder Konfigurationen, die keinen Effekt/Sinn haben, auch in ihrer dhcpd.conf hatten.
> Der Client muss mit einem Flag einer FQDN-Option deutlich machen, dass er seinen > ARecord im DNS selbst updaten möchte. Bitte die entsprechenden Auszuege aus der manpage angeben oder wo kommt dies her?
ad-hoc update scheme ist in Univention Admin Option "allow/deny client-updates" ist jetzt bei DNS Update In unser DNS ist meines Wissens noch keine Möglichkeit zur Konfiguration von DDNS integriert. Das ist aber nötig, um DDNS überhaupt nutzen zu können. => Ist es sinnvoll, die Konfiguration auf DHCP-Seite schon anzubieten? Allgemein müsste sich nach meiner Einschätzung nochmal jemand Dynamic DNS Update insgesamt angucken.
nach eingehenden Tests versuche ich mal zusammenzufassen, welche Erweiterungen am derzeitigen Stand des Admin nötig sind: 1. Bezüglich Konfigurationsdateien: - in dhcpd.conf und named.conf sollten gemäß üblichen Konventionen (siehe man dhcpd.conf) keys definiert werden, um signierte DDNS-Updates möglich zu machen - in den Zonendefinitionen müssen auf dem master "allow-update" und auf dem proxy (und eventuellen Slaves) "allow-update-forwarding" acl's bezüglich diesen keys eingetragen werden; das benötigt Erweiterungen des listener-moduls und des schemas 2. Bezüglich der derzeitigen Ldap-Einträge: - die Einträge für DDNS-Domain-Name und reverse gehören in "" ins Ldap, das muss jetzt mit "" in den Admin eingetragen werden - Die Policy-vererbung funktioniert nicht richtig (?), es werden an DHCP-Service angegebene Werte genommen auch wenn in DHCP-Subnet dinge definiert sind 3. Bezüglich bind: Hier wirds kompliziert. Das Ldap-Backend des Bind9 scheint ein speichern nicht möglich zu machen -- die eingehenden Update-Anfragen des DHCPD werden zwar bemerkt (bei named -d128), aber nicht bearbeitet. Das bedeutet scheinbar, dass der bind-code nach den entsprechenden Funktionen durchsucht und um die Änderung/Ergänzung von Einträgen ins Ldap erweitert werden muss. Mögliche Folgen (teste): - Laut man dhcpd.conf werden erfolgreiche Einträge in der dhcp.leases vermerkt und, erhält der Client die gleiche IP wieder, nicht erneut an den DNS-Server weitergeleitet. Sollte das nicht der Fall sein würden häufige DDNS-Anfragen (kleine lease-time) schnell zu einem hohen Replikationsaufwand führen.
Sollten DDNS-Updates wirklich im LDAP gespeichert werden? Das würde ja heissen, dass wir Bind schreibenden LDAP-Zugriff geben müssten. Meiner Ansicht nach müssten dynamische Updates in einer seperaten Datei gespeichert werden. Wie ist es denn eigentlich bei einer "normalen" Konfiguration? Dann werden doch auch nicht die vom Administrator gepflegten Zonendateien automatisch verändert, oder?
On Mon, Apr 19, 2004 at 09:26:21PM +0200, bugs@univention.de wrote: Doch, wird glaube ich. Roland
Mit dem Samba Parameter "wins hook" könnte man ein Skript ausführen, wenn ein Rechner sich registriert: https://postlister.uninett.no/sympa/arc/dns-ldap/2005-01/msg00006.html Unter https://postlister.uninett.no/sympa/arc/dns-ldap/2006-02/msg00001.html steht noch: "I understand that this back-end is read-only, and that dynDNS (using dhcpd) requires an extra Perl script to have it work." Gibt es beim DHCP Server eine Möglichkeit ein Skript anzugeben, welches ausgeführt wird?
(In reply to comment #7) > Gibt es beim DHCP Server eine Möglichkeit ein Skript anzugeben, welches > ausgeführt wird? Auf der Bind LDAP Patch Seite http://www.venaas.no/ldap/bind-sdb/ : DHCP A number of people have asked for Dynamic DNS support, or how they can make their DHCP server do DNS updates. There is now a tool that allows a zone to be updated based on the ISC DHCP server's lease database updates. The tool is dhcp2ldapd-1.1 and is a Perl script written by Travis Groth.
Created attachment 767 [details] dhcp2ldapd-1.1
Laut man dhcpd.conf gibt es events, die auf commit/release/timeout von Leases Aktionen ausführen können. Das klingt nach dem elegantesten Weg, das zu implementieren (und ist auch der Weg in dem das normale DDNS des dhcpd implementiert wird). Ein Beispiel aus dem Web: on commit { set client = binary-to-ascii (10,8,".", leased-address); if (execute ("/sbin/iptables", "-A", "FORWARD", "-s", client, "-j", "ACCEPT") = 0) { log (concat ("Firewall updated with new client ", client)); } else { log (concat ("Error while updating firewall with client ", client)); } } http://osdir.com/ml/network.dhcp.isc.dhcp-server/2003-01/msg00040.html Dort wird erwähnt dass noch ein bestimmter Patch eingesetzt wurde, ich denke aber dass das nicht notwendig sein wird. Ich denke übrigens weiterhin dass man diese Einträge direkt in das LDAP schreiben sollte, z.B. als IP-Managed Clients in einem eigenen Subcontainer. Ist die IP schon vergeben muss der alte Client gelöscht werden.
für "execute" benötigt der dhcpd in 3.0.X auch in UCS 2.0 noch einen Patch, das bringt erst der 4.0.X mit. Man kann aber z.B. IP und MAC (hier dezimal, nicht hexadezimal) ausgeben lassen. Dazu in der dhcpd.conf ergänzen: on commit { #execute("/usr/sbin/logger commit"); set client = binary-to-ascii (10,8,".", leased-address); set macaddr = binary-to-ascii (10,8,".", hardware); log (concat ("got new client ", client, " with ", macaddr)); } Im Log erscheint dann z.B.: Nov 14 11:58:46 dc-master dhcpd: DHCPDISCOVER from 00:0c:29:20:0d:10 via eth0 Nov 14 11:58:46 dc-master dhcpd: DHCPOFFER on 10.202.0.51 to 00:0c:29:20:0d:10 via eth0 Nov 14 11:58:47 dc-master dhcpd: Searching for Host dhcpHWAddress=ethernet 00:0c:29:20:0d:10 in LDAP tree cn=dhcp,dc=test,dc=unive ntion,dc=de Nov 14 11:58:47 dc-master dhcpd: Found Host: LDAP entry is cn=test,cn=st.univention.de,cn=dhcp,dc=test,dc=univention,dc=de Nov 14 11:58:47 dc-master dhcpd: Sending the following options: 'filename "pxelinux.0"; option domain-name "st.univention.de"; opt ion domain-name-servers 10.202.0.50; fixed-address 10.202.0.51; ' Nov 14 11:58:47 dc-master dhcpd: got new client 10.202.0.51 with 1.0.12.41.32.13.16 Nov 14 11:58:47 dc-master dhcpd: DHCPREQUEST for 10.202.0.51 (10.202.0.50) from 00:0c:29:20:0d:10 via eth0 Nov 14 11:58:47 dc-master dhcpd: DHCPACK on 10.202.0.51 to 00:0c:29:20:0d:10 via eth0
Ich habe für die existierenden Kommandos/Variablen keine Dokumentation gefunden, eine Übersicht kann man sich in den dhcpd-Quellen aus common/tree.c in "int write_expression" zusammensuchen.
Das wurde von einem Partner an Ticket: 2010060410000597 angefragt.
http://sin.co.at/schnittstellen_ucs_dhcp_dns_sync.php
Ein paar Tests: /etc/dhcp3/dhcpd.conf: on commit { execute("/usr/bin/logger", "commit"); set client = binary-to-ascii (10,8,".", leased-address); #set macaddr = binary-to-ascii (10,8,".", hardware); set macaddr = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)); set hostn = pick-first-value(option host-name,"no-hostname"); log (concat ("got new client ", client, " with ", macaddr, " host ", hostn)); } on expiry { execute("/usr/bin/logger", "expiry"); set client = binary-to-ascii (10,8,".", leased-address); #set macaddr = binary-to-ascii (10,8,".", hardware); set macaddr = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)); set hostn = pick-first-value(option host-name,"no-hostname"); log (concat ("client timeout ", client, " with ", macaddr, " host ", hostn)); } on release { execute("/usr/bin/logger", "release"); set client = binary-to-ascii (10,8,".", leased-address); #set macaddr = binary-to-ascii (10,8,".", hardware); set macaddr = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)); set hostn = pick-first-value(option host-name,"no-hostname"); log (concat ("client release ", client, " with ", macaddr, " host ", hostn)); } Damit sehe ich in der syslog bei einem ipconfig /renew unter Windows XP unter anderem: Dec 7 21:22:12 master logger: commit Dec 7 21:22:12 master dhcpd: got new client 10.201.11.55 with 0:c:29:c2:3f:f0 host winxpsp3 Bei einem Release: Dec 7 21:22:21 master logger: release Dec 7 21:22:21 master dhcpd: client release 10.201.11.55 with 0:c:29:c2:3f:f0 host no-hostname Anstatt dem logger Aufruf sollte ein Python Skript aufgerufen werden, welches einen Eintrag im LDAP erzeugt. Offen ist unter anderem die Konfliktbehandlung und die LDAP ACLs, da der DHCP Server auf allen DCs laufen kann.
Prüfung zu UCS 3.0.
Mit UCS 3.0 kann als DNS Backend samba4 verwendet werden. Dadurch können Windows 7 Clients direkt ihr DDNS Update an den DNS Server schicken und es wird registriert, da die Updates per Kerberos geschickt werden. Andere Clients können, sofern sie einen Kerberos Account haben, ebenfalls DDNS-Updates schicken. Für alle anderen sollten wir ein Tool entwickeln, welches die DHCP Hooks verwendet. Es sollte dabei sinnvoll konfiguriert werden können, welche Namen dann registriert werden sollen. Nicht zur 3.0.
Wenn Samba 4 eingesetzt wird und ein Update von einem nicht Windows Client durchgeführt werden soll: http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-updates-against-secure-microsoft-dns/
Auf der dns-ldap Liste aufgefallen: https://postlister.uninett.no/sympa/arc/dns-ldap/2012-02/msg00003.html http://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/
Ich glaube hier gibt es keine Notwendigkeit bzgl. einer Umsetzung im Produkt, da es in Samba 4 Umgebungen Out-of-the-box geht. Wenn doch bitte Reopen.
additional comment here: http://forum.univention.de/viewtopic.php?f=48&t=4686&p=18140