Hi,
ich habe einen “Externer DNS-Server”, in dem Fall unseren Router, in UCS gesetzt (UCR dbs/forwarder1) Nun kann ich DNS Einträge vom Router auch von der UCS Maschine erreichen. Von den Clients aber leider nicht. Das heisst UCS gibt die DNS Anfrage eines Clients nicht an den Router weiter. Nur leider keine Ahnung warum nicht. muss ich das noch irgendwo explizit erlauben?
Hallo,
“dbs/forwarder1” ist vermutlich nur ein Typo in Ihrem Post.
Meine erste Frage wäre demnach die, mit welchen Methoden Sie auf dem Server getestet haben und wie sichergestellt wurde, dass die Clients auch wirklich den UCS als DNS verwenden.
Für den Test auf dem Server empfehle ich “dig” (siehe z.B. http://www.thegeekstuff.com/2012/02/dig-command-examples). Dort sehen Sie in der “SERVER:” Zeile die IP des Systems, welches Ihnen geantwortet hat. Ohne Angabe eines Servers bei Dig wird das in der UCRV “nameserver1” angegebene System befragt. Normalerweise steht da erstmal die DC-Master. Und den sollten in der einfachsten Installationsweise auch die Clients benutzen und ohne zusätzliche Freischaltung befragen können.
Viele Grüße,
Dirk Ahrnke
Hi,
es scheint irgendwie an der Domain “quark.intern” zu liegen, ganz kurz nach dem der bind neugestartet wurde funktioniert der zugriff…
hier die dig ausgauben kurz nach neustart:
root@ucs:/home/Administrator# service bind9 restart
root@ucs:/home/Administrator# dig quark.intern
; <<>> DiG 9.9.5-9+deb8u6A~4.2.0.201702281603-Debian <<>> quark.intern
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7180
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;quark.intern. IN A
;; ANSWER SECTION:
quark.intern. 120000 IN A 172.16.1.21
;; AUTHORITY SECTION:
. 119998 IN NS Goerlitz.gr.gc.
;; ADDITIONAL SECTION:
Goerlitz.gr.gc. 900 IN A 192.168.200.1
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 06 12:03:45 CEST 2017
;; MSG SIZE rcvd: 100
paar sekunden später:
root@ucs:/home/Administrator# dig quark.intern
; <<>> DiG 9.9.5-9+deb8u6A~4.2.0.201702281603-Debian <<>> quark.intern
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31140
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;quark.intern. IN A
;; AUTHORITY SECTION:
. 2135 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017090600 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 06 12:04:22 CEST 2017
;; MSG SIZE rcvd: 116
Vielen Dank!
Den Ausgaben kann ich zunächst nur folgendes entnehmen:
Ich finde es zwar ungewöhnlich, dass “localhost” befragt wird - bislang habe ich nur gesehen, dass in der o.g. UCRV (und damit in /etc/resolv.conf) eines Masters seine primäre Public-IP steht - grundsätzlich solte das aber für das aktuelle Problem nicht von Belang sein.
Es gilt zunächst, herauszufinden, was den Bind dazu bewegt, plötzlich NXDOMAIN zu liefern.
Also Logs schauen, in /var/log: messages, syslog und daemon.log
dns/backend ist natürlich auch wichtig, wenn Sie Samba 4 betreiben, stellt dieser per default die DNS-Informationen.
dns/backend ist samba4…
die logs liefern leider nichts aussagefähiges… was mich doch noch viel mehr stutzig macht. bind setzt erst NXDOMAIN nach die Seite einmal aufgerufen wurde. Solange die Webseite NICHT aufgerufen wird, stimmt der DNS!!!
Ist das so reproduzierbar? Also wirklich mit der Reihenfolge
Weiterhin sollte man mal schauen, ob es wirklich an dieser einen Domain liegt und der Bind sich normal verhält, wenn man diese Domain nicht abfragt. Wenn dem so wäre, müssten wir wissen, was dies für eine Domäne ist. Wäre es zum Beispiel die lokale vom Samba verwaltete Domäne, müsste man schauen, ob sich in den Samba-Logs etwas findert. Oder testweise mal das DNS-Backend umschalten (Doku beachten).
Hi,
ja ist reproduzierbar. ich kann egal welche domain nehmen, alles was auf .intern endet verhält sich so. Jede andere Domain verhält sich ganz normal und wird auch ordentlich weiter geleitet.
Das Verhalten des Binds ändern sich für die .intern Domain auch erst nach dem die Webseite geladen wurde oder ein Telnet auf Port 80 zum Beispiel erfolgte.
Man soll nie “nie” sagen, aber eine Abhängigkeit von Anfragen an den Webserver zum beschriebenen Verhalten des DNS erscheint mir erstmal etwas weit weg. Ich würde denken, dass durch die http-requests DNS-Anfragen ausgelöst werden. Das sollte man auch ohne Browser wie beschrieben reproduzieren können.
Die Aussage “alles, was aus .intern endet verhält sich so” wäre ebenfalls ergänzungswürdig. Sie hatten oben das Beispiel mit “quark.intern” angeführt. Ist das ein von Ihnen definiert Rechnername? Heißt die Zone somit “.intern”?
Und was hat der antwortende DNS goertlitz.gr.gc mit der Sache zu tun? Zumal der UCS ja auch “ucs” heißt.