HOWTO: dns mit ldap-zone-lookup

hallo zusammen,

also, nachdem es nun laeuft, ich gefragt wurde wie und nun auch noch die zeit gefunden habe, hier nun also, wie man es anstellt.

vorne weg vielleicht noch, dass man bind in der version 9.1.0 oder neuer installiert haben muss.

weiter solltet ihr noch folgendes beruecksichtigen:
dieses howto wurde auf die hier beschriebene art unter suse linux 9.3 installiert. will heissen, es wird openLdap verwendet. in wie weit die hier aufgefuehrten pfadAngaben fuer ein anderes linuxSystem zutreffend sind, vermang ich nicht zu sagen, da ich noch nicht so lange bei linux dabei bin. ich denke aber, dass wenn ich davon sprechen, die slapd.conf zu editieren oder eine ldapSchemaDefinitionsDatei zu laden, dann wird dies wohl jeder hinbekommen, der schon ein ldap am laufen hat. dies ist im uebrigen natuerlich voraussetzung fuer dieses howto. also, ldap muss installiert, konfiguriert und lauffaehig sein!
weiter werden wir in diesem howto eine dnsZonen als master konfigurieren, die eine forwarding und eine reverse zone beinhaltet. in diesen werden wir die zonen mydomain.local und 100.168.192.in-addr.arpa konfigurieren. wir werden in diesem netzwerk einen server mit dem namen myserver haben und zwei weitere clients mit den namen client00 und client01. ausserdem wird es drei cnameEintraege geben. www, mail und ns werden alle samt aliasEintraege fuer myserver sein. zuguter letzt noch, wir gehen von einem in der /etc/openldap/slapd.conf wie folgt konfigurierten suffix aus " dc=mydomain,dc=local "!

wem das nun schon zu viel war, der sollte an dieser stelle nun stopen und sich zunaechst ausgiebig mit den themen bind und ldap beschaeftigen.

gut, nun aber zurueck zum thema. zunaechst muessen wir uns ein paar sachen herunter laden. eigentlich nur zwei, um genau zu sein.

bind patch http://www.venaas.no/ldap/bind-sdb/
dns zone ldap schema http://www.venaas.no/ldap/bind-sdb/dnszone-schema.txt

anschliessend den bind patchen, wie es in der INSTALL, welche im patchArchivFile enthalten ist, beschrieben wird.
ANMERKUNG: unter suse linux 9.3 ist dieser patch bereits in bind integriert und besitzer dieser distribution koennen sich das patchen sparen...

anschliesend den inhalt der ldapSchemaDatei als textDatei unter /etc/openldap/schema/dnszone.schema abspeichern. diese nun durch den ldapServer beim starten einlesen lassen. dies erreicht man, indem man in der datei /etc/openldap/slapd.conf folgende zeile hinzufuegt.

(man tut gut daran, dies an der stelle zu machen, wo all die anderen includeAnweisungen stehen)

bevor der ldapServer nun aber neu gestartet wird, muss auf jeden fall dafuer gesorgt werden, dass ebenfalls die datei cosine.schema geladen wird. dies ist notwendig, da die dnszone.schema auf dieser aufsetzt und wir spaeter attribute verwenden werden, welche in der cosine.schema definiert sind. dies ist das normale vorgehen. will heissen, es ist keine eigengestrickte loesung!
man sorge nun also dafuer, dass folgender eintrage in der
/etc/openldap/slapd.conf vorhanden ist und achte darauf, dass dieser vor dem include fuer die dnszone.schema definiert ist.


weiter fuegen wir noch die folgenden anweisungen der /etc/openldap/slapd.conf hinzu und tun dies an der stellen, an der dort die indizes definiert sind.


wenn in eurer /etc/openldap/slapd.conf die angaben fuer die indizes in einer zeile geschrieben sind, also in etwa so:


wobei ich gerade nicht wirklich weiss, ob dann auch wirklich ein komma zwischen den attributAngaben steht, dann fuegt ihr es halt dem dort angewandten schema entsprechend hinzu.

so, nun startet den ldapServer mal neu und schaut, dass er keine fehler berichtet. sollten fehler auftrette, dann kann ich nur empfehlen, dass ihr euch anschaut, welche logLevelDefinitionen es fuer die /etc/openldap/slapd.conf gibt, wendet entsprechend einen an und schaut euch dann an, was alles in die /var/log/messages geschrieben wird, waehrend ihr den ldapServer neu startet. das hilft sehr oft. folgender befehl ist dabei sehr hilfreich:


tail liest die testdatei aus. parameter f bestimmt, dass immer dann, wenn etwas der logDatei hinzugefuegt wird, dieses dann auch gleich in der shell, wo wir uns befinden, ausgegeben wird. parameter n mit der angabe 100 sagt tail, dass es die letzten 100 eintraege der logDatei ausgeben soll. schoen, haetten wir das auch...

