Solución:
Recientemente, encontramos este problema y lo redujimos a que ocurriera SOLO en dispositivos con Android v5 y versiones posteriores. Android v4 y todos los demás sistemas operativos no tienen ningún problema.
Con ese dato, determinamos que Android v5 y versiones posteriores insisten en usar IPv6 para la resolución de nombres DNS. (Dado que hemos deshabilitado completamente IPv6 en nuestra red, esto coincide con el problema). Si Android v5 (+) no puede obtener una respuesta IPv6 del DNS local, entonces se comunica con el host de nombre público de Google (8.8.8.8) . Por lo tanto, no hay DNS interno, solo externo.
Solucionamos el problema creando registros DNS en nuestros servidores DNS públicos para nombres e IP internos seleccionados. Una vez hecho esto, el DNS público de Google podría resolver estos nombres internos con IP internas, y los dispositivos podrían llegar a nuestros hosts internos.
Estamos procediendo a habilitar completamente IPv6 en nuestros servidores DNS internos (controladores de dominio) como una solución permanente.
=========================================
ACTUALIZACIÓN– Bueno, resulta que esto puede ser una pista falsa … o no. Mi red doméstica es Win2008R2, de dominio único con DHCP y DNS y sin enlace IPv6. Probé un dispositivo Android v5 desde allí y NO HAY PROBLEMA. La red de la oficina con el problema es Win2012 (no R2), dominio único.
Se omitieron los WAP de oficina actuales con Linksys WAP independientes y SSID separados para las pruebas; el problema persiste.
Diferencias entre redes de oficina y domésticas (que se me ocurren): – Versión de Windows – 2012 vs. 2008 R2 – Modelo de enrutador (Cisco vs. Linksys) – Modelo WAP (Aruba Networks de marca Dell vs. Linksys)
Continuar con todas las pruebas adicionales que se me ocurran para reducir el problema. ¡Cualquier sugerencia o aportación es muy apreciada!
=========================================
EL PROBLEMA SE HA IDO (?!)
Nuestro problema pareció desaparecer por sí solo después de un cambio de topología de red que no creo que esté relacionado, pero aquí está la información por si acaso.
(ENORMES disculpas por esta larga y prolongada historia, pero aquí es cuando nuestros problemas de Android desaparecieron, así que aguanta esto si puedes. Probablemente estoy brindando DEMASIADOS detalles aquí, pero como no puedo ver una conexión directa, Lo expongo todo exactamente como sucedió).
Nuestro ISP es Comcast Business Class, un cable módem con static Bloque de IP de cinco direcciones (número extraño, pero así es como las vende Comcast). El cable módem de Comcast es esencialmente una combinación de módem / firewall / enrutador / conmutador, con nuestro static Bloque de IP programado de forma remota en él.
Durante más de 10 años y casi la misma cantidad de empleadores, siempre he construido redes de oficina de la misma manera:
Configure una IP de LAN para el módem / enrutador ISP, cuyo tráfico NAT desde Internet. No podría ser más sencillo, y así es como se ha configurado la red de mi oficina actual durante cuatro años.
Recientemente, el servicio de Internet de nuestra oficina dejó de funcionar. Por lo general, un reinicio del módem lo corrige, pero cuando no fue así, llamamos a Comcast, quien envió a un técnico, quien reemplazó el cable módem para restaurar el servicio.
Unos días después, volvió a ocurrir lo mismo. Llamamos de nuevo, y la tecnología en el sitio (tecnología diferente a la anterior) intentó reemplazar el módem nuevamente, esta vez con un modelo más nuevo. Sorprendentemente, el módem de cable más nuevo no admitía cambiar la dirección de subred LAN. La subred predeterminada es 10.1.10.0/24 y no se puede cambiar. (Solo se podía configurar el cuarto octeto). Como la subred de nuestra oficina es 192.168.100.0/24, le dije al técnico que no podíamos usarla sin poder cambiar la subred de la LAN. Lo entendió, pero no tenía información de por qué el cable módem evitaría el cambio. Entonces instaló un módem de reemplazo del mismo modelo que antes, que configuramos de manera idéntica, y se restauró el acceso a Internet.
Pasan uno o dos días más y el servicio vuelve a bajar. Esta vez, cuando llamé a Comcast, el técnico inicial con el que hablé me hizo preguntas detalladas y bien informadas sobre la configuración de nuestra red. Cuando le expliqué que el cable módem estaba configurado con una IP LAN en nuestra subred, pareció desconcertado por esto. Dijo que la mayoría de los clientes de Comcast conectan un enrutador NAT entre el módem por cable y la LAN en lugar de utilizar la conexión NAT del módem por cable. De hecho, dijo que no sabía que el módem de cable soportaba NAT.
Comcast envió otra tecnología con un módem de cable nuevo (el último modelo que no admite el cambio de subred LAN). Hizo pruebas exhaustivas en el módem existente y finalmente determinó que solo pasaba tráfico IPv6, no IPv4. También confirmó lo que había dicho el técnico del teléfono: que se recomienda usar un enrutador separado para NAT y no cambiar la subred LAN en el módem de cable (lo que no podemos hacer en los módems más nuevos ahora de todos modos).
Y ahora finalmente llegamos al cambio de red que hicimos. Instalé un enrutador LinkSys simple entre el módem de cable y nuestro enrutador central, configurado con nuestro static IP en el lado del módem y una IP de LAN en el interior. A continuación, se restauró el servicio de Internet y se ha mantenido estable durante algún tiempo.
Después de que se restableció el servicio de Internet, pensé en la rareza del problema de IPv6 con el módem de cable, que a su vez me recordó el problema de Android v5. Luego probé nuestros dispositivos Android en la oficina y me sorprendió ver que el problema de DNS ya no estaba ocurriendo.
Agregar el enrutador LinkSys para NAT es el ÚNICO CAMBIO DE RED QUE HACEMOS. ¿¿Coincidencia?? Posiblemente, pero parecía un poco peculiar que ambos estuvieran relacionados con IPv6.
De todos modos, lo siento de nuevo por la larga historia, pero nuestro problema con Android se ha ido. Haz lo que puedas con eso.
Dimarc67
Encontré esta publicación mientras intentaba que mi dispositivo Android 6.0 usara el servidor DNS configurado localmente para resolver nombres de host locales. Una respuesta anterior indicó que Android 5.0 y versiones posteriores insisten en usar servidores DNS IPv6. Esta fue la pista que me llevó a mi solución.
Mi enrutador anunciaba los servidores DNS IPv6 proporcionados por mi ISP mediante DHCP-PD. Reconfiguré mi enrutador para dejar de anunciar los servidores DNS IPv6 y ahora el dispositivo Android 6.0 está resolviendo el nombre de host local utilizando el servidor DNS IPv4 proporcionado por DHCP (IPv4).
También tengo un DNAT para redirigir todas las consultas de DNS (puerto 53 de TCP / UDP) a mi servidor DNS local. Esto estaba en su lugar antes de deshabilitar el anuncio del enrutador con servidores DNS IPv6, por lo que no sé si Android 5.0+ recurre a los servidores DNS de Google (como se afirma en la respuesta anterior) y los atrapé con mi regla DNAT o si mi Android 6.0 dispositivo acaba de utilizar el servidor DNS IPv4 asignado por DHCP. De cualquier manera, la resolución de nombre de host local está funcionando ahora.
Finalmente pude resolver esto configurando un servidor DHCP yo mismo en la misma red, que configura el dominio de búsqueda correcto para enviar a los clientes.
Una vez tuve un servidor dhcp, en mi caso isc-dhcpd con la configuración en dhcp.conf:
option domain-name "myrealdomain.tld";
Android pudo resolver los registros A locales establecidos en mi servidor DNS.
Si conservas alguna desconfianza y disposición de enriquecer nuestro post puedes escribir un informe y con gusto lo observaremos.