اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
برنامج تعيين نظام أسماء النطاقات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توفّر وحدة "برنامج حلّ نظام أسماء النطاقات" حماية للمستخدمين من هجمات اعتراض طلبات DNS
وهجمات تعديل الإعدادات، كما تُحسِّن أداء الشبكة في ما يتعلّق بطلبات DNS. تحتوي الوحدة على الرمز البرمجي الذي ينفِّذ معالج عناوين IP
في نظام أسماء النطاقات (DNS)، والذي يحوِّل الأسماء مثل www.google.com إلى عناوين IP
مثل 2001:db8::1. يتوافق مع عنصرَي واجهة برمجة التطبيقات Java API، وهما
InetAddress#getAllByName و
Network#getAllByName، بالإضافة إلى
وظائف الشبكات الأصلية، وينفِّذ إرسال وتلقّي طلبات بحث نظام أسماء النطاقات وتخزين النتائج مؤقتًا.
التغييرات في Android 10
على الأجهزة التي تعمل بنظام التشغيل Android 9 والإصدارات الأقدم، يتم توزيع رمز أداة حلّ نظام أسماء النطاقات على
Bionic وnetd. يتم تجميع عمليات البحث في نظام أسماء النطاقات في ملف netd الخدمي لتوفير ميزة التخزين المؤقت على مستوى النظام، بينما تستدعي التطبيقات الدوال (مثل getaddrinfo) في Bionic. يتم إرسال طلب البحث
عبر مقبس UNIX إلى /dev/socket/dnsproxyd إلى
الخادم الدائم netd الذي يحلّل الطلب ويطلب
getaddrinfo مرة أخرى لإصدار عمليات بحث نظام أسماء النطاقات، ثم يخزِّن النتائج
حتى تتمكّن التطبيقات الأخرى من استخدامها. كان تنفيذ أداة حلّ نظام أسماء النطاقات في أغلبه
مضمّنًا في bionic/libc/dns/ وجزئيًا في
system/netd/server/dns.
ينقل نظام التشغيل Android 10 رمز أداة حلّ نظام أسماء النطاقات إلى
system/netd/resolv, ويحوّله إلى C++، ثمّ يحسّنه ويعيد
تنظيمه. سيظل الرمز البرمجي في Bionic متوفّرًا لأسباب تتعلّق بالتوافق مع التطبيقات، ولكن لم يعُد النظام يستدعيه. تتأثّر مسارات المصدر
التالية بعملية إعادة التنظيم:
bionic/libc/dnssystem/netd/clientsystem/netd/server/dnssystem/netd/server/DnsProxyListenersystem/netd/server/ResolverControllersystem/netd/resolv
يتم عرض وحدة حلّ نظام أسماء النطاقات ("com.android.resolv") كملف
APEX ويتم ربطها ديناميكيًا باستخدام
netd. ومع ذلك، netd ليس أحد تبعات
لأنّ الوحدة تعرِض المقبس المحلي
/dev/socket/dnsproxyd مباشرةً. تم نقل نقطة نهاية Binder لإعدادات
وحدة التحويل من netd إلى وحدة التحويل،
ما يعني أنّ خدمة النظام يمكنها الاتصال مباشرةً بوحدة التحويل
بدون المرور عبر netd.
تعتمد وحدة حلّ نظام أسماء النطاقات على libc (Bionic) و
وتربطها بشكلٍ ثابت بعناصرها المُستندة إليها، ولا يلزم استخدام أي مكتبات أخرى.
دقة mDNS .local
اعتبارًا من تشرين الثاني (نوفمبر) 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، ستُرسِل getaddrinfo() API طلبات بحث mDNS إلى 224.0.0.251:5353 أو [FF02::FB]:5353، ثم ستُعرِض العناوين المحلية. إذا كان الجهاز لا يتيح تحليل mDNS .local
، تُرسِل طريقة واجهة برمجة التطبيقات getaddrinfo() طلب بحث نظام أسماء النطاقات إلى خادم نظام أسماء النطاقات.
الرمز متوفر في AOSP، ويقع في packages/modules/DnsResolver. يمكن للمستخدمين الاحتفاظ
بتصميم mDNS الحالي للحصول على العناوين، أو استخدام getaddrinfo() بدلاً من ذلك. يشبه سلوك
هذه الميزة طلب بحث نظام أسماء النطاقات العادي الذي يتم إرساله إلى عناوين البث المتعدد لنظام أسماء النطاقات ذي البث المتعدد (mDNS). ولا تؤثر هذه الميزة في
حالة النظام.
يمكن للمستخدمين استخدام الأمر adb shell ping6 HOSTNAME.local،
حيث يكون HOSTNAME هو اسم المضيف لجهاز مستهدف على الشبكة المحلية، على سبيل المثال،
adb shell ping6 ipad.local.
يتم استبعاد عمليات الاتصال بشبكة VPN وبيانات الجوّال من عملية تحديد عناوين .local.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
