توفّر وحدة "برنامج حلّ نظام أسماء النطاقات" حماية للمستخدمين من هجمات اعتراض طلبات 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.