Bind löst Namen auf dem Server nicht auf
Hallo, Bind 8 löst neuerdings keine Namen auf dem lokalen Server auf. Unter Suse 7.3 funktionierte es bestens, nach dem Update auf Suse 8 gibt es seit einiger Zeit kleinere Probleme (fiel Anfangs auch noch nicht auf, da keine Namensbasierten virt. Domains aufgesetz waren). 1. Der NS ist localhost. Namen auf diesem Rechner werden nicht aufgelöst. Von den anderen Rechnern im Netz werden die Namen aber akzeptiert, in der /etc/host stehen die Namen nicht drin, ergo sollte der NS funktionieren.. 2. Der Rechner geht bei _jeder_ Anfrage online, negiert die lokalen Adressen. Meine Vermutung ist ein Routingproblem, da localhost in der Suse 8 ein eignes netzwerkinterface (?) lo bekommen hat. Da funzt wohl etwas nicht mit dem localhost, und da er den NS nicht findet (?), geht er online. In der routes Datei steht. default 127.0.0.1 - - nach Eingabe von route -N erhalte ich folgendes: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ippp0 irgendwo fehlt mir da das lo. Könnte mir da bitte jemand helfen? Danke, Herbert
Hallo Herbert, zeig uns doch mal deine Konfigurationsdateien vom Bind und die Ausgaben von tail -f /var/log/messages, nachdem Du den Bind neugestartet hast... das Loopbackdevice hat sicherlich auch vor SuSE 8.0 ein eigenes Interface gehabt! Wie sieht deine Resolv.conf aus? Fürs Loopback Device brauchsts eigentlich kein Routingeintrag! Hast Du Forwarders definiert? Gruß Sebastian www.wolfgarten.com
Am Sonntag, 12. Mai 2002 20:53 schrieb Sebastian Wolfgarten:
Hallo Herbert,
zeig uns doch mal deine Konfigurationsdateien vom Bind und die Ausgaben von tail -f /var/log/messages, nachdem Du den Bind neugestartet hast... das Loopbackdevice hat sicherlich auch vor SuSE 8.0 ein eigenes Interface gehabt! Wie sieht deine Resolv.conf aus? Fürs Loopback Device brauchsts eigentlich kein Routingeintrag! Hast Du Forwarders definiert?
Hallo, anbei mal die Inhalte der Config-Files. Ich hoffe, Ihr könnt mir helfen. # /etc/resolv.conf nameserver 127.0.0.1 nameserver 192.168.100.10 nameserver 62.104.196.134 search local sonne.local # tail -f /val/log/messages May 13 09:13:21 sonne kernel: isdn_net: ippp0 connected May 13 09:13:21 sonne ipppd[434]: Remote message: May 13 09:13:21 sonne ipppd[434]: MPPP negotiation, He: No We: No May 13 09:13:21 sonne ipppd[434]: CCP enabled! Trying CCP. May 13 09:13:21 sonne ipppd[434]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol) May 13 09:13:21 sonne ipppd[434]: ccp_resetci! May 13 09:13:21 sonne ipppd[434]: local IP address 213.7.74.63 May 13 09:13:21 sonne ipppd[434]: remote IP address 62.104.204.32 May 13 09:13:21 sonne modify_resolvconf: Service ipppd modified /etc/resolv.conf. See info block in this file May 13 09:14:20 sonne isdnlog: May 13 09:14:20 tei 92 calling +49 101901929, with +49 xxxxxx 2.CI 0.184 EUR (after 0:01:00) nachfolgende Konfiguration hat unter Suse 7.3 bestens funktioniert. Daher meine Vermutung, dass es am Routing liegen _könnte_ . (Trennungen mit Tabs erfolgt.) # /etc/named.conf configuration for BIND8 options { directory "/var/named"; forwarders { }; forward first; listen-on { 127.0.0.1; 192.168.100.10; }; #query-source address * port 53 allow-query { 127.0/16; 192.168.100/24; }; #allow-transfer {! *;}; cleaning-interval 120; statistics-interval 0; notify no; }; zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; zone "sonne.local" in { type master; file "sonne.zone"; }; zone "100.168.192.in-addr.arpa" in { type master; file "192.168.100.zone"; notify no; }; zone "." in { type hint; file "root.hint"; }; # sonne.zone $TTL 2D sonne.local. IN SOA localhost. root.localhost. ( 2002021617 1D 2H 1W 2D ) sonne.local. IN NS localhost. IN MX 10 sonne sonne.sonne.local. IN A 192.168.100.10 mond.sonne.local. IN A 192.168.100.20 mars.sonne.local. IN A 192.168.100.40 erde.sonne.local. IN A 192.168.100.90 pluto.sonne.local. IN A 192.168.100.10 jupi.sonne.local. IN A 192.168.100.10 saturn.sonne.local. IN A 192.168.100.10 # 192.168.100.zone $TTL 2D 100.168.192.in-addr.arpa. IN SOA localhost. root.localhost. ( 2002021625 1D 2H 1W 2D ) IN NS localhost. 10.100.168.192.in-addr.arpa. IN PTR sonne.sonne.local. 20.100.168.192.in-addr.arpa. IN PTR mond.sonne.local. 40.100.168.192.in-addr.arpa. IN PTR mars.sonne.local. 90.100.168.192.in-addr.arpa. IN PTR erde.sonne.local. 10.100.168.192.in-addr.arpa. IN PTR pluto.sonne.local. 10.100.168.192.in-addr.arpa. IN PTR jupi.sonne.local. 10.100.168.192.in-addr.arpa. IN PTR saturn.sonne.local. # 127.0.0.zone $TTL 2D @ IN SOA localhost. root.localhost. ( 42 ; serial (d. adams) 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS localhost. 1 IN PTR localhost. # localhost.zone $TTL 2D @ IN SOA @ root ( 42 ; serial (d. adams) 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS @ IN A 127.0.0.1 (Die anderen beiden Files spare ich mir an dieser Stelle)
Hi, ich habe zwar bisher nix im Thread gesagt, aber: On 13 May 2002 at 9:21, Herbert Schrader wrote:
Am Sonntag, 12. Mai 2002 20:53 schrieb Sebastian Wolfgarten: [...] anbei mal die Inhalte der Config-Files. Ich hoffe, Ihr könnt mir helfen.
# /etc/resolv.conf nameserver 127.0.0.1 nameserver 192.168.100.10 nameserver 62.104.196.134 search local sonne.local
IMHO so nicht sinnvoll. Lass deine resov.conf nur auf den lokalen DNS zeigen. Dieser ist dann dafür zuständig, die forwarders zu befragen. Meines Wissens nach wird der zweite und dritte Eintrag nur genommen, wenn der erste DNS keine Antwort liefert (nicht erreichbar ist). Ein "kann Namen nicht auflösen" ist aber auch eine Antwort. Dann wird der zweite nicht mehr befragt.
# tail -f /val/log/messages May 13 09:13:21 sonne kernel: isdn_net: ippp0 connected May 13 09:13:21 sonne ipppd[434]: Remote message: May 13 09:13:21 sonne ipppd[434]: MPPP negotiation, He: No We: No May 13 09:13:21 sonne ipppd[434]: CCP enabled! Trying CCP. May 13 09:13:21 sonne ipppd[434]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol) May 13 09:13:21 sonne ipppd[434]: ccp_resetci! May 13 09:13:21 sonne ipppd[434]: local IP address 213.7.74.63 May 13 09:13:21 sonne ipppd[434]: remote IP address 62.104.204.32 May 13 09:13:21 sonne modify_resolvconf: Service ipppd modified
Das müsste Dein Problem sein: Wenn Du einen lokalen DNS hast, sollte die resolv.conf nicht verändert werden. Wird NACH der Einwahl überhaupt noch dein lokaler DNS benutzt? Oder ist die resolv.conf wirklich überschrieben? Das kannst in den optionen (hier bei mir: options.ippp0 in /etc/ppp) abstellen (option irgendwas mit ms-getdns o-ä.) Andreas
participants (3)
-
Andreas Kyek
-
Herbert Schrader
-
Sebastian Wolfgarten