El módulo DNS Resolver brinda protección al usuario para la interceptación de DNS y 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 sistema de resolución de código auxiliar de DNS, que traduce nombres como www.google.com a direcciones IP como 2001:db8::1 . El sistema de resolución de stubs de DNS respalda elementos de la API de Java, como InetAddress#getAllByName y Network#getAllByName , así como funciones de red nativas , e implementa el envío y la recepción de consultas de DNS y el almacenamiento en caché de los resultados.
Cambios en Android 10
En los dispositivos que ejecutan Android 9 y versiones anteriores, el código de resolución de DNS se distribuye entre Bionic y netd . Las búsquedas de DNS están centralizadas en el demonio netd para permitir el almacenamiento en caché en todo el sistema, mientras que las aplicaciones llaman a funciones (como getaddrinfo ) en Bionic. La consulta se envía a través de un socket UNIX a /dev/socket/dnsproxyd al demonio netd , que analiza la solicitud y vuelve a llamar a getaddrinfo para realizar búsquedas de DNS, luego almacena en caché los resultados para que otras aplicaciones puedan usarlos. La implementación de la resolución de DNS estaba contenida principalmente en bionic/libc/dns/ y en parte en system/netd/server/dns .
Android 10 mueve el código de resolución de DNS a system/netd/resolv, lo convierte a C++, luego moderniza y refactoriza el código. El código en Bionic continúa existiendo por razones de compatibilidad de aplicaciones, pero el sistema ya no lo llama. Estas rutas de origen se ven afectadas por la 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 se entrega como un archivo APEX y netd lo vincula dinámicamente; sin embargo, netd no es una dependencia ya que el módulo sirve directamente al socket local /dev/socket/dnsproxyd . El punto final de Binder para la configuración del resolutor se movió de netd al resolutor, lo que significa que el servicio del sistema puede llamar directamente al módulo de resolución sin pasar por netd .
El módulo DNS Resolver depende de libc (Bionic) y vincula estáticamente sus dependencias; no se requieren otras bibliotecas.
mDNS .resolución local
A partir de noviembre de 2021, el sistema de resolución de Android es compatible con la resolución mDNS .local, que implementa "5.1 Consultas de DNS de multidifusión únicas" en RFC 6762 para enviar consultas de DNS estándar a ciegas 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 termine en *.local .
La resolución mDNS .local aumenta la funcionalidad existente de getaddrinfo() para obtener las direcciones. Si un dispositivo es compatible con la resolución local de mDNS, la API getaddrinfo() envía consultas de mDNS a 224.0.0.251:5353 o [FF02::FB]:5353 y devuelve las direcciones locales. Si un dispositivo no es compatible con mDNS .resolución local, entonces el método API getaddrinfo() envía una consulta DNS al servidor DNS.
El código está en AOSP, ubicado 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 regular enviada a las direcciones de multidifusión de mDNS. Esta característica no tiene impacto en la salud del sistema.
Los usuarios pueden usar el comando adb shell ping6 HOSTNAME .local , donde HOSTNAME es el nombre de host de un dispositivo de destino en la LAN, por ejemplo, adb shell ping6 ipad.local .
Las conexiones de datos móviles y VPN están excluidas de la resolución .local.