Ich habe ein Problem mit einem BIND9-DNS-Setup auf meinem Heimserver.
Wenn ich nslookup
und dig
von SSH auf dem Heimserver (192.168.1.20) verwende, erhalte ich Ergebnisse zurück und es curl
werden ggf. auch Webseiten zurückgegeben, sodass der Heimserver meine Zonenkonfigurationen richtig sieht.
Wenn ich jedoch von einem lokalen Client (192.168.1.30, mein Windows-PC) auf das Intranet zugreife, gelange ich can't connect to the server
über Firefox, the remote name could not be resolved
über curl und *** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for REDACTED
über nslookup. Die DNS-Auflösung sollte vom Router (192.168.1.1) ordnungsgemäß weitergeleitet werden, aber anscheinend funktioniert dies nicht oder es liegt ein anderes Problem vor, da der Heimserver einwandfrei funktioniert.
Netgear RouterDD-WRT (192.168.1.1):
RouterName: REDACTED
HostName: REDACTED (Same as RouterName)
LocalIP: 192.168.1.1
SubnetMask: 255.255.255.0
Gateway: 0.0.0.0
LocalDNS: 192.168.1.20 (is this correct? should this be 0.0.0.0?)
StaticDNS1: 192.168.1.20
StaticDNS2: 1.1.1.1
StaticDNS3: 1.0.0.1
WINS: 0.0.0.0
DnsMasqDHCP: Enabled
DnsMasqDNS: Enabled
DnsMasqAuth: Enabled
ForceDNSRedir: Disabled
Für DHCP Srv:
UsedDomain: LAN & WLAN
LANDomain: inet (*.REDACTED.inet is BIND9 intranet zone. could this be interfering?)
Für DnsMasq Srv:
DNSMasq: Enabled
EncryptDNS: Disabled
CacheDNSSEC: Disabled
ValidateDNSRep: Disabled
CheckUnsDNSRep: Disabled
LocalDNS: Enabled (is this correct?)
NoDNSRebind: Enabled
QueryDNSStrict: Enabled
RequestorMAC: Disabled
Und keine zusätzlichen Optionen
Linux Home Server(192.168.1.20):
/etc/hostname
S001
/etc/hosts
127.0.0.1 localhost S001
/etc/resolv.conf
nameserver 192.168.1.20
nameserver 1.1.1.1
nameserver 1.0.0.1
Ich bin ziemlich neu darin, DNS im Allgemeinen einzurichten. Sieht irgendetwas komisch aus? Haben Sie eine Idee, warum der DNS nicht erreicht wird oder was der No internal type for both IPv4/v6
Fehler bedeutet?
AKTUALISIEREN: Ich habe es für weitere Informationen auf meinem Windows-Client installiert dig
und als ich über 192.168.1.1 auf den DNS zugegriffen habe, erhielt ich eine gültige Statusabfrage NOERROR
, allerdings ohne ANSWER SECTION
und ohne A
Datensätze.
Ich habe die DNS-Adressen auf der Netzwerkkarte meines Clients fest auf 192.168.1.20 codiert und aus einer dig
Beispielabfrage an einen meiner DNS-Namen Folgendes erhalten:
; <<>> DiG 9.14.0 <<>> REDACTED
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f57ba5147d707a93c2a4328f5c9ae973c0bd569d9d31e87a (good)
;; QUESTION SECTION:
;REDACTED IN A
;; ANSWER SECTION:
REDACTED 38400 IN CNAME REDACTED
REDACTED 38400 IN A 192.168.1.20
;; AUTHORITY SECTION:
REDACTED 38400 IN NS localhost.
;; ADDITIONAL SECTION:
localhost. 604800 IN A 127.0.0.1
localhost. 604800 IN AAAA ::1
;; Query time: 0 msec
;; SERVER: 192.168.1.20#53(192.168.1.20)
;; WHEN: REDACTED
;; MSG SIZE rcvd: 168
Und ich kann über die DNS-Namen auf Webseiten zugreifen. Wenn ich zu den automatischen DNS-Einstellungen zurückkehre, bricht es wieder ab. Es sieht sehr wahrscheinlich aus, dass das Problem etwas mit der DD-WRT-Routerkonfiguration zu tun hat.
Antwort1
Problem gelöst. Es stellte sich heraus, dass DNSMasq selbst der Übeltäter war. Nachdem ich Use DNSMasq for DHCP
, und deaktiviert Use DNSMasq for DNS
und DHCP-Authoritative
dann DNSMasq deaktiviert hatte, funktionierten die DNS-Abfragen und die Site-Navigation wieder.
Ich bin nicht sicher, ob es eine saubere Möglichkeit gibt, die Abfragen über DNSMasq weiterzuleiten, wenn jemand dasselbe wie ich mit aktiviertem DNSMasq tun möchte, aber da ich es nicht brauche, lasse ich es einfach deaktiviert.