Re: BIND: lokale hosts werden nicht aufgelöst

Hallo,

Andi Wuestner <awuestner@xxxxxxxxxxxxxxxxxxx> wrote:
> Ergänzung zum Ursprungsposting:
>
> resolv.conf von linux3:
> domain tfi-net.local
> nameserver 192.168.57.1

Das ".local" keine gute Idee ist, habe ich dir wohl schon verraten ...

> resolv.conf von linux1 (=DNS-Server=Router=Firewall):
>
> search tfi-net.local
> nameserver 192.168.57.1
> nameserver 217.237.149.161
> nameserver 217.237.151.225

Fehler! Trag die DNS-Server deines Providers nicht in die resolv.conf
ein, sondern nur als forwarder in die Konfiguration deines bind.
Ansonsten sind mehr oder weniger oft Probleme beim aufloesen der
lokalen Namen vorprogrammiert ... Wenn einer der DNS-Server deines
Providers fuer einen lokalen Namen bereits ein "not found" antwortet,
findet kein fallback auf deinen lokalen DNS statt (denn "not found"
ist bereits eine akzeptable Antwort). Es kaeme also sehr darauf an,
welcher DNS-Server zuerst befragt wird (und darauf hast du keinen
Einfluss). Abhilfe: *NUR* deinen DNS befragen, und der fragt (falls
er nicht direkt fuer die angefragte Zone zustaendig ist) seine
"forwarder" (bei entsprechender Konfiguration also die deines
Providers).

> BIND 9.2.2 lief mit den (fast) gleichen Konfigurationsdatein unter SuSE
> 9 problemlos. Aufgrund der strengeren Syntaxprüfung der Zonendateien,
> die zu einem Abbruch des Ladevorgangs aufgrund von Underscores in
> Rechnernamen führt, habe ich lediglich in die named.conf die Zeile
> check-names master warn; eingetragen.
>
> Ausgaben von BIND nach /var/log/messages beim Start:
>
> Jan 4 12:43:50 linux1 named[12914]: starting BIND 9.3.1 -t
> /var/lib/named -u named
> Jan 4 12:43:50 linux1 named[12914]: found 1 CPU, using 1 worker thread
> Jan 4 12:43:50 linux1 named[12914]: loading configuration from
> '/etc/named.conf'
> Jan 4 12:43:50 linux1 named[12914]: listening on IPv4 interface eth0,
> 192.168.0.1#53
> Jan 4 12:43:50 linux1 named[12914]: zone 'domain.local' allows updates
> by IP address, which is insecure

Benoetigst du "dynamische DNS-Updates"? Wenn nicht, nimm die
"allow-update" Eintraege heraus.

> Jan 4 12:43:50 linux1 named[12914]: zone '57.168.192.in-addr.arpa'
> allows updates by IP address, which is insecure
> Jan 4 12:43:50 linux1 named[12914]: command channel listening on
> 127.0.0.1#953
> Jan 4 12:43:50 linux1 named[12914]: command channel listening on ::1#953
> Jan 4 12:43:50 linux1 named[12914]: zone 0.0.127.in-addr.arpa/IN:
> loaded serial 42
> Jan 4 12:43:50 linux1 named[12914]: zone 57.168.192.in-addr.arpa/IN:
> loaded serial 2004082840
> Jan 4 12:43:50 linux1 named[12914]: master/domain.zone:29:
> gc._msdcs.domain.local: bad owner name (check-names)
> Jan 4 12:43:50 linux1 named[12914]: master/domain.zone:104:
> GUT_Vankann.domain.local: bad owner name (check-names)
> Jan 4 12:43:50 linux1 named[12914]: master/domain.zone:116:
> Linksys\032WAP54G.domain.local: bad owner name (check-names)
> Jan 4 12:43:50 linux1 named[12914]: master/domain.zone:177:
> wlan_gut.domain.local: bad owner name (check-names)

Diese Meldungen liessen sich durch Verzicht auf ".local" vermeiden.
Such dir z.B. eine der in RFC2606 genannten Toplevel-Domains oder (falls
du eine eigene Domain hast) eine Subdomain deiner eigenen Domain fuer
deine lokalen Rechner aus.

Ob das deine Probleme wirklich loest, weiss ich nicht genau, aber
es ist zumindest ein Ansatz ...
Ach ja, wenn du weitere Fragen hast, wende dich eher an die passende
Newsgruppe de.comm.protocols.tcp-ip (oder evt. eine Gruppe. die sich
^^^^^^^^^^^^^^^^^^^^^^^^
OOPS! Die waere unpassend, besser waere de.comp.os.unix.networking.misc

mit allgemeinen unix-Applikationen befast), denn bind ist alles andere
als linux-spezifisch ...

Tschuess,
Juergen Ilse (juergen@xxxxxxxxxxxxxxxxxxxx)
.

Relevant Pages

  • Re: bind delegation subdomain fibu
    ... kennt die domain nicht. ... dig -trace ist diesbezueglich aussagekraeftiger als host. ... Der Fehler liegt wohl auf dem Nameserver ad.example.intern, ... nicht fuer die Domain "fibu.example.intern" zustaendig fuehlt (und ...
    (de.comp.os.unix.networking.misc)
  • Re: DNS-Abfrage wird nicht beantwortet
    ... Also ein Recursor (rekursiver resolver). ... Fuer die Domain "dietmar-buecher.de" ist u. a. ... Nameserver dns1.teliko.net verantwortlich. ...
    (de.comp.os.unix.networking.misc)
  • Re: Der DNS-Server meines Providers loest localhost. zu einer AOL-Adresse auf
    ... Und da der eigene DNS ja cached, ... von Zonen eines Nameserver) und die TTL dieser Einträge ... dass die Rootserver unter ihrer Last bereits ächzen ... Es kommt auf die Anzahl der Queries (fuer Rechenzeit und Netzbandbreite) ...
    (de.comp.os.unix.networking.misc)
  • Re: F: Korrektheit einer DNS-Zone
    ... dass du fuer den selben Namen nicht ... gleichzeitig einen CNAME und einen anderen Record in der Zone haben darfst, ... also nimm fuer den Wildcard einen A und keinen CNAME Record. ... die Domain wird gar nicht auf deinen Nameserver ...
    (de.comp.os.unix.networking.misc)
  • Re: Verstaendnisproblem: bind9 und forwarder
    ... Nun soll der NS dns1.sub.example.org nicht die root server fuer ... das ist eine nicht-rekursive delegation fuer die root-zone. ... Nameserver fuer eine Zone den selben Inhalt kennen - also gleichwertig ... machen und diese auf dns1.sub diese fest als Forwarder fuer alles ...
    (de.comp.os.unix.networking.misc)