gut, unser ldapServer laeuft nun also. fuegen wir nun mal etwas hinzu, was dann spaeter auch ausgelesen werden kann. wir werden unterhalbe des ldapSuffix einen ouEintrag " DNS " einfuegen, welcher weiter ouEintraege fuer zonenDaten wie etwa forwarding und reverse zones einer masterZone enthalten. dies sieht dann in etwa so aus:


kk, nun wissen wir, wo wir unsere dnsZonenDaten und -eintraege ablegen werden. schauen wir uns nun also an, was wir alles eintragen werden.
zunaechst schauen wir uns mal an, wie so eine zonenDefinition in einem textfile aussieht. hierzu nehmen wir diejenige genauer unter die lupe, welche uns die forwardingZone fuer unser netzwerk definiert.


k, dies laest sich in drei wesentliche teile zerlegen.
erstens der kopf, welcher sich vom anfang der datei bis inklusive der zeile "mydomain.local. IN NS ns.mydomain.local." erstreckt.
zweitens die definitionen fuer die hosts (IN A-eintraege) und drittens die definitionen der aliase (IN CNAME).

dies spiegelt dann auch wieder, wie wir die eintraege im ldap vornehmen muessen.
erstens einen fuer den kopf, in welchem die standardwerte fuer die zone definiert werden. dieser schaut in ldif-notation wie folgt aus:


hier die definition des serverEintrags:


hier die der clients:


und zu guter letzt noch die aliasEintraege:


nun mag sich vielleicht so manch einer fragen, wie er das denn nun in sein ldapVerzeichnis bekommt. hier nun also noch eine exkursion diesbezueglich.
wir speichern alle zuvor erwaehnten ldif-definitionen in einer textdatei. am anfang dieser textDatei, vor der ersten weiter oben genannten objektDefinition fuegen wir folgendes ein:


nun navigieren wir in unserer shell in das verzeichnis, wo wir diese textDatei abgelegt haben. per konvention geben wir ihr in ihrem namen noch die dateiEndung .dif.
angenommen, wir haben der datei den namen "dnsinput.ldif" gegeben, fuehren wir nun diesen befehl aus:


wobei gilt:

-c besagt, dass bei einem fehler nicht abgebrochen, sondern weiter gemacht werden soll. ACHTUNG: unbedingt kontrollieren, was eingetragen wurde und was nicht. aber das macht man ja eh, gell... ;-)
-f klar, oder...
-v verbose
-x simpleauthentication mechanism
-D "..." hier muesst ihr den adminAccount angeben, denn ihr unter rootdn in der /etc/openldap/slapd.conf angegeben habe, oder ihr seit schon weiter hinsichtlich acl und/oder aci und verwendet ein userAccount mit den entsprechenden rechten. ach, was laber ich, das wisst ihr ja eh, oder...
-W besagt, dass nach dem absetzen des kommandos noch das passwort fuer die verbindung zum verzeichnisdienst abgefragt werden soll. man kann an stelle dessen auch " -w secret " verwenden, wobei secret dann natuerlich das passwort fuer den verwendeten binddn sein muss.

nachdem diese eintraege nun also dem ldapVerzeichnis hinzugefuegt wurden, sieht dieses nun in etwa so aus:


nun wollen wir ja aber nicht nur eine forward-lookup-zone einrichten, sondern auch eine reverse. ich kuerz jetzt an dieser stelle ein klein wenig ab und praesentiere gleich die gesamte lidfDatei. wer ein klein wenig genauer hin schaut, der wird die unterschiede recht schnell sehen und sich ableiten koennen, wie man einen reverseLookupEintrag erstellt.
hier nun also die ldif-datei:


ist diese ebenfalls in das ldapVerzeichnis eingelesen worden, so sieht jenes nun wie folgt aus:


schauen wir uns nun an, wie wir unserem bind verklickern koennen, dass er diese konfiguration auslesen und anwenden soll.
hierzu nehmen wir uns die /etc/named.conf zur hand und editieren sie unseren anforderungen entsprechend.
hierfuer fuegen wir folgende zonenDefinitionen hinzu:

(ersetzt xxx.xxx.xxx.xxx mit der ipAdresse, auf welcher euer ldapServer lauscht. z.b. 127.0.0.1 oder 192.168.100.1. verwendet keine dnsNamen, diese kann bind beim starten noch nicht aufloesen. dem aufmerksamen leser wird nicht entgangen sein, dass dieses mir zum verhaengnis wurde... ;-) die zahl 172800 am ende definiert die standardTTL, welche bind anwenden wird, sollte keine im verzeichnisdienst konfiguriert sein. jede der beiden zonenDefinitionen enthaelt eine zeile, welche angibt, wie und wo auf den verzeichnisdienst zugegriffen werden soll. diese definition " database ... " ist jeweils in EINER zeile zu notieren. den umbruch macht hier nur euer browser!)

