SirLizium Geschrieben 13. Juni 2003 Teilen Geschrieben 13. Juni 2003 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
nic_power Geschrieben 13. Juni 2003 Teilen Geschrieben 13. Juni 2003 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 16. Juni 2003 Teilen Geschrieben 16. Juni 2003 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> Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.disk Geschrieben 16. Juni 2003 Teilen Geschrieben 16. Juni 2003 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 18. Juni 2003 Teilen Geschrieben 18. Juni 2003 Die root.hints war und ist aktuell, das IN war es. Komisch nur, dass es trotzallem funktioniert hat... Tx to all! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 8. Juli 2003 Teilen Geschrieben 8. Juli 2003 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 9. Juli 2003 Teilen Geschrieben 9. Juli 2003 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... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.disk Geschrieben 9. Juli 2003 Teilen Geschrieben 9. Juli 2003 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* Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.disk Geschrieben 10. Juli 2003 Teilen Geschrieben 10. Juli 2003 Ja. Man tut halt was man kann Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 10. Juli 2003 Teilen Geschrieben 10. Juli 2003 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...) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.disk Geschrieben 10. Juli 2003 Teilen Geschrieben 10. Juli 2003 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kristian Geschrieben 26. Mai 2004 Teilen Geschrieben 26. Mai 2004 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) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.