Agente de resolución de DNS

El módulo del agente de resolución de DNS proporciona protección al usuario contra la interceptación de DNS y los ataques de actualización de configuración, y mejora el rendimiento de la red para las resoluciones de DNS. El módulo contiene el código que implementa el agente de resolución de stub de DNS, que traduce nombres como www.google.com a direcciones IP como 2001:db8::1. El solucionador de stub de DNS admite elementos de la API de Java, como InetAddress#getAllByName y Network#getAllByName, así como funciones de red nativas, y también implementa el envío y la recepción de consultas de DNS, y almacena en caché los resultados.

Cambios en Android 10

En dispositivos que ejecutan Android 9 y versiones anteriores, el código del solucionador de DNS se distribuye entre Bionic y netd. Las búsquedas de DNS se centralizan en el daemon netd para permitir el almacenamiento en caché en todo el sistema, mientras que las apps llaman a funciones (como getaddrinfo) en Bionic. La consulta se envía a través de un socket UNIX a /dev/socket/dnsproxyd al daemon netd, que analiza la solicitud y vuelve a llamar a getaddrinfo para emitir búsquedas de DNS y, luego, almacena en caché los resultados para que otras apps puedan usarlos. La implementación del agente de resolución de DNS se encontraba principalmente en bionic/libc/dns/ y, en parte, en system/netd/server/dns.

Android 10 mueve el código del solucionador de DNS a system/netd/resolv,, lo convierte a C++, luego lo moderniza y refactoriza. El código en Bionic sigue existiendo por motivos de compatibilidad con la app, pero el sistema ya no lo llama. Estas rutas de origen se ven afectadas por el refactorización:

  • bionic/libc/dns
  • system/netd/client
  • system/netd/server/dns
  • system/netd/server/DnsProxyListener
  • system/netd/server/ResolverController
  • system/netd/resolv

Formato y dependencias

El módulo DNS Resolver ("com.android.resolv") se entrega como un archivo APEX y netd lo vincula de forma dinámica. Sin embargo, netd no es una dependencia, ya que el módulo entrega el socket local /dev/socket/dnsproxyd directamente. El extremo de Binder para la configuración del resolvedor se trasladó de netd al resolvedor, lo que significa que el servicio del sistema puede llamar directamente al módulo del resolvedor sin pasar por netd.

El módulo DNS Resolver depende de libc (Bionic) y vincula sus dependencias de forma estática. No se requieren otras bibliotecas.

Resolución local de mDNS

A partir de noviembre de 2021, el solucionador de Android admite la resolución .local de mDNS, que implementa las "Consultas de DNS multicast únicas 5.1" en RFC 6762 para enviar consultas de DNS estándar de forma ciega a 224.0.0.251:5353 o [FF02::FB]:5353. La resolución de mDNS se admite de forma transparente llamando a getaddrinfo() con un nombre de host que termina en *.local.

La resolución local de mDNS aumenta la funcionalidad existente de getaddrinfo() para obtener las direcciones. Si un dispositivo admite la resolución .local de mDNS, la API de getaddrinfo() envía consultas de mDNS a 224.0.0.251:5353 o [FF02::FB]:5353 y muestra las direcciones locales. Si un dispositivo no admite la resolución .local de mDNS, el método de la API de getaddrinfo() envía una consulta de DNS al servidor DNS.

El código está en AOSP, en packages/modules/DnsResolver. Los usuarios pueden mantener su diseño de mDNS actual para obtener las direcciones o usar getaddrinfo() en su lugar. El comportamiento de esta función es como una consulta de DNS normal que se envía a las direcciones multicast de mDNS. Esta función no tiene ningún efecto en el estado del sistema.

Los usuarios pueden usar el comando adb shell ping6 HOSTNAME.local, en el que HOSTNAME es el nombre de host de un dispositivo de destino en la LAN, por ejemplo, adb shell ping6 ipad.local.

Las conexiones de VPN y de datos móviles se excluyen de la resolución .local.