v654321
Poster original- 6 de agosto de 2011
- Vilvoorde, Bélgica
- 22 de mayo de 2021
Declaración del problema: Mi MBP obtiene una dirección IP asignada a través de DHCP, usando un Pi-hole, con un resolutor de DNS independiente. Utilizo un nombre de dominio interno 'home.arpa' y eso se agrega como un dominio de búsqueda de DNS, incluida la IP de mi servidor DNS (192.168.1.4). Cada dispositivo de mi red tiene un nombre de host.
En mis máquinas Linux y Windows puedo hacer ping perfectamente al mismo dispositivo usando tanto el FQDN (por ejemplo, ap12.home.arpa o kodi.home.arpa) como el nombre de host en sí (por ejemplo, ap12 o kodi) a medida que el dominio de búsqueda se agrega automáticamente . Sin embargo, en mi MBP simplemente no funciona, como si el dominio de búsqueda ni siquiera existiera / fuera ignorado. Puedo hacer ping perfectamente al FQDN, pero el nombre de host en sí siempre falla. No aprovisioné mi archivo / private / etc / hosts con estos nombres de host o FQDN, ya que la configuración de DNS debería encargarse de eso (y lo hace en mis máquinas que no son MacOS). Lo intenté incluso con una configuración de IP fija (tanto IP estática como dominios de búsqueda de DNS y DNS) pero no hubo diferencia.
Disculpas si esto no se aprecia, pero agregué algunas capturas de pantalla de Windows, Linux y MacOS Big Sur con sus resultados de configuración y ping:
Windows 10:
Ver elemento multimedia '>
Linux:
Ver elemento multimedia '>
MacOS Big Sur:
Ver elemento multimedia '>
Por lo que mi búsqueda en Google ha revelado, parece que el dominio de búsqueda es un problema que surgió en el pasado para varios usuarios, pero no encontré ningún hilo que lo convirtiera en un problema estructural. La mayor parte del tiempo estuvo vinculado a VPN (DNS de túnel dividido) o dominios de búsqueda faltantes / incorrectos. Me hizo concluir que con una configuración adecuada, se consideraba que todo estaba funcionando.
Espero en silencio que algunos de ustedes puedan guiarme / ayudarme a descubrir qué podría estar mal o qué puedo hacer para aliviar esto. Obviamente, puedo codificar los nombres de host / FQDN en el archivo / private / etc / hosts, pero como estoy jugando con muchas computadoras y VM, me gustaría poder confiar en la resolución de DNS que está completamente automatizada.
¡Gracias de antemano por su posible interés / participación!
HenryAZ
- 9 de enero de 2010
- Congreso Sur AZ
- 22 de mayo de 2021
v654321 dijo: Declaración del problema: Mi MBP está obteniendo una dirección IP asignada a través de DHCP, usando un Pi-hole, con un sistema de resolución de DNS independiente. Utilizo un nombre de dominio interno 'home.arpa' y eso se agrega como un dominio de búsqueda de DNS, incluida la IP de mi servidor DNS (192.168.1.4). Cada dispositivo de mi red tiene un nombre de host.
¿Tiene una zona local configurada para home.arpa sin unir en 192.168.1.4? V
v654321
Poster original- 6 de agosto de 2011
- Vilvoorde, Bélgica
- 23 de mayo de 2021
El dominio interno home.arpa se configura en la interfaz web de pihole. Es posible que mi descripción de configuración original no esté completa. Mis disculpas por esto.
El servidor DNS configurado en todas mis computadoras es la dirección IP del pihole, que, si no tiene el dominio solicitado en su caché, ni está en las listas de bloqueo preconfiguradas, lo reenvía al servicio no vinculado (que se ejecuta en localhost en el pihole) quien luego se comunicará con los servidores raíz de DNS para identificar los servidores DNS de TLD, etc., hasta que se reciban las IP necesarias para los dominios externos. No se necesita una configuración de zona local en unbound ya que esto se hace en la interfaz web de pihole. Usé lo siguiente Guia de preparacion y lo siguió al pie de la letra. Solo el MBP falla para las búsquedas de solo nombre de host, todas las demás máquinas funcionan perfectamente.
Ejecutar el siguiente comando en Linux funciona perfectamente (kodi se extiende automáticamente con el dominio de búsqueda, por lo que se convierte en kodi.home.arpa:
|_+_|
Esto da como resultado los siguientes registros en pihole:
|_+_|
Sin embargo, haciendo lo mismo desde mi MBP:
|_+_|
Esto da como resultado los siguientes registros en pihole:
|_+_|
Esto muestra que en el MBP el primer intento de ping falla porque el dominio de búsqueda no se agrega automáticamente para convertirse en el FQDN (kodi.home.arpa) mientras que la segunda solicitud se trata correctamente. Ambas solicitudes llegan al pihole, pero el dominio de búsqueda no se aplica a pesar de estar presente en la configuración de IP proporcionada por DHCP.
A menos que me falte algo más, me atrevería a concluir que, dado que tanto el host de Linux como el MBP obtienen su información de IP y DNS de manera idéntica del mismo DHCP, se comunican con el mismo servidor DNS (pihole) y que funciona perfectamente en mi host Linux (no el pihole) pero no en el MBP, el dominio de búsqueda de DNS no se está aplicando a un comando ping solo de host. Realmente no tengo idea de qué más puedo cambiar para que esto funcione.
HenryAZ
- 9 de enero de 2010
- Congreso Sur AZ
- 23 de mayo de 2021
v654321 dijo: A menos que me falte algo más, me atrevería a concluir que, dado que tanto el host de Linux como el MBP obtienen su información de IP y DNS de manera idéntica del mismo DHCP, se comunican con el mismo servidor DNS (pihole) y eso Funciona perfectamente en mi host Linux (no en el pihole) pero no en el MBP, el dominio de búsqueda de DNS no se aplica a un comando ping solo del host. Realmente no tengo idea de qué más puedo cambiar para que esto funcione.
Me arriesgaría a adivinar que la implementación de MacOS de NetBIOS no es tan robusta como las otras dos, que pueden resolverse solo con el nombre de host. ¿Tiene NetBIOS habilitado en su Mac? Es por defecto. No creo que la ruta de búsqueda realmente importe, que Windows y Linux están haciendo la resolución de nombres NetBIOS del nombre de host para obtener su dirección IP, en lugar de DNS.
Con unbound, tiene el lujo de usarlo como resolutor de validación, para zonas externas, sin tener que reenviar solicitudes. Y como solucionador de una zona local.
Entradas Populares