Recientemente encontramos este problema y lo redujimos a que ocurra 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 tidbit, 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 concuerda con el problema). Si Android v5 (+) no puede obtener una respuesta IPv6 del DNS local, entonces llega al host de nombre público de Google (8.8.8.8) . Por lo tanto, no hay DNS interno, solo externo.
Trabajamos alrededor del problema creando registros DNS en nuestros servidores DNS públicos para nombres internos e IP 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 un arenque rojo total ... o no. Mi red doméstica es Win2008R2, dominio único con DHCP y DNS y sin enlace IPv6. Probé un dispositivo Android v5 desde allí y NO TENGO NINGÚN PROBLEMA. La red de Office con problema es Win2012 (no R2), dominio único.
Eludió los WAP actuales de la oficina con el WAP de Linksys independiente y el SSID separado para las pruebas, el problema persiste.
Diferencias entre las redes domésticas y de oficina (en las que puedo pensar): - Versión de Windows - 2012 vs. 2008 R2 - modelo de enrutador (Cisco vs. Linksys) - Modelo WAP (Aruba Networks vs. Linksys de la marca Dell)
Continuando con cualquier otra prueba que se me ocurra para acotar el problema. Cualquier sugerencia o entrada es muy apreciada!
=========================================
PROBLEMA IDO (?!)
Nuestro problema pareció desaparecer por sí solo luego de un cambio en la topología de la red que no creo que esté relacionado, pero aquí está la información por si acaso.
(ENORMES DISCULPAS por esta larga y larga historia, pero es cuando nuestros problemas con Android desaparecieron, así que resuélvelo si puedes. Probablemente estoy proporcionando muchos detalles aquí, pero porque no puedo ver una conexión directa, Estoy exponiendo todo exactamente como sucedió).
Nuestro ISP es Comcast Business Class: un módem de cable con un bloque de IP estático de cinco direcciones (número extraño, pero así es como Comcast las vende). El cable módem de Comcast es esencialmente una combinación de módem / firewall / enrutador / conmutador, con nuestro bloque de IP estático programado de forma remota.
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 LAN para el módem / enrutador ISP, que el tráfico de NAT desde Internet. No podría ser más simple, y así es como mi red de oficina actual se ha configurado durante cuatro años.
Recientemente nuestro servicio de internet de la oficina se cayó. Por lo general, un reinicio del módem lo corrige, pero cuando no lo hizo, llamamos a Comcast, que envió un técnico, que reemplazó el módem por cable para restaurar el servicio.
Unos días después, volvió a ocurrir lo mismo. Llamamos nuevamente, 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 cable módem más nuevo no admitía el cambio de la dirección de subred LAN. La subred predeterminada es 10.1.10.0/24 y no se puede cambiar. (Solo el 4to octeto era configurable). Como nuestra subred de la oficina es 192.168.100.0/24, le hice saber al técnico que no podíamos usarla sin poder cambiar la subred LAN. Él entendió, pero no tenía información sobre 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 restableció el acceso a Internet.
Otro día o dos pases, y el servicio vuelve a caer. Esta vez, cuando llamé a Comcast, la tecnología inicial con la que hablé me hizo preguntas detalladas y bien informadas sobre nuestra configuración de red. Cuando le expliqué que el módem de cable estaba configurado con una IP de 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 usar el enrutador NAT del módem por cable. De hecho, dijo que no sabía que el módem por cable soportaba NAT'ing.
Comcast envió otra tecnología con un nuevo cable módem (último modelo que no admite el cambio de la subred LAN). Hizo pruebas exhaustivas en el módem existente y finalmente determinó que solo estaba pasando tráfico IPv6, no IPv4. También confirmó lo que dijo la tecnología 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 de todos modos ahora).
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 nuestra IP estática en el lado del módem y una IP LAN en el interior. El servicio de Internet fue restaurado y se ha mantenido estable por 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 ocurría.
Agregar el enrutador LinkSys para NAT es el ÚNICO CAMBIO DE RED QUE HICIMOS. ¿¿Coincidencia?? Posiblemente, pero parecía un poco peculiar que ambos estuvieran relacionados con IPv6.
De todos modos, perdón por la larga historia, pero nuestro problema con Android se ha ido. Haz lo que puedas de ella.
Dimarc67