Nameserver sind nicht ansprechbar

german

#1

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.


#2

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.


#3

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


#4

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

nslookup google.com 192.168.0.10

#5

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

#6

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


#7

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

#8

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/*?


#9

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:~#

#10

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


#11

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

#12

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


#13

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


#14

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