BIND8 vergisst seine Forwarder
Hallo Liste! Ich habe folgendes Problem mit einem lokalen Nameserver, der via DSL im I-Net hängt: Der Server ist als DNS-Server für ein privates Netz (192.168.101.255) mit dem Namen hebi.prv eingerichtet. Er soll dabei neben der Auflösung der lokalen Adressen als Forwarder für Adressen im I-Net dienen. Wird named gestartet (manuell über rcnamed oder vom ip-up-Script aus), dann funktioniert alles so, wie es soll. Nach mehreren Minuten (so ca. 10) "vergißt" named aber offensichtlich seine Forwarder und liefert keine Ergebnisse mehr zurück :-( Umgebung: SuSE 7.2, Kernel 2.4.17 (SuSE-rpm) bind 8 (rpm : bind8-8.2.3-140) SuSE-Personal-Firewall (rpm: personal-firewall-1.1-4) Das innere Netz 192.168.101.255 ist nach außen maskiert, ansonsten kommt eigentlich nur SSH durch die Firewall. Der named wird bei jedem ip-up automatisch neu gestartet (keine Fehlermeldungen im Log!) Nach der DSL-Einwahl sieht /etc/rc.config so aus: search hebi.prv nameserver 192.168.101.2 <- IP des Servers nameserver 194.25.2.129 <- T-Online-DNS #nameserver 62.155.255.16 <- Backup-Inet-DNS /etc/named.conf hat folgende Einträge: zone "." IN { type hint; file "root.hint"; }; zone "localhost" IN { type master; file "localhost.zone"; check-names fail; allow-update { none; }; }; zone "prv" IN { type master; file "prv.zone"; check-names fail; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; check-names fail; allow-update { none; }; }; zone "hebi.prv" { type master; file "/var/named/hebi.prv.hosts"; }; zone "101.168.192.in-addr.arpa" { type master; notify no; file "/var/named/192.168.101.0.rev"; }; Ein nslookup von einem Client aus (Nameserver ist 192.168.101.2) funktioniert (innerhalb der 10 Minuten) fehlerfrei für innere und äußere Adressen, danach nur noch innere. Äußere liefern jetzt einen Timeout. Das Loging hat ebenfalls keine interessanten Erkenntnisse gebracht. Hoffe, das reicht ;-) Wer nimmt mir die Blinheit von den NAMED-Augen? Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
* Montag, 11. März 2002 um 20:58 (+0100) schrieb Dirk Hebenstreit:
Wird named gestartet (manuell über rcnamed oder vom ip-up-Script aus), dann funktioniert alles so, wie es soll. Nach mehreren Minuten (so ca. 10) "vergißt" named aber offensichtlich seine Forwarder und liefert keine Ergebnisse mehr zurück :-(
Umgebung: SuSE 7.2, Kernel 2.4.17 (SuSE-rpm) bind 8 (rpm : bind8-8.2.3-140) SuSE-Personal-Firewall (rpm: personal-firewall-1.1-4)
Das innere Netz 192.168.101.255 ist nach außen maskiert, ansonsten kommt eigentlich nur SSH durch die Firewall.
Ich kenne mich mit der Personal-Firewall nicht aus, aber um den Fehler einzugrenzen: Funktioniert es denn ohne Firewall?
Der named wird bei jedem ip-up automatisch neu gestartet (keine Fehlermeldungen im Log!)
Warum startest du den den named in ip-up?
Nach der DSL-Einwahl sieht /etc/rc.config so aus:
search hebi.prv nameserver 192.168.101.2 <- IP des Servers nameserver 194.25.2.129 <- T-Online-DNS #nameserver 62.155.255.16 <- Backup-Inet-DNS
/etc/resolv.conf nehme ich an...?
/etc/named.conf hat folgende Einträge:
Der "options"-Abschnitt wäre hier IMHO interessanter.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke wrote: ...
Ich kenne mich mit der Personal-Firewall nicht aus, aber um den Fehler einzugrenzen: Funktioniert es denn ohne Firewall?
Nein, gleiches Phänomen. ..
Warum startest du den den named in ip-up?
War so als Idee gedacht, um bei jeder Einwahl das Problem zu umgehen. Wenn ich aber länger als ca. 10 min online bin, dann bringt es eben nichts mehr. ...
/etc/resolv.conf nehme ich an...?
Ja, sorry.
/etc/named.conf hat folgende Einträge:
Der "options"-Abschnitt wäre hier IMHO interessanter.
Stimmt, habe ich als Antwort auf das Posting von Dieter Kluenter nochmal nachgeliefert. Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
Dirk Hebenstreit
Hallo Liste!
Ich habe folgendes Problem mit einem lokalen Nameserver, der via DSL im I-Net hängt: [...] Wird named gestartet (manuell über rcnamed oder vom ip-up-Script aus), dann funktioniert alles so, wie es soll. Nach mehreren Minuten (so ca. 10) "vergißt" named aber offensichtlich seine Forwarder und liefert keine Ergebnisse mehr zurück :-(
Er vergisst nicht die Forwarder, sondern löscht nur die cache Einträge.
Umgebung: SuSE 7.2, Kernel 2.4.17 (SuSE-rpm) bind 8 (rpm : bind8-8.2.3-140) SuSE-Personal-Firewall (rpm: personal-firewall-1.1-4)
Das innere Netz 192.168.101.255 ist nach außen maskiert, ansonsten kommt eigentlich nur SSH durch die Firewall. Der named wird bei jedem ip-up automatisch neu gestartet (keine Fehlermeldungen im Log!)
Das ist nicht gut, Port 53 udp und tcp sollte auch frei sein. Das automatische Neustarten des named kann dazu führen, dass er zu früh gestartet wird, d.h. die Verbindung besteht noch nicht.
Nach der DSL-Einwahl sieht /etc/rc.config so aus:
search hebi.prv nameserver 192.168.101.2 <- IP des Servers nameserver 194.25.2.129 <- T-Online-DNS #nameserver 62.155.255.16 <- Backup-Inet-DNS
Was hat das mit rc.config zu tun ? Ich vermute mal, dass soll /etc/resolv.conf heissen. Dann definierst du aber hier mehrere Nameserver, die vom Resolver befragt werden sollen, das sind aber keine Forwarding Anweisungen an named.
/etc/named.conf hat folgende Einträge:
zone "." IN {
type hint; file "root.hint"; };
[...]
zone "prv" IN { type master; file "prv.zone"; check-names fail; allow-update { none; }; }; [...]
Wie hast du denn die Forwarders in /etc/named.conf eingetragen, das ist doch viel wichtiger. Da sollte etwa folgendes stehen options { forwarders { 194.25.2.129; 62.155.255.16;} } -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Dieter Kluenter wrote: ...
Er vergisst nicht die Forwarder, sondern löscht nur die cache Einträge.
Hmm, und wie kommen diese in den Cache, bzw. warum wird der Cache geleert? Im Cache sollte doch auch nur das stehen, was ich schon mal abgefragt habe und dann sollte der Cache bei einer neuen Anfrage ja wieder gefüllt werden. ..
Das innere Netz 192.168.101.255 ist nach außen maskiert, ansonsten kommt eigentlich nur SSH durch die Firewall. Der named wird bei jedem ip-up automatisch neu gestartet (keine Fehlermeldungen im Log!)
Das ist nicht gut, Port 53 udp und tcp sollte auch frei sein.
Erg, ich möchte eigentlich nicht meinen Port 53 nach außen freigeben :-{ Baut named eine Verbindung zum Forwarder denn mit SRC 53 auf oder dynamisch?
Das automatische Neustarten des named kann dazu führen, dass er zu früh gestartet wird, d.h. die Verbindung besteht noch nicht.
Wenn ich rcnamed restart bei bestehender Verbindung aufrufe, dann geht es aber wieder (also auch bei komplett initialisierter Firewall), der Fehler sollte also eigentlich ehr in der named-Konfiguration liegen.
Nach der DSL-Einwahl sieht /etc/rc.config so aus:
search hebi.prv nameserver 192.168.101.2 <- IP des Servers nameserver 194.25.2.129 <- T-Online-DNS #nameserver 62.155.255.16 <- Backup-Inet-DNS
Was hat das mit rc.config zu tun ?
Nix, SCH* Cut&Paste - sorry!
Ich vermute mal, dass soll /etc/resolv.conf heissen. Dann definierst du aber hier mehrere Nameserver, die vom Resolver befragt werden sollen, das sind aber keine Forwarding Anweisungen an named.
...
Wie hast du denn die Forwarders in /etc/named.conf eingetragen, das ist doch viel wichtiger. Da sollte etwa folgendes stehen
options { forwarders { 194.25.2.129; 62.155.255.16;} }
Ja, man sollte solche Fragen nicht mit 38° Fieber vom Krankenbett aus posten :-( Ich habe beim Kopieren den options-Abschnitt vergessen, hier der Rest von named.conf: options { directory "/var/named"; check-names master warn; pid-file "/var/run/named.pid"; datasize default; stacksize default; coresize default; files unlimited; recursion yes; multiple-cnames no; forward only; forwarders { 62.155.255.16; 194.25.2.129; }; listen-on { 192.168.101.2; }; max-transfer-time-in 100; }; ... Liegt dort der Fehler? Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
Dirk Hebenstreit
Dieter Kluenter wrote:
...
Er vergisst nicht die Forwarder, sondern löscht nur die cache Einträge.
Hmm, und wie kommen diese in den Cache, bzw. warum wird der Cache geleert? Im Cache sollte doch auch nur das stehen, was ich schon mal abgefragt habe und dann sollte der Cache bei einer neuen Anfrage ja wieder gefüllt werden.
Beim Start von named werden zuerst die root-server nach top level domains abgefragt, dann werden die darunter liegenden Domains erfasst, das dauert etwa 2 -3 Minuten. Viele Eintraege haben nur eine kurze TTL, die werden dann wieder nach Ablauf der TTL aus dem cache entfernt.
..
Das innere Netz 192.168.101.255 ist nach außen maskiert, ansonsten kommt eigentlich nur SSH durch die Firewall. Der named wird bei jedem ip-up automatisch neu gestartet (keine Fehlermeldungen im Log!)
Das ist nicht gut, Port 53 udp und tcp sollte auch frei sein.F
Erg, ich möchte eigentlich nicht meinen Port 53 nach außen freigeben :-{ Nicht deinen Port nach draussen freigeben, sondern Verbindungen von Port 53 an 1024:
Baut named eine Verbindung zum Forwarder denn mit SRC 53 auf oder dynamisch?
Die Verbindung wird von sport 1024: an dport 53 aufgebaut, die Antwort kommt dann natürlich von sport 53 an dport 1024:
Das automatische Neustarten des named kann dazu führen, dass er zu früh gestartet wird, d.h. die Verbindung besteht noch nicht.
Wenn ich rcnamed restart bei bestehender Verbindung aufrufe, dann geht es aber wieder (also auch bei komplett initialisierter Firewall), der Fehler sollte also eigentlich ehr in der named-Konfiguration liegen.
OK, bei bestehender Verbindung, aber wie sieht es während des Verbindungsaufbaues aus? Wann wird named gestartet?
Wie hast du denn die Forwarders in /etc/named.conf eingetragen, das ist doch viel wichtiger.
Ja, man sollte solche Fragen nicht mit 38° Fieber vom Krankenbett aus posten :-( Ich habe beim Kopieren den options-Abschnitt vergessen, hier der Rest von named.conf:
Dann wünsche ich dir erst mal gute Besserung und lass die Finger von der Tastatur, die könntest uns anstecken :-)
options {
[...]
forward only;
Warum dass denn? Das schränkt dich aber sehr ein, was ist bei einem Timeout?
forwarders { 62.155.255.16; 194.25.2.129; };
listen-on { 192.168.101.2; }; max-transfer-time-in 100;
Und warum soll er nicht auf der dynamisch zugewiesenen Adresse auf Antwort der Forwarders lauschen ? In Verbindung mit 'recursion yes' führt dass dazu, dass dein Nameserver keine Authorität hat und daher auch nicht mehr vom Resolver befragt wird. Das wird dein Problem sein. :-) Nimm dein 'DNS und BIND' und lies noch einmal Kapitel 10 :-) Ich würde lieber den Nameserver auf allen Devices lauschen lassen, die Rekursion weglassen und stattdessen mit der 'allow-query' option die erlauben Frager einschänken. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Dieter Kluenter wrote:
Beim Start von named werden zuerst die root-server nach top level domains abgefragt, dann werden die darunter liegenden Domains erfasst, das dauert etwa 2 -3 Minuten. Viele Eintraege haben nur eine kurze TTL, die werden dann wieder nach Ablauf der TTL aus dem cache entfernt.
Das erklärt schon mal einiges. ...
Erg, ich möchte eigentlich nicht meinen Port 53 nach außen freigeben :-{
Nicht deinen Port nach draussen freigeben, sondern Verbindungen von Port 53 an 1024:
Gut, das sollte die Personal-Firewall ja machen: # iptabels -L ACCEPT udp -- nimrod.hebi.prv anywhere udp spt:domain ACCEPT udp -- dns.t-online.de anywhere udp spt:domain Upps, da fehlt auf jeden Fall tcp!
Die Verbindung wird von sport 1024: an dport 53 aufgebaut, die Antwort kommt dann natürlich von sport 53 an dport 1024:
Muß ich wohl eine eigene Regel für dns schreiben...
OK, bei bestehender Verbindung, aber wie sieht es während des Verbindungsaufbaues aus? Wann wird named gestartet?
Eigentlich wird er regulär im Runlevel gestartet, ich habe aber als Woraround ein "rcnamed restart" in ip-up aufgenommen.
Dann wünsche ich dir erst mal gute Besserung und lass die Finger von der Tastatur, die könntest uns anstecken :-)
Danke für den Tip, aber ich dachte, Viren können Linux nix anhaben ;-)
options {
[...]
forward only;
Warum dass denn? Das schränkt dich aber sehr ein, was ist bei einem Timeout?
Ich hatte die Doku für das Forwarding so interpretiert. Nicht O.K.?
forwarders { 62.155.255.16; 194.25.2.129; };
listen-on { 192.168.101.2; }; max-transfer-time-in 100;
Und warum soll er nicht auf der dynamisch zugewiesenen Adresse auf Antwort der Forwarders lauschen ? In Verbindung mit 'recursion yes' führt dass dazu, dass dein Nameserver keine Authorität hat und daher auch nicht mehr vom Resolver befragt wird. Das wird dein Problem sein. :-) Nimm dein 'DNS und BIND' und lies noch einmal Kapitel 10 :-)
Hm, meine Ausgabe kennt noch keinen BIND8 ;-) (Ich werde aber trotzdem nochmal die Theorie wälzen, irgendwie habe ich DNS doch noch nicht so richtig kapiert. Kommt wohl davon, wenn man mit einer Klick-Konfiguration anfängt (Webmin) und dann daran 'rumspielt.)
Ich würde lieber den Nameserver auf allen Devices lauschen lassen, die Rekursion weglassen und stattdessen mit der 'allow-query' option die erlauben Frager einschänken.
Teste ich! Danke! hebi
Hallo Dirk,
Dirk Hebenstreit
Dieter Kluenter wrote:
[...]
Und warum soll er nicht auf der dynamisch zugewiesenen Adresse auf Antwort der Forwarders lauschen ? In Verbindung mit 'recursion yes' führt dass dazu, dass dein Nameserver keine Authorität hat und daher auch nicht mehr vom Resolver befragt wird. Das wird dein Problem sein. :-) Nimm dein 'DNS und BIND' und lies noch einmal Kapitel 10 :-)
Hm, meine Ausgabe kennt noch keinen BIND8 ;-) (Ich werde aber trotzdem nochmal die Theorie wälzen, irgendwie habe ich DNS doch noch nicht so richtig kapiert. Kommt wohl davon, wenn man mit einer Klick-Konfiguration anfängt (Webmin) und dann daran 'rumspielt.)
Auch deine alte Ausgabe kennt schon recursion :-) Ein paar Bemerkungen zu recursion, dies ist nur sinnvoll bei Root Servern. Ich zitier mal aus der deutschen Ausgabe von DNS und BIND, "Soll einer Ihrer Nameserver nichtrekursiv arbeiten, dürfen Sie ihn in keiner Ihrer resolv.conf irgendeines Hosts aufnehmen. Zwar können Sie dafür sorgen, daß Ihr Nameserver nichtrekursiv arbeitet, aber es gibt keine entsprechende Option, mit der Sie einen Resolver dazu bringen könnten, mit einem nichtrekursiven Nameserver zu arbeiten." -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo Dieter! Am 12 Mar 2002 21:46:52 +0100 schrieb Dieter Kluenter:
Ich zitier mal aus der deutschen Ausgabe von DNS und BIND,
"Soll einer Ihrer Nameserver nichtrekursiv arbeiten, dürfen Sie ihn in keiner Ihrer resolv.conf irgendeines Hosts aufnehmen. Zwar können Sie dafür sorgen, daß Ihr Nameserver nichtrekursiv arbeitet, aber es gibt keine entsprechende Option, mit der Sie einen Resolver dazu bringen könnten, mit einem nichtrekursiven Nameserver zu arbeiten."
Kannst Du mir sagen, wo ich eine deutsche Ausgabe zu BIND und DNS finde? Gruß -- Andreas Meyer http://home.wtal.de/MeineHomepage
Hallo Andreas,
Andreas Meyer
Hallo Dieter!
Am 12 Mar 2002 21:46:52 +0100 schrieb Dieter Kluenter:
Ich zitier mal aus der deutschen Ausgabe von DNS und BIND,
"Soll einer Ihrer Nameserver nichtrekursiv arbeiten, dürfen Sie ihn in keiner Ihrer resolv.conf irgendeines Hosts aufnehmen. Zwar können Sie dafür sorgen, daß Ihr Nameserver nichtrekursiv arbeitet, aber es gibt keine entsprechende Option, mit der Sie einen Resolver dazu bringen könnten, mit einem nichtrekursiven Nameserver zu arbeiten."
Kannst Du mir sagen, wo ich eine deutsche Ausgabe zu BIND und DNS finde? Klar, bei Lehmanns. In Hamburg habe ich es da einfach, da Lehmanns zweimal vertreten ist, gibt es aber auch in etlichen anderen Uni Städten, speziell mit grosser medizinischer Fakultät. Sonst online
http://www.lob.de Suche nach 'DNS und BIND, Deutsche Ausgabe, Paul Albitz & Cricket Liu, O'Reilly, Deutsche Übersetzung von Andreas Roeschies & Peter Klicman' -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
participants (4)
-
Andreas Koenecke
-
Andreas Meyer
-
Dieter Kluenter
-
Dirk Hebenstreit