Bug 24145 - Funktionsbeschreibung von univention-bind und univention-bind-proxy
Funktionsbeschreibung von univention-bind und univention-bind-proxy
Status: CLOSED FIXED
Product: UCS manual
Classification: Unclassified
Component: IP and network management (DHCP, DNS, firewall, proxy)
unspecified
Other Linux
: P5 normal (vote)
: UCS 3.2
Assigned To: Moritz Muehlenhoff
Philipp Hahn
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-21 13:52 CEST by Roman Asendorf
Modified: 2015-04-01 13:48 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

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Asendorf univentionstaff 2011-10-21 13:52:36 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.
Comment 1 Moritz Muehlenhoff univentionstaff 2011-10-21 14:38:35 CEST
Das ist für den DNS-Abschnitt im neuen Netzwerk-Management-Kapitel des 3.0-Handbuchs vorgesehen.
Comment 2 Moritz Muehlenhoff univentionstaff 2013-09-25 14:37:32 CEST
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).