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

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.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

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.

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