named löst Namen nicht mehr auf

[PMBOSS]

Hallo,

ich setze gerade einen All-Inclusive-PDC unter Suse Linux 10.0 auf.
DNS,LDAP,remote-Verwaltung per phpldapadmin, Samba-PDC. Das Ganze soll dann auch noch auf einen BDC repliziert werden.

Bin immer noch Anfänger - so langsam glaube ich, das wird sich nie ändern - und gehe nach einem 10cm hohen Stapel an Howto's vor. Da ich leider noch keines gefunden habe, bei dem nicht irgendwas zu Stolperstein wird, gestaltet sich das Vorhaben extrem zeitraubend. Wäre ich nicht so ein sturer Hund, hätte ich längst einen Win2003-Server draus gemacht.

Nun bin ich soweit, da LDAP und phpldapadmin laufen und auch die Benutzverwaltung am Server (noch ohne Samba) komplett ber LDAP funktioniert. Zuvor musste ja der DNS-Server laufen, weil LDAP laut Howto's eine funktionierende Namensauflösung braucht. Den habe ich ebenfalls nach diversen Howto's aufgesetzt und VOR der Einrichtung von LDAP getestet.

Da hat auch alles noch wunderbar funktioniert (Forward und Reverse).

Leider ist dem jetzt nicht mehr so. Er löst keine Namen mehr auf, obwohl ich weder an der named.conf noch an der forward bzw. reverse-Datei irgendwelche Änderungen vorgenommen habe (warum auch? es lief ja einwandfrei!)

Aufgefallen ist erst, daß er's nicht mehr tut, als beim Erstellen eines Client-Zertifikates für die TSL-Verschlsselung des LDAP pltzlich eine Fehlermeldung "gethostname" oder so ähnlich kam. Habe dann getestet, ob die Namensauflösung noch tut. Das Ergebnis: Der named läuft nach wie vor und läßt sich ohne Fehlermeldung starten und beenden. Nur auflösen tut er nichts mehr, obwohl die Forward und Reverse-Dateien wie auch die named.conf unverändert sind.

Hat da jemand eine Idee, wie man den Fehler am Besten eingrenzen kann? Oder besser noch: Gleich die Lösung? Macht sich LDAP da vielleicht schon selbst zur DNS-Datenbank? Vielleicht durch eine der vorhandenen Schema-Dateien?

Bin für jeden Tip dankbar. Habe mir da offensichtlich mächtig was vorgenommen.

 

[stka]

Wenn du dir mal meinen Workshop im LDAP Forum anschaust, oder gleich unter www.kania-online.de/workshop.htm dann wirst du da alles finden, inklusive der benötigten conf-Dateinen.
Wenn wir dir hier helfen sollen, musst du uns schon ein paar mehr Infos geben, wie z.B. die named.conf und die Zonendateien.
Beim erstellen des Server Zertifikats hast du da den FQD deines LDAP-Servers als common Name verwendet?

 

[PMBOSS]

Erst mal zu Deiner Frage:

Bei der Erstellung des Serverzertifikates habe ich als common-name "Servername.Domäne.local" eingetragen.


Dein Workshop ist übrigens das mit Abstand Beste, was ich zu den diversen Themen gefunden habe. Deshalb richte ich mich auch weit überwiegend danach. Eine kleine Ausnahme ist vielleicht die Doku zum phpldapadmin. Da mußte ich auch noch anderweitig nachlesen.

Zu meinem Problem:
Habe gestern noch ein bischen rumlaboriert und muß eine Aussage korrigieren: Der Reverse-Lookup funktioniert immer, der Forward jedoch nicht.

