از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
حل کننده DNS
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
ماژول 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 مستثنی هستند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# DNS Resolver\n\nThe DNS Resolver module provides user protection for DNS interception\nand configuration update attacks and improved network performance for DNS\nresolutions. The module contains the code that implements the DNS stub\nresolver, which translates names such as **www.google.com** to IP\naddresses such as **2001:db8::1** . The DNS stub resolver backs\nJava API elements such as\n[InetAddress#getAllByName](https://developer.android.com/reference/java/net/InetAddress#getAllByName(java.lang.String)) and\n[Network#getAllByName](https://developer.android.com/reference/android/net/Network#getAllByName(java.lang.String)), as well as\n[native networking functions](https://developer.android.com/ndk/reference/group/networking), and implements sending and\nreceiving DNS queries and caching the results.\n\nChanges in Android 10\n---------------------\n\n\nOn devices running Android 9 and lower, the DNS resolver code is spread across\nBionic and `netd`. DNS lookups are centralized in the\n`netd` daemon to allow for system-wide caching, while apps\ncall functions (such as `getaddrinfo`) in Bionic. The query is sent\nover a UNIX socket to `/dev/socket/dnsproxyd` to the\n`netd` daemon, which parses the request and calls\n`getaddrinfo` again to issue DNS lookups, then caches the results\nso that other apps can use them. The DNS resolver implementation was mostly\ncontained in `bionic/libc/dns/` and partly in\n`system/netd/server/dns`.\n\n\nAndroid 10 moves the DNS resolver code to\n`system/netd/resolv,` converts it to C++, then modernizes and\nrefactors the code. The code in Bionic continues to exist for app\ncompatibility reasons, but is no longer called by the system. These source\npaths are affected by the refactoring:\n\n- `bionic/libc/dns`\n- `system/netd/client`\n- `system/netd/server/dns`\n- `system/netd/server/DnsProxyListener`\n- `system/netd/server/ResolverController`\n- `system/netd/resolv`\n\nFormat and dependencies\n-----------------------\n\n\nThe DNS Resolver module (\\`com.android.resolv\\`) is delivered as an\n[APEX](/docs/core/ota/apex) file and is dynamically linked by\n`netd`; however, `netd` is **not** a\ndependency as the module serves the local socket\n`/dev/socket/dnsproxyd` directly. The Binder endpoint for the\nresolver configuration was moved from `netd` to the resolver,\nmeaning that the system service can call directly into the resolver module\nwithout going through `netd`.\n\n\nThe DNS Resolver module depends on `libc` (Bionic) and\nstatically links its dependencies; no other libraries are required.\n\nmDNS .local resolution\n----------------------\n\nStarting from November 2021, Android resolver supports mDNS .local resolution, which implements\n\"5.1 One-Shot multicast DNS Queries\" in RFC 6762 to send standard DNS queries blindly to\n224.0.0.251:5353 or \\[FF02::FB\\]:5353. mDNS resolution is transparently supported\nby calling `getaddrinfo()` with a hostname ending in `*.local`.\n\nmDNS .local resolution augments the existing functionality of `getaddrinfo()`\nto get the addresses. If a device supports mDNS .local resolution, then the\n`getaddrinfo()` API sends mDNS queries to 224.0.0.251:5353 or \\[FF02::FB\\]:5353\nand returns the local addresses. If a device doesn't support mDNS .local\nresolution, then the `getaddrinfo()` API method sends a DNS query to the DNS\nserver.\n\nThe code is in AOSP, located in `packages/modules/DnsResolver`. Users can keep their\ncurrent mDNS design to get the addresses, or use `getaddrinfo()` instead. The behavior of\nthis feature is like a regular DNS query sent to the mDNS multicast addresses. This feature has no\nimpact on system health.\n\nUsers can use the command `adb shell ping6 `\u003cvar translate=\"no\"\u003eHOSTNAME\u003c/var\u003e`.local`,\nwhere \u003cvar translate=\"no\"\u003eHOSTNAME\u003c/var\u003e is the hostname of a target device on the LAN, for example,\n`adb shell ping6 ipad.local`.\n\nVPN and mobile data connections are excluded from .local resolution."]]
