Veröffentlicht 13. Juni 200322 j In /var/log/messages erscheint bei meinem suse8.1- mailserver immer wieder die meldung: mailserver named[974]: ns_req: no address for root server Was genau hat das zu bedeuten, ist der Nameserver falsch konfiguriert? Wie/wo kann ich Abhilfe schaffen?
13. Juni 200322 j Hallo, Falls Du auf der Maschine keinen name-Server (named) betreibst, kannst Du diesen einfach abschalten (beispielsweise über yast2). Ansonsten läßt sich die Konfiguration in named.conf anpassen. Nic
16. Juni 200322 j Ich habe selbiges Problem, der DNS-Server wird gebraucht, und die Config ist (meiner Ansicht nach) entsprechend der des DNS-Howtos: options { directory "/var/named"; forward first; forwarders { 212.63.33.66 ; 212.63.37.66 ; }; }; zone "." { type hint; file "root.hints"; }; zone "localhost." { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" { type master; file "127.0.0.zone"; }; ; Eigene Zonen usw ist btw nen Bind8 auf SuSE 8.1 Der Gag an der Geschichte ist aber auch, dass er die korrekten Root-Server kennt! (Überprüft mit dig ohne Rekursion und überprüfung der IP) Er überflutet einem halt nur alle 15min /var/log/messages mit den Fehlermeldungen (Wird ganz schön groß, das Ding...) <edit>Hab gerade gesehen, dass die Fehlermeldung nicht die Gleiche ist: named[12606]: sysquery: no addrs found for root NS (A.ROOT-SERVERS.NET) Und das für alle 13 Root-Server </edit>
16. Juni 200322 j Kleine Frage: die Datei /var/named/root.hints existiert und ist aktuell? Eine aktuelle root.hints gibt's z.B hier: ftp://ftp.internic.net/domain/named.root
18. Juni 200322 j Die root.hints war und ist aktuell, das IN war es. Komisch nur, dass es trotzallem funktioniert hat... Tx to all!
8. Juli 200322 j OK, war es doch noch nicht... nachdem er sich das letzte mal das Update der root.hints gefahren hat, hat er wieder angefangen mit den Meldungen. Die Datei stimmt aber auf jeden Fall. Noch irgendwelche Ideen?
9. Juli 200322 j Das mit der Resolf.conf ist zwar ne nette idee, geht aber nicht, da das ding nen Nameserver für ne ganze Firma ist. Die Geschichte mit dem Netzwerk ist deswegen auch nicht drin, das ist ne Standleitung. Und bei mir heist das Ding wirklich root.hints. Hab ich irgendwann bei dem Update-Script so benannt, und hab jetzt keinen Bock das nochmal umzustellen...
9. Juli 200322 j Laut ISC (http://www.isc.org/ml-archives/bind-users/2000/08/msg00834.html) handelt es sich bei dem Problem um eine veraltete root.hints. Bei Dir läuft ja aber ein Update, das sollte es also nicht sein. Trotzdem: das 'in' bei den obigen Zonen sollte eingefügt werden. Was für ein Ergebnis liefert den folgender Aufruf: dig @127.0.0.1 a.root-servers.net. Könnte es evtl. sein, daß eine Firewall den Nameserver nicht durchläßt? Anbei mal meine named.conf mit der bei mir alles funktioniert (vielleicht kommt ja ne Idee dadurch): # interne Netze acl "mynet" { 192.168.0.0/24; 192.168.1.0/24; }; options { directory "/var/lib/named"; pid-file "/var/run/named/named.pid"; auth-nxdomain no; recursion yes; listen-on { 192.168.0.1; 192.168.1.1; 127.0.0.1; }; listen-on-v6 { none; }; port 53; forward first; forwarders { 193.101.111.10; 192.76.144.105; }; notify yes; allow-query { 127.0.0.1; mynet; }; allow-recursion { 127.0.0.1; mynet; }; allow-transfer { 127.0.0.1; mynet; }; recursive-clients 25; tcp-clients 10; }; zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; zone "." in { type hint; file "root.hint"; }; *snip*
10. Juli 200322 j Das IN habe ich eingefügt. (Schon beim ersten Versuch.) Das die Firewall das Ding nicht durchlässt, glaug ich eher weniger, denn es funktioniert ja alles, abgesehen davon, dass er mir die logs zumüllt. Das aber dafür mit wirklich enormer Geschwindigkeit. Schade. Noch irgendwelche Ideen? btw: die Konfig da oben ist echt der Hammer. bin ich froh, das da unsere Firewall doch einiges einfacher macht. (Wenn nur die richtigen Netze überhaupt Kommunizieren dürfen, muss man sich nicht per ACL einschränken...)
10. Juli 200322 j btw: die Konfig da oben ist echt der Hammer. bin ich froh, das da unsere Firewall doch einiges einfacher macht. (Wenn nur die richtigen Netze überhaupt Kommunizieren dürfen, muss man sich nicht per ACL einschränken...) Stimmt zwar, trotzdem sollte man sich nicht immer nur auf die Firewall allein verlassen. In der Firewall könnte ja auch mal ein Fehler sein
26. Mai 200421 j ist zwar schon ewig her, aber ich hab die Lösung! (Diesmal wirklich) Also, erstmal zu den Antworten zum Thema fehlendes IN: ist nicht unbedingt notwendig, aber schöner. Wenn nicht vorhanden, ist es dennoch der Default-Wert. Aber zum Problem: Es waren ganz offensichtlich die Dateirechte der hint-zone. waren auf root.root und 444. bind wollte aber ganz gerne darauf schreiben, also auf named.root und 644 berichtigt, und jetzt läuft die Kiste ohne die Logs zuzumüllen. (waren etwa 15 Zeilen pro Minute......) OK, nochmal allen vielen Dank, jetzt läuft er (endlich)
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.