UCS bind akzeptiert forward-Zone nicht

german

#1

Hallo an alle!

Ich habe gem. diesem Post eine Forward Zone eingerichtet.
So habe ich eine interne Sichtbarkeit der Server in der Forward-Zone. Und für diese Zone werden die öffentlichen DNS-Server dann ja nicht gefragt.
Die Datei /etc/bind/local.conf.samba4 enthält u.a.:

zone "intern.de" {
        type forward;
        forwarders { 192.168.1.1;};
};

Nach einem Neustart funktioniert das Ganze auch. Aber irgendwann liefert der lokale UCS dann doch die öffentlichen Informationen.

So soll es aussehen:

root@ucs:/var/log# dig ba.intern.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ba.intern.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37195
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;ba.intern.de. IN   A

;; ANSWER SECTION:
ba.intern.de. 900 IN A      192.168.1.34

;; AUTHORITY SECTION:
ba.intern.de. 900     IN      NS      dns.intern.de.

;; ADDITIONAL SECTION:
dns.intern.de. 900 IN   A       192.168.1.10

;; Query time: 50 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar  8 14:48:27 2017
;; MSG SIZE  rcvd: 103

Und so sieht es nach einer Weile aus:

[code]root@ucs:/var/log# dig ba.intern.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ba.intern.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25177
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;ba.intern.de. IN A

;; ANSWER SECTION:
ba.intern.de. 73466 IN A 188.34.36.249

;; AUTHORITY SECTION:
intern.de. 73440 IN NS third-dns.netcup.net.
intern.de. 73440 IN NS root-dns.netcup.net.
intern.de. 73440 IN NS second-dns.netcup.net.

;; ADDITIONAL SECTION:
root-dns.netcup.net. 6572 IN A 46.38.225.225
third-dns.netcup.net. 6572 IN A 188.68.63.68
second-dns.netcup.net. 6572 IN A 37.221.199.199

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 8 14:46:09 2017
;; MSG SIZE rcvd: 196
[/code]

Im syslog sind keinerlei Auffälligkeiten zu sehen.
Dann mache ich:

invoke-rc.d univention-bind restart
invoke-rc.d univention-bind-proxy restart

…und dann ist alles wieder ok.
Warum “vergißt” er nach einer Weile immer den Forwarder?

Danke!

/KNEBB


#2

Hallo,

beim ersten Lesen bin ich erstmal darüber gestolpert, dass auf die “dig”-Anfragen bei Ihnen 127.0.0.1 antwortet. Ich sehe sonst bei UCS (und das scheint ja lokal auf dem UCS abgefragt) eigentlich immer die Public-IP (aus UCRV nameserver1 bis nameserver3).

Ansonsten würde ich aber als nächstes das Debugging gemäß des zitierten Wiki-Artikels hochsetzen und schauen, ob sich etwas findet. Oder einen cronjob aufsetzen der regelmäßig die Zone abfragt um zumindest eine zeitliche Zuordnung des Problems zu finden.

Viele Grüße,
Dirk Ahrnke


#3

Auch wenn der Thread etwas älter ist. Domains enden immer mit einem Punkt.


#4

Ohne nähere Erläuterung, auf welche Einstellung sich diese Aussage im Kontext bezieht, ist Ihr Einwurf eher irritierend.


#5

Seine Zone-Config ganz oben.


#6

Wenn man meckert, sollte man wissen, wovon man redet.

Die Config ist absolut in Ordnung.
Beispiel aus dem Administrator-manual direkt von ISC (siehe https://www.isc.org/bind-9-11-arm/) und hierbei spielt es keine Rolle, ob forward oder master.

// We are the master server for example.com
   zone "example.com" {
   type master;
   file "example.com.db";
};

Das funktioniert problemlos, weil der Eintrag ja eben “zone” ist und der bind dadurch weiß, dass es sich um eine Zone handelt und nicht um einen Host (an den man ggf. ohne einen “.” tatsächlich noch die Zone ranfügen würde).

Also bitte meckern zum Einen nur, wenn man genau weiß worum es geht und zum Zweiten, wenn man das auch konkret korrigieren kann.