Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

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?

Geschrieben

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

Geschrieben

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>

  • 3 Wochen später...
Geschrieben

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?

Geschrieben

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...

Geschrieben

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*

Geschrieben

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...)

Geschrieben
  Zitat
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 :P

  • 10 Monate später...
Geschrieben

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 Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Weiterlesen  

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...