Moduł rozpoznawania nazw DNS zapewnia ochronę użytkowników przed przechwytywaniem DNS ataki i aktualizacje konfiguracji oraz poprawiły wydajność sieci dla DNS rozwiązań. Moduł zawiera kod implementujący atrapę DNS. resolver, który tłumaczy nazwy takie jak www.google.pl na IP takich jak 2001:db8::1. Program do rozpoznawania wersji DNS sięga wstecz Elementy interfejsu API Java, takie jak InetAddress#getAllByName i Network#getAllByName, a także natywnych funkcji sieci oraz implementuje wysyłanie i odbieranie zapytań DNS i zapisywanie wyników w pamięci podręcznej.
Zmiany w Androidzie 10
Na urządzeniach z Androidem 9 lub starszym kod resolvera DNS jest rozłożony
Bionic i netd. Wyszukiwanie DNS jest scentralizowane
demon netd umożliwiający buforowanie w całym systemie, podczas gdy aplikacje
funkcji wywoływania (takich jak getaddrinfo) w Bionic. Zapytanie zostanie wysłane
przez gniazdo UNIX do /dev/socket/dnsproxyd
demona netd, który analizuje żądanie i wywołuje żądanie.
getaddrinfo jeszcze raz, aby przeprowadzić wyszukiwania DNS, a następnie zapisze wyniki w pamięci podręcznej
aby inne aplikacje mogły z nich korzystać. Implementacja resolvera DNS polegała głównie na
zawarte w bionic/libc/dns/ i częściowo w
system/netd/server/dns
Android 10 przenosi kod resolvera DNS do
system/netd/resolv, konwertuje na C++, a następnie modernizuje
refaktoryzuje kod. Kod aplikacji Bionic nadal istnieje.
związane ze zgodnością, ale nie jest już wywoływany przez system. Te źródła
na ścieżki wpływa refaktoryzacja:
bionic/libc/dnssystem/netd/clientsystem/netd/server/dnssystem/netd/server/DnsProxyListenersystem/netd/server/ResolverControllersystem/netd/resolv
Format i zależności
Moduł rozpoznawania nazw DNS (`com.android.resolv`) jest dostarczany jako
APEX i jest dynamicznie połączony przez
netd; jednak netd nie jest
gdy moduł obsługuje gniazdo lokalne
bezpośrednio /dev/socket/dnsproxyd. Punkt końcowy Binder dla
konfiguracja resolvera została przeniesiona z netd do resolvera,
co oznacza, że usługa systemowa może wywoływać bezpośrednio do modułu resolvera
bez przejazdu przez netd.
Moduł rozpoznawania nazw DNS korzysta z usług libc (Bionic) i
statycznie łączy zależności; nie są wymagane żadne inne biblioteki.
Rozpoznawanie plików mDNS w formacie lokalnym
Od listopada 2021 r. resolver na Androida obsługuje rozpoznawanie plików mDNS z rozszerzeniem .local, które implementuje
„5.1 One-Shot Multicast DNS Zapytania” (5.1 Zapytania DNS typu One-Shot) w RFC 6762, aby ślepo wysyłać standardowe zapytania DNS do
224.0.0.251:5353 lub [FF02::FB]:5353. Rozpoznawanie nazw mDNS jest w przejrzysty sposób obsługiwane
Wywołując funkcję getaddrinfo() z nazwą hosta kończącą się na *.local.
Rozdzielczość mDNS zwiększa obecne funkcje getaddrinfo()
aby uzyskać adresy. Jeśli urządzenie obsługuje rozpoznawanie plików mDNS z rozszerzeniem .local,
Interfejs API getaddrinfo() wysyła zapytania mDNS na numer 224.0.0.251:5353 lub [FF02::FB]:5353
i zwraca adresy lokalne. Jeśli urządzenie nie obsługuje pliku mDNS .local
rozpoznawanie, metoda interfejsu API getaddrinfo() wyśle zapytanie DNS do systemu DNS
serwera.
Kod jest w AOSP w regionie packages/modules/DnsResolver. Użytkownicy mogą zachować
aktualnego projektu mDNS, aby uzyskać adresy, lub użyj zamiast tego funkcji getaddrinfo(). Działanie funkcji
Ta funkcja przypomina zwykłe zapytanie DNS wysyłane na adresy transmisji grupowej mDNS. Ta funkcja nie ma
wpływ 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
Połączenia VPN i mobilnej transmisji danych nie są obsługiwane w rozdzielczości z rozszerzeniem .local.