Moduł DNS Resolver zapewnia ochronę użytkownika przed przechwyceniem DNS i atakami związanymi z aktualizacją konfiguracji oraz lepszą wydajność sieci w przypadku rozpoznawania DNS. Moduł zawiera kod implementujący funkcję rozpoznawania kodu pośredniczącego DNS, która tłumaczy nazwy takie jak www.google.com na adresy IP, takie jak 2001:db8::1 . Narzędzie rozpoznawania kodu pośredniczącego DNS obsługuje elementy interfejsu API języka Java, takie jak InetAddress#getAllByName i Network#getAllByName , a także natywne funkcje sieciowe oraz implementuje wysyłanie i odbieranie zapytań DNS oraz buforowanie wyników.
Zmiany w Androidzie 10
Na urządzeniach z Androidem 9 i starszym kod rozpoznawania nazw DNS jest rozpowszechniany w Bionic i netd
. Wyszukiwania DNS są scentralizowane w demonie netd
, aby umożliwić buforowanie w całym systemie, podczas gdy 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
w celu przeprowadzenia wyszukiwania DNS, a następnie buforuje wyniki, aby inne aplikacje mogły z nich korzystać. Implementacja programu rozpoznawania nazw DNS była zawarta głównie w bionic/libc/dns/
, a częściowo w system/netd/server/dns
.
Android 10 przenosi kod rozpoznawania nazw DNS do system/netd/resolv,
konwertuje go do C++, a następnie modernizuje i refaktoryzuje kod. Kod w Bionic nadal istnieje ze względu na kompatybilność aplikacji, ale nie jest już wywoływany przez system. Refaktoryzacja ma wpływ na te ścieżki źródłowe:
-
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ści
Moduł rozpoznawania DNS (`com.android.resolv`) jest dostarczany jako plik APEX i jest dynamicznie łączony przez netd
; jednakże netd
nie jest zależnością, ponieważ moduł obsługuje bezpośrednio lokalne gniazdo /dev/socket/dnsproxyd
. Punkt końcowy Binder dla konfiguracji resolwera został przeniesiony z netd
do resolwera, co oznacza, że usługa systemowa może wywoływać bezpośrednio moduł resolwera bez przechodzenia przez netd
.
Moduł DNS Resolver zależy od libc
(Bionic) i statycznie łączy jej zależności; żadne inne biblioteki nie są wymagane.
Rozdzielczość lokalna mDNS
Od listopada 2021 r. narzędzie do rozpoznawania nazw dla systemu Android obsługuje rozpoznawanie mDNS .local, które implementuje „5.1 One-Shot multicast DNS Queries” w dokumencie RFC 6762 w celu ślepego wysyłania standardowych zapytań DNS do 224.0.0.251:5353 lub [FF02::FB]:5353. Rozpoznawanie mDNS jest obsługiwane w przejrzysty sposób poprzez wywołanie metody getaddrinfo()
z nazwą hosta kończącą się na *.local
.
Rozdzielczość lokalna mDNS rozszerza istniejącą funkcjonalność getaddrinfo()
w celu uzyskania adresów. Jeśli urządzenie obsługuje rozpoznawanie .local mDNS, funkcja API getaddrinfo()
wysyła zapytania mDNS do 224.0.0.251:5353 lub [FF02::FB]:5353 i zwraca adresy lokalne. Jeśli urządzenie nie obsługuje rozpoznawania mDNS .local, wówczas metoda API getaddrinfo()
wysyła zapytanie DNS do serwera DNS.
Kod znajduje się w AOSP, zlokalizowanym w packages/modules/DnsResolver
. Użytkownicy mogą zachować swój aktualny projekt mDNS, aby uzyskać adresy, lub zamiast tego użyć metody getaddrinfo()
. Zachowanie tej funkcji przypomina zwykłe zapytanie DNS wysyłane na adresy multiemisji mDNS. Ta funkcja nie ma wpływu na kondycję 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
.
VPN i mobilne połączenia danych są wyłączone z rozdzielczości .local.