Nameserver sind nicht ansprechbar

Hallo,

leider bekomme ich die folgende Warnung in der Systemdiagnose des DC-Slave (192.168.0.10) angezeigt:

Warnung: Nameserver sind nicht ansprechbar
Der Nameserver 192.168.0.10 (UCR Variable ‘nameserver1’) ist nicht ansprechbar:
Eine Zeitüberschreitung trat beim Erreichen des Nameservers auf (ist er online?).

Auf den Systemen ist UCS 4.1-2 Errata 234 installiert.
DC-Master 192.168.0.40 -> keine Fehler in der Systemdiagnose

DC-Slave 192.168.0.10 -> o.g. Warnung
Netzwerk-Einstellungen
nameserver1 192.168.0.10
nameserver2 192.168.0.40
forwarder1 192.168.0.1

Was läuft da falsch ?

Vielen Dank im voraus.

Also wenn 192.168.0.10 er selbst ist, vermute ich mal dass da der DNS-Dienst (bind9) nicht läuft. Das sollte er aber, im Normalfall. Zunächst würde ich über SystemSystemdienste schauen, ob der Dienst bind9 (DNS-Server) läuft und dann mal neustarten.

System → Systemdienste
der Dienst bind9 (DNS-Server) läuft und startet automatisch

Wurde der Bind auch mal neugestartet? Was ist die Ausgabe von

nslookup google.com 192.168.0.10

Der Server wurde schon mehrmals neu gestartet, doch die Meldung blieb. Wenn ich mich richtig erinnere, war nur nach dem aller ersten Domainbeitritt keine Fehlermeldung. Dieser DC-Slave wir gelegentlich gestartet ohne das der DC-Master läuft. Dieser Start benötigt ca.5x länger, was sicherlich mit dem Fehler zusammen hängt.

nslookup google.com 192.168.0.10

Server:	192.168.0.10
Address:	192.168.0.10#53

Non-authoritative answer:
Name:	google.com
Address: 216.58.201.238

Externe Domainnamen gehen also. Klappt das ganze auch mit einem internen FQDN?

Die interne Namensauflösung geht nicht.
Nur die Externe geht und das wahrscheinlich wegen dem Eintrag “forwarder1 192.168.0.1”.

nslookup srv41-dcb 192.168.0.10

Server:	192.168.0.10
Address:	192.168.0.10#53
** server can't find srv41-dcb: NXDOMAIN
nslookup srv41-dcb

Server:	192.168.0.40
Address:	192.168.0.40#53

Name:	srv41-dcb.xxx.tld
Address: 192.168.0.41

Ich schätze mal auf dem Slave ist Samba 4 installiert? Dann wird vermutlich Samba 4 als Backend verwendet. Läuft der Samba 4? Gibt es Auffälligkeiten in den Logs unter /var/log/samba/*?

Ich glaube, dass ich einen grundsätzlichen Fehler bei der Installation gemacht habe. Nur welchen ? Was habe ich überlesen ?
Deshalb habe ich noch einmal eine Testrechner als DC-Slave (192.168.0.99) installiert.
Bei der Installation habe ich die Optionen

  • einer bestehenden UCS-Domain beitreten
  • als DC-Slave
    gewählt, sonst nichts.
    Jetzt nahm ich an, dass durch diese Angaben die korrekten Einstellungen erfolgen.
    Doch auch bei diesem Testsystem erfolgt keine Namensauflösung.
root@test-srv-2:~# nslookup srv41-dcb 192.168.0.99
Server:         192.168.0.99
Address:        192.168.0.99#53

** server can't find srv41-dcb: NXDOMAIN

root@test-srv-2:~#

Hallo,

die Frage, welches Backend für DNS genutzt wird, erscheint auch mir relevant.

[quote]# ucr search dns/backend
dns/backend: samba4
Bind can use different backends for its configuration: ‘ldap’ configures the use of the UCS OpenLDAP directory. ‘samba4’ uses the Samba 4 LDB database. When using the Samba backend, a search is performed in the LDAP for every DNS request. With the OpenLDAP backend, a search is only performed in the directory service if the DNS data has changed.
[/quote]

Viele Grüße,
Dirk Ahrnke

DC-Master

root@srv40-dcm:~# ucr search dns/backend
dns/backend: samba4

DC-Slave

root@pc10-082:~# ucr search dns/backend
dns/backend: ldap

DC-Slave (Testrechner)

root@test-srv-2:~# ucr search dns/backend
dns/backend: ldap

ok, zunächst bitte mal zur Sicherheit prüfen, ob die (Search)-Domain (zur Verwendung von Shortname anstelle des FQDN) auch gesetzt ist. Das wird zumeist über die UCR-Variable “domainname” gemacht, es geht aber auch über “domain/domainname” oder “domain/search”, was sich letztendlich in der /etc/resolv.conf niederschlägt.
Der sauberere Weg wäre m.E. aber immer die Suche mit nslookup oder dig via FQDN.

Beim LDAP-Backend werden (über includes in der named.conf) die lokalen Forward- und Reverse-Zonen in /etc/bind/univention.conf.d konfiguriert. Man sollte alsoprüfen, ober der lokale LDAP-Server

  • läuft
  • korrekte Daten in cn=dns liefert (z.B. mit univention-ldapsearch, ggf. nach “less” pipen und dann suchen)

Zur Fehlersuche bietet es sich an, in den Standard-Logs unter /var/log nachzusehen, ggf. nachdem univention-bind und univention-bind-proxy neu gestartet wurden.

Viele Grüße,
Dirk Ahrnke

Ich hab’s dank eurer Hilfe gelöst. :slight_smile:

Auf dem DC-Master habe ich die UCS-App Active Directory-kompatibler Domänencontroller installiert. Da sich sowieso die Windows-Arbeitsstationen nur anmelden, wenn der DC-Master bereits läuft, reichte mir das aus. Nur den anderen DC’s eben nicht, eigentlich logisch. Wie soll ein DC-Slave stellvertretend die Windows-Anmeldungen entgegennehmen ohne die App? So habe ich die App auch auf diesen jetzt installiert, Fehler weg.

Viele Grüße aus Dresden
Jens Büttner

Naja eigentlich nicht. Denn Bind sollte auch mit dem openLDAP-Backend funktionieren. Warum dies nicht klappte, wurde nicht geklärt.

Mastodon