ماژول DNS Resolver حفاظت کاربر را برای حملات DNS و حملات به روز رسانی پیکربندی و بهبود عملکرد شبکه برای وضوح DNS فراهم می کند. ماژول حاوی کدی است که حل‌کننده خرد DNS را پیاده‌سازی می‌کند، که نام‌هایی مانند www.google.com را به آدرس‌های IP مانند 2001:db8::1 ترجمه می‌کند. حل‌کننده خرد DNS از عناصر Java API مانند InetAddress#getAllByName و Network#getAllByName و همچنین توابع شبکه بومی پشتیبانی می‌کند و ارسال و دریافت پرسش‌های DNS و ذخیره‌سازی نتایج را پیاده‌سازی می‌کند.
تغییرات اندروید 10
در دستگاه‌های دارای Android 9 و پایین‌تر، کد حل‌کننده DNS در Bionic و netd پخش می‌شود. جستجوهای DNS در شبح netd متمرکز هستند تا امکان ذخیره سازی در سراسر سیستم را فراهم کنند، در حالی که برنامه ها توابع (مانند getaddrinfo ) را در Bionic فراخوانی می کنند. پرس و جو از طریق سوکت یونیکس به /dev/socket/dnsproxyd به شبح netd ارسال می شود، که درخواست را تجزیه می کند و دوباره getaddrinfo فراخوانی می کند تا جستجوهای DNS را صادر کند، سپس نتایج را ذخیره می کند تا سایر برنامه ها بتوانند از آنها استفاده کنند. پیاده سازی حل کننده DNS بیشتر در bionic/libc/dns/ و تا حدی در system/netd/server/dns موجود بود.
اندروید 10 کدهای حل‌کننده DNS را به system/netd/resolv, آن را به C++ تبدیل می‌کند، سپس کد را مدرن‌سازی و تغییر می‌دهد. کد موجود در Bionic به دلایل سازگاری برنامه ها همچنان وجود دارد، اما دیگر توسط سیستم فراخوانی نمی شود. این مسیرهای مبدأ تحت تأثیر refactoring قرار می گیرند:
-
bionic/libc/dns -
system/netd/client -
system/netd/server/dns -
system/netd/server/DnsProxyListener -
system/netd/server/ResolverController -
system/netd/resolv
قالب و وابستگی ها
ماژول DNS Resolver (`com.android.resolv`) به عنوان یک فایل APEX تحویل داده می شود و به صورت پویا توسط netd پیوند داده می شود. با این حال، netd یک وابستگی نیست زیرا ماژول به طور مستقیم به سوکت محلی /dev/socket/dnsproxyd سرویس می دهد. نقطه پایانی Binder برای پیکربندی رزولوگر از netd به حل‌کننده منتقل شد، به این معنی که سرویس سیستم می‌تواند مستقیماً بدون عبور از netd به ماژول حل‌کننده فراخوانی کند.
ماژول DNS Resolver به libc (Bionic) وابسته است و وابستگی های آن را به صورت ایستا پیوند می دهد. هیچ کتابخانه دیگری مورد نیاز نیست.
وضوح محلی mDNS
از نوامبر 2021، حل‌کننده Android از وضوح mDNS .local پشتیبانی می‌کند، که «5.1 One-Shot multicast DNS Queries» را در RFC 6762 پیاده‌سازی می‌کند تا پرسش‌های DNS استاندارد را کورکورانه به 224.0.0.251:5353 یا [FF02:FB]:5353 ارسال کند. وضوح mDNS با فراخوانی getaddrinfo() با نام میزبانی که به *.local ختم می‌شود، به طور شفاف پشتیبانی می‌شود.
وضوح mDNS .local عملکرد موجود getaddrinfo() را برای دریافت آدرس ها افزایش می دهد. اگر دستگاهی از وضوح mDNS .local پشتیبانی می کند، API getaddrinfo() پرس و جوهای mDNS را به 224.0.0.251:5353 یا [FF02::FB]:5353 ارسال می کند و آدرس های محلی را برمی گرداند. اگر دستگاهی از وضوح mDNS .local پشتیبانی نمی کند، متد getaddrinfo() API یک درخواست DNS را به سرور DNS ارسال می کند.
کد در AOSP است که در packages/modules/DnsResolver قرار دارد. کاربران می توانند طراحی mDNS فعلی خود را برای دریافت آدرس ها حفظ کنند یا به جای آن از getaddrinfo() استفاده کنند. رفتار این ویژگی مانند یک درخواست DNS معمولی است که به آدرس‌های چندپخشی mDNS ارسال می‌شود. این ویژگی هیچ تاثیری بر سلامت سیستم ندارد.
کاربران می توانند از دستور adb shell ping6 HOSTNAME .local استفاده کنند، جایی که HOSTNAME نام میزبان یک دستگاه هدف در شبکه محلی است، به عنوان مثال، adb shell ping6 ipad.local .
VPN و اتصالات داده تلفن همراه از وضوح .local مستثنی هستند.