bind9, dig und NXDOMAIN
Hallo Liste Unter SuSE 9 und bind 9.2-2-25 werden alle Anfragen mit dig (vermutlich) sofort an die Internet-NS weitergeleitet und daher werden lokale Namen nicht gefunden. Nach meinem Verständnis, sollten zuerst die lokalen Zonen beantwortet werden und erst später die externen. Aenderungen bei /etc/resolv.conf "name resolve order" hatten keine Wirkung. Merkwürdigerweise gehen nur die Vorwärts-Anfragen (ausser localhost) nicht: dig localhost OK dig -x 127.0.0.1 OK dig -x 192.168.200.212 OK (ist die Machine linuxtest) dig linuxtest NXDOMAIN (Fehler) dig @192.168.200.212 localhost OK dig @192.168.200.212 linuxtest NXDOMAIN (Fehler) Ich finde den Fehler nicht. Es ist keine Firewall in Betrieb. # /etc/named.conf options { directory "/var/lib/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; #forwarders { 192.0.2.1; 192.0.2.2; }; #forward first; #listen-on port 53 { 127.0.0.1; }; listen-on-v6 { any; }; #query-source address * port 53; #transfer-source * port 53; #notify-source * port 53; #allow-query { 127.0.0.1; }; #notify no; }; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; zone "200.168.192.in-addr.arpa" in { type master; file "master/200.168.192.in-addr.arpa.zone"; }; zone "example.net" in { type master; file "master/example.net.zone"; }; 200.168.192.in-addr.arpa.zone: $TTL 2D 200.168.192.in-addr.arpa. IN SOA linuxtest.example.net. hostmaster.example.net. ( 1999092903 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS linuxtest.example.net. 1 IN PTR test.example.net. 101 IN PTR test1.example.net. 102 IN PTR test2.example.net. 212 IN PTR linuxtest.example.net. example.net.zone: $TTL 2D example.net. IN SOA localhost.example.net. hostmaster.example.net. ( 1999092902 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS localhost IN MX 10 localhost localhost IN A 192.168.200.212 linuxtest IN A 192.168.200.212 IN A 192.168.200.1 test1 IN A 192.168.200.101 test2 IN A 192.168.200.102 www IN CNAME localhost ftp IN CNAME localhost Sorry, war mit einem ähnlichen Problem schon mal da. Hoffentlich weiss jemand Rat. Komme wirklich hier nicht mehr weiter. Herzlichen Dank für jeden Tipp. -- Bernhard
Bernhard Buehler wrote:
dig localhost OK dig -x 127.0.0.1 OK dig -x 192.168.200.212 OK (ist die Machine linuxtest) dig linuxtest NXDOMAIN (Fehler) dig @192.168.200.212 localhost OK dig @192.168.200.212 linuxtest NXDOMAIN (Fehler)
Wie sieht es denn aus, wenn du den FQDN von einem Rechner nimmst? In meinem Schädel brütet dumpf die Erinnerung an eine search domain bzw. eine Einstellung, dass eine Domain standardmäßig bei Rechnernamen angehängt wird für die Auflösung. Kann auch sein, dass dies eine Option für den DHCP-Server ist, die gesetzt werden kann. Sandy
Hallo Sandy danke für deine Antwort. Bin leider bisher mit Allem nicht weitergekommen. Grüsse Bernhard Am Donnerstag, 17. Februar 2005 11.58 schrieb Sandy Drobic:
Bernhard Buehler wrote:
dig localhost OK dig -x 127.0.0.1 OK dig -x 192.168.200.212 OK (ist die Machine linuxtest) dig linuxtest NXDOMAIN (Fehler) dig @192.168.200.212 localhost OK dig @192.168.200.212 linuxtest NXDOMAIN (Fehler)
Wie sieht es denn aus, wenn du den FQDN von einem Rechner nimmst? In meinem Schädel brütet dumpf die Erinnerung an eine search domain bzw. eine Einstellung, dass eine Domain standardmäßig bei Rechnernamen angehängt wird für die Auflösung. Kann auch sein, dass dies eine Option für den DHCP-Server ist, die gesetzt werden kann.
Sandy
Hallo Peter danke für deine Antwort. Bisher bin ich noch nicht weitergekommen. Grüsse Bernhard Am Donnerstag, 17. Februar 2005 12.15 schrieb Peter Wiersig:
On Thu, Feb 17, 2005 at 11:12:09AM +0100, Bernhard Buehler wrote:
Merkwürdigerweise gehen nur die Vorwärts-Anfragen (ausser localhost) nicht:
dig linuxtest NXDOMAIN (Fehler)
dig -h: ... +[no]search (Set whether to use searchlist)
also "dig +search linuxtest"
--
Hallo Liste Hallo Bernhard Unter SuSE 9 und bind 9.2-2-25 Ach so der Bind ist Dein Feind werden alle Anfragen mit dig (vermutlich) was heist vermutlich? ein tcpdump bringt Gewissheit, an wen welches Paket gerichtet ist. In deinem Fall tcpdump -i eth0 port 53 and -p udp sofort an die Internet-NS weitergeleitet und daher werden lokale Namen nicht gefunden. Nach meinem Verständnis, sollten zuerst die lokalen Zonen beantwortet werden und erst später die externen. Aenderungen richtig, das kann mann auch den bind machen lassen "forwarders" bei /etc/resolv.conf "name resolve order" hatten keine Wirkung. Merkwürdigerweise gehen nur die Vorwärts-Anfragen (ausser localhost) nicht: dig localhost OK dig -x 127.0.0.1 OK dig -x 192.168.200.212 OK (ist die Machine linuxtest) dig linuxtest NXDOMAIN (Fehler) dig linuxtest.example.net
oder host linuxtest wobei in deiner resolv.conf dann folgendes stehen muss search example.net nameserver 192.168.200.212
dig @192.168.200.212 localhost OK dig @192.168.200.212 linuxtest NXDOMAIN (Fehler)
Ich finde den Fehler nicht. Es ist keine Firewall in Betrieb.
# /etc/named.conf options { directory "/var/lib/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; #forwarders { 192.0.2.1; 192.0.2.2; }; benutze forwarders forwarders { 135.4.56.7; 212.45.22.11; }; Du musst Deine eintragen, die Dir Dein ISP beim login ins Internet übergibt #forward first; #listen-on port 53 { 127.0.0.1; }; listen-on-v6 { any; }; benutzt du ipv6 ? wenn nicht, dann weg damit #query-source address * port 53; #transfer-source * port 53; #notify-source * port 53; #allow-query { 127.0.0.1; }; #notify no; }; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone"; forwarders {}; #localhost wird nicht forgewardet }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; forwarders {}; }; zone "200.168.192.in-addr.arpa" in { type master; file "master/200.168.192.in-addr.arpa.zone"; forwarders {} }; zone "example.net" in { type master; file "master/example.net.zone"; forwarders {}; }; zusätzlich solltest du noch die zonen "0.in-addr.arpa" und "255.in-addr.arpa" mit aufnehmen und anlegen
200.168.192.in-addr.arpa.zone: $TTL 2D 200.168.192.in-addr.arpa. IN SOA linuxtest.example.net. hostmaster.example.net. ( korrekt muss das heißen hostmaster.linuxtest.example.net. ( oder die ganze zeile in kurzer schreibweise @ IN SOA linuxtest. hostmaster.linuxtest. ( 1999092903 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
IN NS linuxtest.example.net.
1 IN PTR test.example.net. 101 IN PTR test1.example.net. 102 IN PTR test2.example.net. 212 IN PTR linuxtest.example.net.
example.net.zone: $TTL 2D example.net. IN SOA localhost.example.net. hostmaster.example.net. ( @ IN SOA linuxtest. hostmaster.linuxtest. ( 1999092902 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
IN NS localhost IN NS linuxtest.example.net. der localhost hat hier nichts zu suchen dafür hast du doch in der named.conf extra die beiden zonen "localhost" und "0.0.127.in-addr.arpa" deklariert IN MX 10 localhost IN MX 10 linuxtest.example.net. hast du wirklich einen zentralen Mailserver laufen ?
localhost IN A 192.168.200.212 localhost benutzt den 127.0.0.0/8 Adressraum linuxtest IN A 192.168.200.212 test1 IN A 192.168.200.101 test2 IN A 192.168.200.102
www IN CNAME localhost www IN CNAME linuxtest.example.net. ftp IN CNAME localhost ftp IN CNAME linuxtest.example.net
Sorry, war mit einem ähnlichen Problem schon mal da. Hoffentlich weiss Welches war das? Hab es anscheinend überlesen. jemand Rat. Komme wirklich hier nicht mehr weiter. Herzlichen Dank für jeden Tipp. Mir scheinst, dass Du hier einiges durcheinanderwirfst. im übrigen solltest Du nach editieren der named.conf und einer Zone einen syntaxcheck machen named-chechconf /etc/named.conf named-checkzone <zonenname> /<pfad der zonendatei> hilfreich ist es auch manchmal den nameserver im debugmodus zu starten named -f -c /etc/named.conf -g -d 1
nichts zu danken und viel Erfolg Jerome
Hallo Jerome Danke für deine ausführliche Hilfe. Ich bin damit (noch) nicht sehr viel weitergekommen. Die von mir angegebene Konfiguration verwendete ich nur zum Test und weil ich keine produktiven Dateien ins Netz stellen wollte. Ich erlaube mir, dich mal weiter zu fragen: Ein primäres Problem ist die Tatsache, dass ich in einem lokalen Netz für MS-Clients einen dyn. Nameserver für Netbios benötige, weil der WINS irgendwie nicht befriedigt. Sagen wir mal es handle ich um www.muster.ch. Im lokalen Netzwerk gibt es genau das Gleiche nämlich auch muster.ch. So gesehen würde meine testmaschine linuxtest.muster.ch heissen. Wenn ich jetzt mit dig oder nslookup nach linuxtest frage, geht der Weg direkt ins Internet und der für die Domän zuständige NS (des Providers) kennt die Maschine linuxtest natürlich nicht. Das Problem (scheint) immer noch zu sein, dass der lokale NS nicht zuerst auch lokal sucht. Mit dem tcpdump wird das Interface "lo" und nicht das "eth0" abgefragt, was ich nicht verstehe. Es könnte aber auch daran liegen, dass der lokale NS die zone nicht richtig lesen kann und daher meint er müssen den nächsten Bruder (auf dem Internet) befragen. Leider weiss ich hier über die Zusammenhänge nicht genügend. Bitte schau dir mal hier den named-checkzone an: nochmals die Zone example.net: $TTL 2D example.net. IN SOA linuxtest.example.net. hostmaster.linuxtest.example.net. ( 1999092908 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS linuxtest linuxtest IN A 192.168.200.212 test1 IN A 192.168.200.101 test2 IN A 192.168.200.102 www IN CNAME localhost ftp IN CNAME localhost linuxtest:/var/lib/named/master # named-checkzone example.net.zone /var/lib/named/master/example.net.zone dns_master_load: /var/lib/named/master/example.net.zone:2: ignoring out-of-zone data (example.net) zone example.net.zone/IN: could not find NS and/or SOA records zone example.net.zone/IN: has 0 SOA records zone example.net.zone/IN: has no NS records Warum finded er nichts. Im Startup (Debug-Modus) schreibt er nichts was nicht stimmt oder fehlt. Ich benatworte trotzdem mal noch die ganze Nachricht.. Am Donnerstag, 17. Februar 2005 13.18 schrieb Jerome Reinert:
Hallo Liste
Hallo Bernhard
Unter SuSE 9 und bind 9.2-2-25
Ach so der Bind ist Dein Feind nein im Gegenteil, ich bemühe mich um Freundschaft, bisher nicht mit grossem Erfolg. Zuletzt hatte ich mit Vs. 8 zu tun, da waren wir "noch Freunde".
werden alle Anfragen mit dig (vermutlich)
was heist vermutlich? ein tcpdump bringt Gewissheit, an wen welches Paket gerichtet ist. In deinem Fall tcpdump -i eth0 port 53 and -p udp s. oben
sofort an die Internet-NS weitergeleitet und daher werden lokale Namen
nicht gefunden. Nach meinem Verständnis, sollten zuerst die lokalen Zonen beantwortet werden und erst später die externen. Aenderungen
richtig, das kann mann auch den bind machen lassen "forwarders"
bei /etc/resolv.conf "name resolve order" hatten keine Wirkung. Merkwürdigerweise gehen nur die Vorwärts-Anfragen (ausser localhost) nicht: dig localhost OK dig -x 127.0.0.1 OK dig -x 192.168.200.212 OK (ist die Machine linuxtest) dig linuxtest NXDOMAIN (Fehler)
dig linuxtest.example.net
oder
host linuxtest wobei in deiner resolv.conf dann folgendes stehen muss search example.net nameserver 192.168.200.212
dig @192.168.200.212 localhost OK dig @192.168.200.212 linuxtest NXDOMAIN (Fehler)
Ich finde den Fehler nicht. Es ist keine Firewall in Betrieb.
# /etc/named.conf options { directory "/var/lib/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; #forwarders { 192.0.2.1; 192.0.2.2; };
benutze forwarders forwarders { 135.4.56.7; 212.45.22.11; }; Du musst Deine eintragen, die Dir Dein ISP beim login ins Internet übergibt habe ich absichtlich nicht eingetragen, um ein "Abschweifen" nach aussen zu verhindern.
#forward first; #listen-on port 53 { 127.0.0.1; }; listen-on-v6 { any; };
benutzt du ipv6 ? wenn nicht, dann weg damit OK
#query-source address * port 53; #transfer-source * port 53; #notify-source * port 53; #allow-query { 127.0.0.1; }; #notify no; }; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone";
forwarders {}; #localhost wird nicht forgewardet habe alle forwarders so eingetragen
}; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone";
forwarders {};
}; zone "200.168.192.in-addr.arpa" in { type master; file "master/200.168.192.in-addr.arpa.zone";
forwarders {}
}; zone "example.net" in { type master; file "master/example.net.zone";
forwarders {};
};
zusätzlich solltest du noch die zonen "0.in-addr.arpa" und "255.in-addr.arpa" mit aufnehmen und anlegen kannst du mir erklären warum und wie der Inhalt auszusehen hätte?
200.168.192.in-addr.arpa.zone: $TTL 2D 200.168.192.in-addr.arpa. IN SOA linuxtest.example.net. hostmaster.example.net. (
korrekt muss das heißen hostmaster.linuxtest.example.net. ( oder die ganze zeile in kurzer schreibweise @ IN SOA linuxtest. hostmaster.linuxtest. (
1999092903 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
IN NS linuxtest.example.net.
1 IN PTR test.example.net. 101 IN PTR test1.example.net. 102 IN PTR test2.example.net. 212 IN PTR linuxtest.example.net.
example.net.zone: $TTL 2D example.net. IN SOA localhost.example.net. hostmaster.example.net. (
@ IN SOA linuxtest. hostmaster.linuxtest. (
1999092902 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
IN NS localhost
IN NS linuxtest.example.net. der localhost hat hier nichts zu suchen dafür hast du doch in der named.conf extra die beiden zonen "localhost" und "0.0.127.in-addr.arpa" deklariert Weiss ich eigentlich, ist mir bei den Tests so reingerutscht.
IN MX 10 localhost
IN MX 10 linuxtest.example.net. hast du wirklich einen zentralen Mailserver laufen ? hatte nur das SuSE-Muster 1:1 so übernommen
localhost IN A 192.168.200.212
localhost benutzt den 127.0.0.0/8 Adressraum
linuxtest IN A 192.168.200.212 test1 IN A 192.168.200.101 test2 IN A 192.168.200.102
www IN CNAME localhost
www IN CNAME linuxtest.example.net.
ftp IN CNAME localhost
ftp IN CNAME linuxtest.example.net
Sorry, war mit einem ähnlichen Problem schon mal da. Hoffentlich weiss
Welches war das? Hab es anscheinend überlesen.
jemand Rat. Komme wirklich hier nicht mehr weiter. Herzlichen Dank für jeden Tipp.
Mir scheinst, dass Du hier einiges durcheinanderwirfst. im übrigen solltest Du nach editieren der named.conf und einer Zone einen syntaxcheck machen named-chechconf /etc/named.conf war OK named-checkzone <zonenname> /<pfad der zonendatei> s. oben hilfreich ist es auch manchmal den nameserver im debugmodus zu starten named -f -c /etc/named.conf -g -d 1 habe ich so laufen
nichts zu danken und viel Erfolg
Jerome
Unter dem Motto "gib den kleinen Finger...." herzlichen Dank Bernhard
Danke an Alle die hier mitgeholfen haben den Fall zu lösen. Grüsse Bernhard
participants (4)
-
Bernhard Buehler -
Jerome Reinert -
Peter Wiersig -
Sandy Drobic