Moduł DNS Resolver zapewnia użytkownikom ochronę przed przechwytywaniem DNS i atakami na aktualizacje konfiguracji oraz poprawia wydajność sieci w przypadku rozwiązywania adresów DNS. Moduł zawiera kod, który wdraża stub DNS resolvera, który przekształca nazwy takie jak www.google.com w adresy IP takie jak 2001:db8::1. Rozwiązanie podrzędne DNS obsługuje elementy interfejsu API Java, takie jak InetAddress#getAllByName i Network#getAllByName, a także rodzime funkcje sieciowe. Umożliwia też wysyłanie i odbieranie zapytań DNS oraz buforowanie wyników.
Zmiany w Androidzie 10
Na urządzeniach z Androidem 9 lub starszym kod rozwiązywania nazw DNS jest rozproszony między Bionic i netd
. Wyszukiwania DNS są scentralizowane w demonie netd
, aby umożliwić buforowanie w całym systemie, a aplikacje wywołują funkcje (takie jak getaddrinfo
) w Bionic. Zapytanie jest wysyłane przez gniazdo UNIX do /dev/socket/dnsproxyd
do demona netd
, który analizuje żądanie i ponownie wywołuje getaddrinfo
, aby przeprowadzić wyszukiwania DNS, a następnie zapisuje wyniki w pamięci podręcznej, aby inne aplikacje mogły z nich korzystać. Implementacja rozwiązywania nazw DNS była głównie zawarta w bionic/libc/dns/
i częściowo w system/netd/server/dns
.
Android 10 przenosi kod rozwiązywania nazw DNS do system/netd/resolv,
, przekształca go w C++, a potem modernizuje i refaktoryzuje. Kod w Bionic nadal istnieje ze względu na zgodność aplikacji, ale system go już nie wywołuje. Refaktoryzacja ma wpływ na te ścieżki źródeł:
bionic/libc/dns
system/netd/client
system/netd/server/dns
system/netd/server/DnsProxyListener
system/netd/server/ResolverController
system/netd/resolv
Format i zależność
Moduł DNS Resolver (`com.android.resolv`) jest dostarczany jako plik APEX i jest dynamicznie linkowany przez netd
. Jednak netd
nie jest zależnością, ponieważ moduł obsługuje lokalny gniazdo /dev/socket/dnsproxyd
bezpośrednio. Punkt końcowy Bindera dla konfiguracji rozwiązywania został przeniesiony z netd
do rozwiązywania, co oznacza, że usługa systemowa może wywoływać bezpośrednio moduł rozwiązywania bez przechodzenia przez netd
.
Moduł DNS Resolver jest zależny od libc
(Bionic) i łączy statycznie swoje zależności; nie są wymagane żadne inne biblioteki.
Rozpoznawanie nazw mDNS .local
Od listopada 2021 r. rozwiązywanie adresów mDNS .local jest obsługiwane przez rozwiązujący na Androidzie. Rozwiązujący ten implementuje „5.1 One-Shot multicast DNS Queries” w RFC 6762, aby wysyłać standardowe zapytania DNS do 224.0.0.251:5353 lub [FF02::FB]:5353. Rozwiązywanie mDNS jest obsługiwane w przez wywołanie getaddrinfo()
z nazwą hosta kończącą się na *.local
.
Rozwiązanie mDNS .local rozszerza dotychczasową funkcjonalność getaddrinfo()
o uzyskiwanie adresów. Jeśli urządzenie obsługuje rozwiązywanie adresów mDNS .local, interfejs API getaddrinfo()
wysyła zapytania mDNS do adresu 224.0.0.251:5353 lub [FF02::FB]:5353 i zwraca adresy lokalne. Jeśli urządzenie nie obsługuje rozwiązywania nazw mDNS .local, metoda interfejsu API getaddrinfo()
wysyła zapytanie DNS do serwera DNS.
Kod znajduje się w AOSP w folderze packages/modules/DnsResolver
. Użytkownicy mogą zachować obecny projekt mDNS, aby uzyskać adresy, lub użyć getaddrinfo()
. Działanie tej funkcji jest podobne do zwykłego zapytania DNS wysyłanego do adresów multicastowych mDNS. Ta funkcja nie ma wpływu na stan systemu.
Użytkownicy mogą użyć polecenia adb shell ping6 HOSTNAME.local
,
gdzie HOSTNAME to nazwa hosta urządzenia docelowego w sieci LAN, na przykład adb shell ping6 ipad.local
.
Rozwiązania .local nie dotyczą połączeń VPN ani komórkowej transmisji danych.