Re: Netzwerkfragen (BIND)

Erik Niemeyer <erik(at)3w20.de> wrote:
> Die Liste mag anscheinend keine zip-Anhänge :-(

Ist besser so, sonst hätte ich Dir nicht helfen können.
Auf der Kiste, wo ich dies lese, ist kein unzip installiert.

> FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009
> root(at)mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC

8.0-Release ist seit fast zwei Jahren EOL, d.h. so lange
gibt es schon keine Advisories und Bugfixes mehr dafür.
Ich würde daher auf jeden Fall zu einem Update raten
(auf ein aktuelleres 8.x und/oder 8-stable, oder auch
gleich auf 9-stable bzw. 9.1-Release, wenn es erscheint).

Nun zu den Kommandos, die fehlschlagen, im einzelnen:

> SanjaII# dig amajala
> SanjaII# dig @172.23.0.1 amajala
> SanjaII# dig @SanjaII amajala
> SanjaII# dig @SanjaII.ork42.de amajala

Diese Kommandos können nicht gehen, da dig per Default nicht
die Suchliste durchgeht und keine Domains anhängt. Folglich
sucht er nach einer TLD namens "amajala.", was natürlich an
die Rootserver delegiert wird, welche dann NXDOMAIN liefern,
weil es so eine TLD tatsächlich nicht gibt.

Mit folgender Option, die die Suchliste einschaltet, sollte
es funktionieren: dig amajala +search

nslookup verwendet immer die Suchliste, daher funktioniert
es dort ohne weiteres.

> SanjaII# dig @127.0.0.1 amajala
> SanjaII# dig @127.0.0.1 amajala.ork42.de
> SanjaII# dig @localhost amajala
> SanjaII# dig @localhost amajala.ork42.de

Alle diese Kommandos liefern "connection timed out", weil
Dein named nicht auf localhost (127.0.0.1) lauscht.

Und damit sind wir auch schon bei der named.conf:

> listen-on { 172.23/16; };

Da solltest Du noch 127.0.0.1 hinzufügen. Dann funktioniert
auch dig @localhost bzw. dig @127.0.0.1.

> forwarders {
> 213.191.74.19;
> 62.109.123.197;
> 141.22.10.1;
> 217.115.143.194;
> 80.237.128.66;
> };

Da hast Du ja eine recht umfangreiche Liste an Forwardern.
Wie bist Du darauf gekommen? Zumindest einige davon sind
keine öffentlichen Nameserver und beantworten keine Queries
(oder keine rekursiven Queries). Das ist für die seltsamen
Probleme verantwortlich, dass Internet-Namen sporadisch
aufgelöst werden können und dann wieder nicht -- je nachdem,
welchen der Forwarder Dein BIND gerade gefragt hat.

Solange Du noch am Debuggen bist, solltest Du die Liste
der Forwarders _komplett_ herausnehmen, um diese als Fehler-
quellen auszuschließen. Du brauchst auch nicht unbedingt
Forwarders; wenn keine vorhanden sind, findet Dein BIND
die Antworten selbständig, indem er die Rootserver fragt
und sich "hocharbeitet". Das dauert nur evtl. ein wenig
länger.

Wenn Du die Probleme beseitigt hast, kannst Du wieder
einen oder mehrere Forwarder eintragen, aber dabei solltest
Du konservativ vorgehen. Lieber zu wenig als zu viel:
Keine Forwarder zu haben, ist nicht schlimm, aber ein
Forwarder, der Queries nicht korrekt beantwortet, sollte
vermieden werden. Normalerweise sollte man _nur_ die
Nameserver des eigenen Providers verwenden, keine "fremden".

> file "master/ork42.de.db";
und
> file "master/172.23.db";

Ein Tip: Ich empfehle, immer absolute Pfade zu verwenden,
also "/etc/namedb/master/...". Dann geht nichts in die
Brüche, falls sich das Arbeitsverzeichnis des BIND ändert.

Zu den Zone-Files: Hier empfehle ich, per $ORIGIN die
Domain festzulegen. Ist zwar nicht zwingend nötig, aber
i.allg. "sauberer".

Außerdem fehlen in den SOA-Records zwei Punkte:

> @ IN SOA SanjaII.ork42.de erik.3w20.de (
muss heissen:
> @ IN SOA SanjaII.ork42.de. erik.3w20.de. (

Ebenso im zweiten Zone-File. Anderenfalls sind die Angaben
nicht qualifiziert, d.h. BIND hängt die Domain nochmals
hinten dran, und dann hast Du sie doppelt. Das ist zwar
in diesem speziellen Fall bei den SOA-Records unkritisch,
aber man sollte es trotzdem besser korrekt machen, und sei
es nur deswegen, um zu verweiden, dass der Fehler später
an eine andere Stelle propagiert wird (z.B. mit einem
unbedachten Copy&paste).

Bei den NS-Records fehlen ein paar Sachen:

> NS SanjaII.ork42.de.

Man darf den Namen zwar weglassen (es wird dann der Name des
vorhergehenden Records übernommen), aber dadurch kann man
später Probleme bekommen, wenn man weitere Zeilen einfügt,
Zeilen löscht oder sich aus irgendeinem Grund die Reihenfolge
der Zeilen ändert. Daher sollte man grundsätzlich immer den
Namen hinschreiben. Auch die Class (IN) sollte man besser
hinschreiben, auch wenn es hier immer die gleiche ist.
Also besser:

> @ IN NS SanjaII.ork42.de.

Man kann drüber streiten, aber meiner Meinung nach erhöht es
die Robustheit, wenn man nicht alles, was man weglassen darf,
auch tatsächlich weglässt.

Zur /etc/resolv.conf:

> domain ork42.de
> nameserver 172.23.0.1

Üblicherweise schreibt man 127.0.0.1 rein (nachdem Du die
listen-Direktive angepasst hast, natürlich). Dies ist
übrigens auch der Default, wenn resolv.conf überhaupt nicht
existiert.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
        -- Robert Firth
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message