Tengo un problema con la configuración de DNS BIND9 en el servidor de mi hogar.
Cuando uso nslookup
y dig
desde SSH en el servidor doméstico (192.168.1.20), obtengo resultados y curl
también devuelve páginas web cuando corresponde, por lo que el servidor doméstico ve mis configuraciones de zona correctamente.
Sin embargo, cuando accedo a la intranet desde un cliente local (192.168.1.30, mi PC con Windows), lo hago can't connect to the server
a través de Firefox, the remote name could not be resolved
curl y *** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for REDACTED
nslookup. La resolución DNS debería ser reenviada correctamente por el enrutador (192.168.1.1), pero aparentemente esto no funciona o hay algún otro problema en juego ya que el servidor doméstico funciona bien.
Enrutador NetgearDD-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
Para DHCP Srv:
UsedDomain: LAN & WLAN
LANDomain: inet (*.REDACTED.inet is BIND9 intranet zone. could this be interfering?)
Para DnsMasq Srv:
DNSMasq: Enabled
EncryptDNS: Disabled
CacheDNSSEC: Disabled
ValidateDNSRep: Disabled
CheckUnsDNSRep: Disabled
LocalDNS: Enabled (is this correct?)
NoDNSRebind: Enabled
QueryDNSStrict: Enabled
RequestorMAC: Disabled
Y sin opciones adicionales
Servidor doméstico Linux(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
Soy bastante nuevo en la configuración de DNS en general. ¿Hay algo que parezca extraño? ¿Tiene alguna idea de por qué no se activa el DNS o qué No internal type for both IPv4/v6
significa el error?
ACTUALIZAR: Lo instalé dig
en mi cliente de Windows para obtener información adicional y al presionar el dns a través de 192.168.1.1 me dio una consulta válida de estado NOERROR
, pero sin ANSWER SECTION
registros A
.
Codifiqué las direcciones DNS en la NIC de mi cliente en 192.168.1.20 y obtuve esto de una dig
consulta de muestra a uno de mis nombres DNS:
; <<>> 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
Y puedo acceder a páginas web a través de los nombres dns. Al volver a la configuración de DNS automático, se vuelve a romper. Parece muy probable que el problema tenga algo que ver con la configuración del enrutador DD-WRT.
Respuesta1
Problema resuelto. Resulta que el culpable fue el propio DNSMasq. Después de desmarcar Use DNSMasq for DHCP
, Use DNSMasq for DNS
y DHCP-Authoritative
luego deshabilitar DNSMasq, las consultas de DNS y la navegación del sitio comenzaron a funcionar nuevamente.
No estoy seguro de si hay una manera limpia de reenviar las consultas a través de DNSMasq si alguien quisiera hacer lo mismo que yo pero con DNSMasq habilitado, pero como no lo necesito, simplemente voy para dejarlo desactivado.