3
ForwardLookup will nicht, ReverseLookup schon - keine Syntaxfehler
Hallo,
nachdem ich mir die letzten Tage schon beinahe die (restlichen) Haare ausgerissen habe, da ich den Wald (Bind9 - Nach Installation checkconf gibt bereits Fehler bei Standarddateien!) mal wieder vor lauter Bäumen nicht gesehen habe, bin ich nun endlich mal ein Stück weiter gekommen.
Ich habe mit Debian ein bind9 Server zum laufen gebracht. Die Prüfung der conf Dateien von bind mithilfe von
und der Zonedateien mithilfe von
verlief ohne Fehler. Auf einer Windows Maschine habe ich dann per nslookup die Ergebnisse geprüft. Die Rückwärtssuche lief problemlos.
Die Vorwärtssuche bereitet mir jedoch Probleme.
Also die Datei nochmal genau angeschaut
und bind neu gestartet. Im Logprotokoll von bind kann ich keine Fehler finden.
Also nochmal die named.conf.local studiert...
Dort hatte ich dann tatsächlich einen Fehler gefunden, home.lan hieß da noch home.local, das habe ich dann so wie oben korrigiert, gespeichert und bind neu gestartet. Auf der Windows Maschine dann mit
den Cache geleert und mit nslookup nochmals probiert. Leider mit dem gleichen Ergebniss. Also habe ich Debian auch nochmal neu gestartet und wieder probiert. Immer noch kein Erfolg. Ich kann mir die Dateien anstarren, ich sehe es einfach nicht. Laut Doku ist bind sehr pingelig was die Syntax angeht. da ich in den Log aber nichts sehe und mit
keine Fehler ausgegeben werden, hab ich wohl einen Knoten im Kopf. Laut
ist die Zone ja definiert, also warum gibt mir nslookup dann
zurück????
Erbitte einen Hinweis. Stehe ich etwa wieder im Wald?
Vielen Dank für jeden erdenklichen Hinweis.
tomquenten
nachdem ich mir die letzten Tage schon beinahe die (restlichen) Haare ausgerissen habe, da ich den Wald (Bind9 - Nach Installation checkconf gibt bereits Fehler bei Standarddateien!) mal wieder vor lauter Bäumen nicht gesehen habe, bin ich nun endlich mal ein Stück weiter gekommen.
Ich habe mit Debian ein bind9 Server zum laufen gebracht. Die Prüfung der conf Dateien von bind mithilfe von
named-chekconfund der Zonedateien mithilfe von
named-checkzoneverlief ohne Fehler. Auf einer Windows Maschine habe ich dann per nslookup die Ergebnisse geprüft. Die Rückwärtssuche lief problemlos.
> 10.14.6.14
Server: ns1.home.lan
Address: 10.14.6.200
Name: ips.home.lan
Address: 10.14.6.14Die Vorwärtssuche bereitet mir jedoch Probleme.
> ips
Server: ns1.home.lan
Address: 10.14.6.200
*** ips wurde von ns1.home.lan nicht gefunden: Non-existent domain.Also die Datei nochmal genau angeschaut
;; bla
;; bla
;; bla
$TTL 604800
@ IN SOA ns1.home.lan. root.home.lan. (
2024031401 ;serial
604800 ;refresh
86400 ;retry
2419200 ;expire
604800 ) ;negative cache ttl
@ IN NS ns1.home.lan.
ns1 IN A 10.14.6.200
router IN A 10.14.6.1
ips IN A 10.14.6.14und bind neu gestartet. Im Logprotokoll von bind kann ich keine Fehler finden.
zone 0.in-addr.arpa/IN: loaded serial 1
2024-03-16T09:10:07.397526+01:00 ns1 named[724]: zone bla.blub/IN: loaded serial 2006032201
2024-03-16T09:10:07.397793+01:00 ns1 named[724]: zone home.lan/IN: loaded serial 2024031401
2024-03-16T09:10:07.398072+01:00 ns1 named[724]: zone 6.14.10.in-addr.arpa/IN: loaded serial 2024031401
2024-03-16T09:10:07.398728+01:00 ns1 named[724]: zone 127.in-addr.arpa/IN: loaded serial 1
2024-03-16T09:10:07.399071+01:00 ns1 named[724]: zone 255.in-addr.arpa/IN: loaded serial 1
2024-03-16T09:10:07.399872+01:00 ns1 named[724]: zone localhost/IN: loaded serial 2
2024-03-16T09:10:07.401749+01:00 ns1 named[724]: all zones loadedAlso nochmal die named.conf.local studiert...
#forward
zone "home.lan" {
type master;
file "/etc/bind/zones/db.home.lan";
};
zone "bla.blub" {
type master;
file "/etc/bind/zones/db.bla.blub";
};
#reverse
zone "6.14.10.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.home.lan.rev.6.14.10.in-addr.arpa";
};Dort hatte ich dann tatsächlich einen Fehler gefunden, home.lan hieß da noch home.local, das habe ich dann so wie oben korrigiert, gespeichert und bind neu gestartet. Auf der Windows Maschine dann mit
ipconfig /flushdnsden Cache geleert und mit nslookup nochmals probiert. Leider mit dem gleichen Ergebniss. Also habe ich Debian auch nochmal neu gestartet und wieder probiert. Immer noch kein Erfolg. Ich kann mir die Dateien anstarren, ich sehe es einfach nicht. Laut Doku ist bind sehr pingelig was die Syntax angeht. da ich in den Log aber nichts sehe und mit
named-checkconf
named-checkzone keine Fehler ausgegeben werden, hab ich wohl einen Knoten im Kopf. Laut
named.conf.local ist die Zone ja definiert, also warum gibt mir nslookup dann
Non-existent domainzurück????
Erbitte einen Hinweis. Stehe ich etwa wieder im Wald?
Vielen Dank für jeden erdenklichen Hinweis.
tomquenten
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 82737796141
Url: https://administrator.de/contentid/82737796141
Printed on: April 27, 2024 at 14:04 o'clock
3 Comments
Latest comment
Nslookup hängt bei Abfragen standardmäßig automatisch das primäre DNS Suffix der aktuellen Netzwerk-Verbindung an alle Namen die nicht auf einen Punkt enden bzw. keine FQDNs sind.
Gib also mal ips.home.lan. in nslookup ein (man beachte auch den Punkt am Ende). Dann solltest du auch das korrekte Ergebnis erhalten.
Gruß pp.
Gib also mal ips.home.lan. in nslookup ein (man beachte auch den Punkt am Ende). Dann solltest du auch das korrekte Ergebnis erhalten.
Gruß pp.
1
TATSACHE! Mensch und so schnell die Antwort! DANKE!
Ich habe das in einem Youtube Video so gesehen. Da wurde auch nur der Rechnername angefragt ohne Suffix.
Ich danke dir vielmals!
tomquenten
Ich habe das in einem Youtube Video so gesehen. Da wurde auch nur der Rechnername angefragt ohne Suffix.
Ich danke dir vielmals!
tomquenten
🤙👋
1