also, wenn wir bind nun neu starten, dann wird er uns die zonenDefinitionen, welche wir im ldapVerzeichnis definierten, auslesen und uebernehmen. zum testen sollte nun also der namensserver in der konfiguration der ipEinstellungen der lokalen maschine auf den server gesetzt werden, auf welchem der ldapKonfigurierte bind laeuft. wenn das die gleichen maschine ist, wie die, auf der man arbeitet, dann einfach 127.0.0.1 als namensserver eintragen. anschliessend sollte eine nslookup in etwa folgendes ergebnis liefern:


bevor wir nun aber in jubel ausbrechen, weil unser bind das macht, was wir wollen, das er macht, schauen wir uns noch ein weiteres, sehr wichtiges thema an.
in unserer aktuellen konfiguration verbindet sich der bind naemlich als anonymer benutzer. wer schon mal mit acl oder aci gearbeitet hat, weiss was nun kommt. fuer alle anderen schnell ne kleine erklaerung. in openldap ist es moeglich, mittels sogenannter acl- und/oder aciEintraegen zugriffsBerechtigungen fuer einzelne eintraege im verzeichnis oder fuer ganze teilBaeume oder das gesamte verzeichnis zusammen zu erstellen, wobei auch kombinationen zulaessig sind. hierbei wird es natuerlich interessant, wenn man angeben kann, dass der benutzer XY zugriff auf bereiche hat, bzw. dort eintraege erstellen, editieren und loeschen kann, was andere benutzer nicht koennen. ein adminAccount sozusagen. oder man macht es an der mitgliedschaft einer bestimmten gruppe im ldapVerzeichnis fest. die moeglichkeiten sind sehr umfangreich und man kann sich durch aus in der endlosigkeit von detailAclDefinitionen verlieren... ;-)
well, um dies umsetzen zu koenne, sollten wir wissen, wann bind sich anmeldet. wir koennen bind hierzu sagen, dass es bestimmte zugangsdaten beim verbinden mit dem verzeichnisdienst verwenden soll. bevor wir das nun in der /etc/named.conf eintragen, erstellen wir uns zunaechst einen solchen benutzer in unserem ldapVerzeichnis, der ausschliesslich dazu verwendet werden wird, bind das anmelden am verzeichnisdienst und den zugriff auf die zonenDefinitionen zu ermoeglichen.
hierzu erstellen wir ein simpleSecurityObject und speichern es unter ou=dns,dc=mydomain,dc=local ab, wobei es den benutzernamen bind9.ldapbindaccount bekommen wird.
zuvor muessen wir uns aber noch die verschluesselte version eines passwortes erstellen. hierzu geben wir in unserer shell folgendes kommando ein (wobei changeit durch ein von euch gewahltes passwort ersetzt werden sollte!):

(md5 ist hierbei nicht nur mein favorit, sondern sehr verbreitet. es bietet die moeglichkeit, auch laengere passworter (unix traditionel 8 zeichen) zu verwenden und bietet durch den verwendetet algorithmus ausreichend schutz. fuer spaeter projekte hier ein kleiner tip: openldap verwendet base64-encoded md5 (ich meine, es heisst so))

dieses passwort benutzen wir nun also um eine definition unseres bindBenutzerKontos in ldif-notation zu erstellen:


diese nun in unseren verzeichnisdienst eingefuegt, sieht jener nun wie folgt aus:


und nun packen wir das ganz noch in unsere /etc/named.conf, welche darauf hin folgende zonenDefinitionen verwendet:

(die ldapDefinitionen hinter database sind in EINER zeiler zu notieren!)

und schon verwendet bind die hier angegebenen zugangsdaten. die verwendung von %2c an stell von kommas und die vielen fragezeichen sind im uebrigen keine tipFehler. das muss so sein. %2c deswegen, da kommas hier als paramerterTrennzeichen fuer die gesammte ldapSpezifische konfiguration verwendet werden.
gut, machen wir nun noch aus " !x-bindpw=changeit " ein " !x-bindpw=changeit,x-tls ", so connected bind auch noch unter der verwendung einer gesicherten verbindung.

jetzt sollte eigentlich soweit alles tun. testet den nslookup wie weiter oben geschildert noch einmal. und schaut in die logFiles, wenn etwas nicht geht.
als letztes bleibt noch zu erwaehnen, wie bind eigentlich nach daten im ldapVerzeichnis sucht. es verwendet hierzu die folgenden search filter:


eigentlich sind es einige abfragen mehr, welche unterschiedliche werte fuer das attribut relativeDomainName definieren. im wesentlichen reicht es aber, die hier aufgefuehrten zu wissen, um sich gedanken machen zu koennen, wie flexibel mit diesem werkzeug dnsAufgaben gemanaged werden koennen.

so, nun haben wir so ziemlich alles besprochen.

ich hoffe es wird dem ein oder anderen helfen und ihr verzeiht mir die fehler und zusammenhangslosen saetze... ;-)

viel spass beim basteln und einen schoenen tag noch.

dialsc