Resolver DNS

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.