¿Por qué Android se niega a resolver los registros DNS que apuntan a direcciones IP internas?

Recientemente nos encontramos con este problema y lo redujimos para que ocurra SOLO en dispositivos con Android v5 y posteriores. Android v4 y todos los demás sistemas operativos no tienen ningún problema.

Con ese dato, determinamos que Android v5 y posteriores insisten en usar IPv6 para la resolución de nombres DNS. (Dado que hemos deshabilitado por completo IPv6 en nuestra red, esto concuerda con el problema). Si Android v5 (+) no puede obtener una respuesta de 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 con la habilitación completa de 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 TENGO PROBLEMAS. La red de la oficina con el problema es Win2012 (no R2), dominio único.

Se omitieron los WAP de oficina actuales con WAP independiente de Linksys y SSID separado para realizar pruebas, el problema persiste.

Diferencias entre las redes domésticas y de oficina (que se me ocurran): - Versión de Windows - 2012 frente a 2008 R2 - Modelo de enrutador (Cisco frente a Linksys) - Modelo WAP (Redes Aruba de la marca Dell frente a Linksys)

Continuando con cualquier prueba adicional que se me ocurra para reducir el problema. ¡Cualquier sugerencia o entrada es extremadamente apreciada!

=========================================

EL PROBLEMA SE ACABÓ (?!)

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.

(MUCHÍSIMAS DISCULPAS por esta larga y dilatada historia, pero aquí es cuando desaparecieron nuestros problemas con Android, así que solucione esto si puede. Probablemente estoy proporcionando 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 módem por cable con un bloque de IP estático de cinco direcciones (un número extraño, pero así es como los vende Comcast). El módem por cable de Comcast es esencialmente una combinación de módem/cortafuegos/enrutador/conmutador, con nuestro bloque de IP estática programado de forma remota en él.

Durante más de 10 años y casi la misma cantidad de empleadores, siempre construí redes de oficina de la misma manera:
configure una IP de LAN para el módem/enrutador ISP, que NAT trafica desde Internet. No podría ser más sencillo, y así ha estado configurada la red de mi oficina actual durante cuatro años.

Recientemente, el servicio de Internet de nuestra oficina se cayó. Por lo general, un reinicio del módem lo corrige, pero cuando no lo hizo, 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. Volvimos a llamar y el técnico del sitio (un técnico diferente al anterior) intentó reemplazar el módem nuevamente, esta vez con un modelo más nuevo. Sorprendentemente, el módem por 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 informé al técnico que no podíamos usarla sin poder cambiar la subred LAN. Lo entendió, pero no tenía información sobre por qué el cable módem impediría el cambio. Así que instaló un módem de reemplazo del mismo modelo que antes, que configuramos de manera idéntica, y se restableció el acceso a Internet.

Pasa otro día o dos, y el servicio vuelve a caer. Esta vez, cuando llamé a Comcast, el técnico inicial con el que hablé hizo preguntas detalladas y bien informadas sobre nuestra configuración de red. Cuando le expliqué que el módem por 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 NAT del módem por cable. De hecho, dijo que no sabía que el módem por cable admitía NAT.

Comcast envió a otro técnico con un módem por cable nuevo (el último modelo que no admite cambiar 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 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 por cable (que de todos modos no podemos hacer en los módems más nuevos ahora).

Y ahora finalmente llegamos al cambio de red que hicimos. Instalé un enrutador LinkSys simple entre el módem por cable y nuestro enrutador central, configurado con nuestra IP estática en el lado del módem y una IP LAN en el interior. Luego se restableció el servicio de Internet y se ha mantenido estable desde hace algún tiempo.

Después de que se restauró el servicio de Internet, pensé en la rareza del problema de IPv6 con el cable módem, 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 HEMOS HECHO. ¿¿Coincidencia?? Posiblemente, pero me pareció 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 desapareció. 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 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 usando el servidor DNS IPv4 provisto por DHCP (IPv4).

También tengo un DNAT para redirigir todas las consultas DNS (puerto TCP/UDP 53) 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 El dispositivo 6.0 acaba de usar el servidor DNS IPv4 asignado por DHCP. De cualquier manera, la resolución del 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.