Univention Bugzilla – Bug 24145
Funktionsbeschreibung von univention-bind und univention-bind-proxy
Last modified: 2015-04-01 13:48:21 CEST
Bereits häufiger ist die Frage nach den Aufgaben von univention-bind und univention-bind-proxy aufgetaucht. Nun wieder in einer Schulung. Wir sollten hierzu einen WIKI-Artikel erstellen, damit die Funktionen beider deutlicher wird: Als Ausgangsbasis für den Artikel können diese Beschreibungen dienen: 1. Welche Aufgaben haben univention-bind und univention-bind-proxy genau? - der bind liest die DNS-Informationen aus dem LDAP und baut dabei für sich die Zonendateien auf - für das Lesen aus dem LDAP muss der bind die Zonen komplett löschen und neu auslesen, was in größeren Umgebungen einige Sekunden dauern kann; in dieser Zeit beantwortet er aber weiter Anfragen und würde dann falsche/keine Ergebnisse zurückliefern und die Umgebung massiv stören univention-bind liest die Daten aus dem LDAP, univention-bind-proxy bezieht die Daten von univention-bind. Das ist die empfohlene Vorgehensweise für das LDAP Backend von bind. Ich meine aus zwei Gründen, es darf keinen Loop geben, damit für den Aufbau der LDAP Verbindung nicht wieder das DNS gefragt wird und zum anderen wird nicht für jede kleine DNS Abfrage (das kann in grossen Domänen sehr viel werden) eine LDAP Abfrage gestartet. Von http://bind9-ldap.bayour.com/ -------------------------------------------------------------------------- Master and slave configurations Using the back-end master servers will make an LDAP query each time they receive a query. There are some advantages to that, but it will of course be slower than using BIND's memory caching. Also note that this back-end appears to be stable, but it has not been tested as heavily as BIND itself, which means that the same level of stability can't be assumed. One way to solve this could be to have a stealth master, not giving it an NS record, and have at least two slaves. The slaves can be any nameserver software you like, and will use AXFR and do caching as usual. In many situations LDAP lookups might be fast enough and you might like the advantage of instant updates. You could then have several masters all using LDAP. You should then use LDAP replication or whatever so that the masters use different LDAP servers. There's no point in several masters and one LDAP server. -------------------------------------------------------------------------- Der dritte Grund ist, es funktioniert, so wie es ist. ;) Siehe oben, damit nicht jede Anfrage auch eine oder mehrere Suchen im LDAP nach sich zieht. - daher haben wir den bind-proxy davorgeschaltet, der per Zonentransfer vom bind mit Updates versorgt wird; dabei kann er weiter Anfragen beantworten da kein vollständiger Reload stattfindet Mit UCS 3.0 gibt es drei wesentliche Änderungen in diesem Bereich: - univention-bind und univention-bind-proxy wurden vereinheitlicht. Es gibt dann noch ein Paket, allerdings noch zwei Daemon. Die werden aber einheitlich über /etc/init.d/bind9 gestartet und beendet. - Wir aktualisieren auf bind 9.8 - Neben dem LDAP Backend bringen wir das Samba 4 Backend mit. Dann greift Bind direkt auf die Samba4 Daten zu. Unser S4 Connector synchronisiert die DNS Daten dann zwischen Samba 4 und OpenLDAP. Somit kann man die Daten dann bequem per UDM administrieren, auch wenn das Samba 4 Backend verwendet wird. Mit dem Samba 4 Backend wir dann vermutlich auch direkt dynamisches DNS funktionieren. > Aus der Doku habe ich hierzu keine weiteren Infos entnehmen können, > nur, dass die Zonendateien vom bind-proxy ausgelesen werden und ggf. > durch weitere 'externe' Einträge erweitert werden können. Mit externen Einträgen meinst du die Definition weiterer Zonen? Das kannst du einfach in der local.conf oder local.conf.proxy definieren. Das man Zonendateien auch von Hand pflegen kann ist als Option integriert, um bestehende Daten und Tools einfacher einbinden zu können. Empfehlung ist natürlich, das im LDAP zu machen. Bei mehreren DNS-Servern in einer UCS-Umgebung müssten die Zonendateien auch mehrfach gepflegt werden, im LDAP fällt das weg.
Das ist für den DNS-Abschnitt im neuen Netzwerk-Management-Kapitel des 3.0-Handbuchs vorgesehen.
The two-fold setup with the bind proxy and the backend server is now documented in Chapter 9.2.1.2 (Configuration of the data backend).
OK: r44463 OK: <http://jenkins.knut.univention.de:8080/view/Doku/job/UCS-3.2-0%20Handbook%20UCS/lastSuccessfulBuild/artifact/webroot/handbuch-3.2.html#ip-config:dns:backend> TODO: <http://jenkins.knut.univention.de:8080/job/UCS-3.2-0%20Handbook%20UCS/lastSuccessfulBuild/artifact/webroot/manual.html#ip-config:dns:backend>