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.