Un nombre de host NAS se resuelve de manera inconsistente cuando los dispositivos no usan el mismo método de nombrado, resolvedor, sufijo o respuesta en caché.
En una red doméstica, una laptop puede encontrar nas a través del DNS del router, una Mac puede encontrar nas.local mediante DNS multicast, una PC con Windows puede recurrir a LLMNR o NetBIOS, y un teléfono puede enviar la misma consulta a DNS Privado, una VPN o un resolvedor filtrado. Por lo tanto, el diagnóstico útil es comparar el nombre exacto y la ruta IP en un dispositivo que funciona y otro que falla antes de cambiar la configuración del NAS, router o SMB.
Compruebe si la falla es en la resolución de nombres o en el acceso al NAS
Pruebe el NAS por su dirección IP actual tanto en un dispositivo que funciona como en uno que falla. Luego pruebe el nombre corto, el nombre local completamente calificado y cualquier forma .local por separado en lugar de tratarlos como intercambiables.
Una prueba de nombre de host añade un paso de resolvedor antes de que SMB, HTTP u otro servicio pueda conectarse. La guía de ZimaSpace para verificar un servidor doméstico por nombre explica por qué el acceso por nombre de host añade resolución DNS al camino que el acceso directo por IP no requiere.
Si la IP funciona en ambos dispositivos pero solo uno resuelve el nombre, mantenga la investigación en la capa del resolvedor. Si la IP también falla, primero solucione VLAN, aislamiento Wi-Fi, firewall, enrutamiento o accesibilidad del servicio porque cambiar el DNS no puede reparar una ruta de red bloqueada.
Compare el servidor DNS usado por cada dispositivo
Registre los servidores DNS, tipo de conexión, puerta de enlace y perfil de red activo en los dispositivos que funcionan y los que fallan. Dos clientes en el mismo nombre Wi-Fi aún pueden usar resolvedores diferentes debido a configuraciones manuales, configuración de nodos de malla, software VPN, DNS seguro del navegador o DNS Privado móvil.
La resolución de nombres local sigue un orden específico del sistema operativo que puede combinar mDNS, LLMNR y DNS unicast. Un cliente que consulta al router puede recibir un registro local del NAS, mientras que un cliente que consulta a un resolvedor público recibe NXDOMAIN porque ese nombre privado no existe en internet público.
Consulte directamente el servidor DNS configurado exacto desde ambos dispositivos y compare la respuesta, el código de respuesta y la dirección devuelta. Si el router responde correctamente pero el cliente que falla nunca lo consulta, corrija la distribución DHCP DNS, la anulación del cliente, la política DNS de la VPN o la configuración de DNS cifrado en lugar de editar el nombre de host del NAS.
Separe los nombres cortos de host de mDNS y otros métodos locales de reserva
Pruebe nas, el nombre local completo del router como nas.home.arpa o nas.lan, y nas.local como tres entradas diferentes. El éxito con una forma no prueba que las otras estén configuradas.
Los protocolos de reserva local no se comportan idénticamente en todos los sistemas operativos. Una discusión práctica en Windows muestra que deshabilitar NetBIOS, mDNS o LLMNR no hace automáticamente que los nombres LAN cortos usen DNS; el cliente aún necesita un registro DNS válido y una ruta de sufijo.
Si solo funciona nas.local, probablemente el NAS esté anunciando mDNS pero el router no está sirviendo un registro DNS local convencional. Si solo funciona el nombre completo del dominio del router, agregue o distribuya el sufijo de búsqueda correcto en lugar de depender de la reserva por nombre corto.
Verifique si el dispositivo soporta el método de descubrimiento que está usando
Deje el NAS y el router sin cambios, luego pruebe el mismo nombre desde otro dispositivo que ejecute el mismo sistema operativo que el cliente que falla. Esto separa una diferencia de implementación del dispositivo de un problema DNS en toda la red.
Las redes reales con dispositivos mixtos pueden mostrar exactamente esta división: un dispositivo Android puede fallar al resolver una dirección .local mientras que dispositivos Windows, iPhone y macOS en la misma LAN tienen éxito. Un caso documentado describe fallo de resolución mDNS en Android a pesar de que otros clientes resuelven el mismo host.
Si el síntoma sigue a un sistema operativo o aplicación, use un registro DNS convencional del router o un dominio local completamente calificado que todos los clientes requeridos puedan consultar. No diseñe montajes SMB críticos, rutas de respaldo o callbacks alrededor de un método de descubrimiento que solo parte del hogar soporte.
Pruebe el sufijo de búsqueda y la consulta exacta enviada por el cliente que falla
Un nombre de una sola etiqueta como nas puede necesitar un sufijo específico de conexión antes de convertirse en una consulta DNS completa. Compare la lista de sufijos del dispositivo que falla con la del que funciona y pruebe el nombre completo directamente.
Usuarios de OpenWrt han reportado casos donde la resolución de nombres cortos funciona mientras que el nombre corto falla en otros clientes. La diferencia suele ser el sufijo que el sistema operativo añade, no el registro del NAS en sí.
Si nas.example.lan funciona pero nas falla, distribuya el mismo dominio de búsqueda mediante DHCP o guarde el nombre completo en montajes SMB y marcadores. Evite crear varios sufijos no oficiales que se resuelvan de manera diferente en el DNS del router, Pi-hole, AdGuard Home y archivos hosts de clientes.
Limpiar el estado del cliente solo después de que la ruta del resolvedor sea correcta
Una vez que ambos dispositivos usen el mismo resolvedor y forma de nombre, borre la caché DNS del cliente que falla, desconecte y reconecte su perfil de red, y vuelva a probar en un navegador o terminal nuevo. Las respuestas NXDOMAIN en caché pueden persistir más allá de la corrección en el lado del router.
La selección del resolvedor también puede desviarse cuando el sistema operativo envía una consulta a multicast o a un stub local en lugar del servidor DNS esperado. Un informe de solución de problemas en Fedora capturó un cliente usando resolución local inconsistente aunque la configuración DNS de la red parecía correcta.
Finalice haciendo que cada dispositivo requerido resuelva un nombre elegido al dirección reservada del NAS, luego confirme que SMB, el panel de control y las aplicaciones autoalojadas se reconecten a través de ese nombre. Mantenga la prueba de IP como respaldo diagnóstico, pero use un sistema de nombres documentado en lugar de depender de reservas accidentales de protocolo.
Soporte y Consejos
Más para leer

¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...

¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...

¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...