Der Grund (glaub' ich zumindest):
Ich fuhrwerke derzeit mit zwei Domänen rum. Sagen wir Domäne1, eine uralte NT-Domäne und Domäne2, die künftige Samba-Domäne, die Domäne1 ablösen soll. Dabei soll sich auch der Name der Domäne ändern. Domäne 2 läuft noch nicht, da Samba noch nicht läuft. Den versuche ich ja gerade aufzusetzen. Alle Rechner im Netz (außer dem neuen Server) befinden sich in Domäne1

Folglich stand in der Arbeitsgruppe der Netzwerkkarte des neuen Servers auch noch "site" (=Standard).

Ich habe ansonsten alles so gemacht, wie in Deinem Howto beschrieben. Nachdem nun offensichtlich das Problem auf den Forward-Lookup begrenzt war, habe ich erst mal dort gesucht und auch nachgesehen, was in /var/log/messages so alles protokolliert wird.

Da fiel mir auf: Ich suche die Adresse für Rechner XYZ, der aber noch in der Domäne1 (logisch, Domäne 2.local läuft ja noch gar nicht) angemeldet ist.

Der ist als
XYZ IN A 192.168.1.150
in der Forward-Datei
db.Domäne2.local
eingetragen.

Laut Protokoll sucht der named bei der Eingabe von "Host XYZ" aber automatisch nach "XYZ.site". Er hängt offensichtlich automatisch die Arbeitsgruppe des Servers an.

Abhilfe:

Erst mal habe ich neben der vorhandenen db.Domäne2.local (die neue Domäne) eine db.Domäne1 für die alte Domäne angelegt und diese auch als zweite Master-Zone in der named.conf eingetragen. Die neue Domäne erhält übrigens eine ".local", da wir einen statischen IP-Adresskreis und auch eine gleichnamige .de-Domäne im Internet haben. Damit es da keine Verwirrungen mehr zwischen innen und außen gibt, will ich jetzt die Erweiterung der lokalen Domäne um ".local". Dann ist das klar getrennt. Im LDAP habe ich die auch so eingetragen: o=domäne2,c=local

Jetzt funktioniert die Namensauflösung so:

Host XYZ ==> Host not found
Host XYZ.Domäne1 ==> die korrekte Adresse

Host Servername ==> Host not found
Host Servername.Domäne1 ==> die korrekte Adresse
Host Servername.Domäne2 ==> die korrekte Adresse

Interessant, weil sich der Server ja tatsächlich nicht in der Domäne1 befindet, aber natürlich als Nameserver in der db.domäne1 eingetragen ist.

Der nächste Schritt war, daß ich die Arbeitsgruppe des Servers von "site" auf den künftigen Domänennamen (Domäne2.local) geändert habe:

Das Ergebnis war genau dasselbe, nur dass jetzt auch der vollständige dn des Servers angegeben werden muß, damit die Namensauflösung funktioniert.
Host Servername ==> Host not found
Host Servername.Domäne2 ==> Host not found
Host Servername.Domäne2.local ==> die korrekte Adresse

Also kann ich im Moment eine Adresse nicht über die Angabe des reinen Rechnernames auflösen, sondern muß immer die vollständige Domäne anhängen.

Ist das normal und richtig so?

 

[stka]

Such mal hier nach "DNS AND .local". Das wird dein Problem sein. Bei suse läuft defaultmäßig mdns, das bedeutet, die Auflösung einer Domäne mit .local geht nicht mehr. Das Problem tritt seit der suse, ich meine 9.3, mit Sicherheit aber bei suse 10 auf.
Du kannst das Problem umgehen, in dem du
1. Deiner Domäne einen neuen Name gibst oder
2. in der Datei /etc/host.conf den Eintrag "mdns = off" hinzufügst.

 

[PMBOSS]

BINGO !!

Habe .local in .BlaBla geändert und schwups war das DNS-Problem gelöst. War schon total gefrustet und habe im Laufe des Tages nochmal bei Null angefangen, weil ich dachte, vielleicht doch irgendwo was verbogen zu haben . Naja, nicht zur Strafe, nur zur Übung....

Genaus das ist übrigens der Punkt, der sehr gegen Linux spricht: Es gibt aus 10.000 Quellen Informationen, wie dies oder jenes zu konfigurieren ist. Selten genug steht dabei, was für eine Softwareumgebung GENAU da verwendet wurde. Und ob die mit der jeweils eigenen noch kompatibel ist, weiß auch nur jemand, der das per Try and Error-Prinzip schonmal selbst erfahren hat. Die Geschichte mit dem .local habe ich nämlich auch irgendwo gesehen und kopiert, weil es mir logisch erschien. Das war dann wohl auch eine etwas angegraute Veröffentlichung.

Bin gespannt, ob ich jetzt zu einem erfolgreichen Abschluß komme.

Auf jeden Fall erstmal VIELEN DANK !!

 

[carsten]

Anmerkung am Rande:
.local ist KEINE TLD für interne Netze gemäß Vorgaben. Wie immer ein typischer MS-Alleingang.

Es gibt offizielle TLD für interne Netze, die reserviert sind und die dann auch keine komischen Effekte bringen.

Suse macht das seit 9.1

Hy, 
stand in der neusten c't 02/05: 
Folgende TL-Domains gehen für Tests gem. RFC 2606: 
.test 
.example 
.invalid 
.localhost 

sowie folgende Domains: 
example.com 
example.net 
example.org 

Folgende TLD gehen auch: 
aa, zz, und alle 2-stelligen, die mit x anfangen (xa..xz) 

Mir fällt auf: 
.local ist nicht dabei. 

Grüße

Aus: http://www.linux-club.de/viewtopic.php?t=6067&start=25