# تسرّب DNS: لماذا يجب أن تمرّ استعلامات الأسماء عبر Tor على جهاز Mac

> يكشف استعلام DNS اسمَ الموقع قبل أن يبدأ أي اتصال. كيف يحدث تسرّب DNS على macOS، ولماذا تُعامَل أسماء ‎.onion معاملة خاصة، وكيف تتحقق من وجود تسرّب.

FireAI Security & Research Team (HisnLabs) · Published 2026-10-08
Canonical: https://hisnlabs.com/ar/blog/dns-leaks-tor-macos-per-app-dns

يقع تسرّب DNS حين تُمرَّر حركة تطبيقٍ ما عبر نفق، مثل Tor أو شبكة افتراضية خاصة (VPN)، بينما يظل محلِّل الشبكة المحلية هو من يجيب عن استعلامات الأسماء التي تسبق تلك الحركة. تعرض هذه المذكرة، استنادًا إلى وثائق IETF وقياسات محكَّمة ودليل tor والشيفرة المفتوحة التي تنشرها Apple نفسها، لماذا يهمّ الاستعلام المسرَّب حتى لو كانت كل الاتصالات اللاحقة محمية، ولماذا يجعل محلِّلُ الأسماء في macOS التوجيهَ لكل تطبيق على حدة أصعبَ مما يبدو، وكيف يستطيع القارئ أن يتحقق بنفسه. والفكرة الجوهرية أن الاستعلام ليس بيانات وصفية عن الحركة، بل هو إعلانٌ عن وجهتها يصدر قبل أن تبدأ.

## خلفية

قبل أن يتصل تطبيقٌ بخدمة مسمّاة، لا بد من تحويل الاسم إلى عنوان. وفي الشبكات المعتادة يذهب السؤال، غيرَ مشفَّر، إلى محلِّل تكراري تختاره الشبكة، وهو في الغالب ما يعلنه جهاز التوجيه أو مزوّد خدمة الإنترنت. وتصف وثيقة IETF الخاصة بخصوصية DNS، أي RFC 9076 الصادرة في يوليو 2021، ما على المحكّ بوضوح: «A single transaction reveals both the originator of the query and the query contents; this potentially leaks sensitive information about a specific user»، أي أن معاملة واحدة تكشف صاحب الاستعلام ومضمونه معًا [[1]](https://www.rfc-editor.org/rfc/rfc9076). وتلاحظ الوثيقة أيضًا أن «almost all this DNS traffic is currently sent unencrypted»، أي أن معظم هذه الحركة يُرسَل بلا تشفير [[1]](https://www.rfc-editor.org/rfc/rfc9076). فالنفق الذي يحمل الاتصال دون الاستعلام يترك خارجه أكثرَ أجزاء التبادل دلالةً.

## النتائج

### المحلِّل يعرف الاسم ويعرف من سأل

تخصّ RFC 9076 المحلِّلَ التكراري بأنه الطرف الأوسع اطّلاعًا: «Recursive resolvers see all the traffic since there is typically no caching before them. To summarize: your recursive resolver knows a lot about you»، وتضيف أن محلِّل مزوّد كبير أو محلِّلًا عامًا كبيرًا «can collect data from many users» [[1]](https://www.rfc-editor.org/rfc/rfc9076). وكل من يقف على المسار بين الجهاز ومحلِّل غير مشفَّر، كمشغّل شبكة Wi-Fi عامة، يرى الأسئلة ذاتها. أما تشفير الاستعلام نحو محلِّل عام فيُبعد المراقب المحلي، لكنه لا يُبعد المحلِّل نفسه، إذ يظل يتلقى كل اسم.

### تتسرّب الأنفاق حين يسلك DNS طريقًا آخر

التسرّب عطلٌ موثَّق في الأنفاق التجارية لا احتمالٌ نظري. فقد حلّل Perta وBarbera وTyson وHaddadi وMei «14 of the most popular» من خدمات VPN التجارية، ووجدوا أن «the majority of VPN services suffer from IPv6 traffic leakage»، كما طوّروا هجمات اختطاف DNS أكثر تعقيدًا «that allow all traffic to be transparently captured» (PoPETs، 2015) [[3]](https://petsymposium.org/popets/2015/popets-2015-0006.php). والآلية الشائعة أن تحليل الأسماء يُضبَط بمعزل عن النفق، فقد يكون النفق قائمًا بينما يظل المحلِّل المستخدَم هو محلِّل الشبكة.

### مع Tor، يعين الاستعلام المسرَّب على الربط بين الطرفين

كلفة التسرّب على مستخدمي Tor أكبر من كشف اسم واحد. فقد بيّن Greschbach وPulls وRoberts وWinter وFeamster أن حركة DNS تمنح المراقب فرصًا إضافية لربط طرفَي اتصال Tor: إذ تجمع هجماتهم المسمّاة «DefecTor» بين DNS وتحليل الحركة، ويذكرون أن «an adversary who can mount a DefecTor attack can often determine the website that a Tor user is visiting with perfect precision, particularly for less popular websites» [[2]](https://arxiv.org/abs/1609.08187). وفي قياساتهم، رصد محلِّل Google ما يقارب 40 في المئة من كل استعلامات DNS الخارجة من شبكة Tor عبر مُرحِّلات الخروج [[2]](https://arxiv.org/abs/1609.08187). تتناول دراستهم الاستعلامات التي تجريها مُرحِّلات الخروج؛ أما الاستعلام الصادر من شبكة المستخدم نفسها فيمنح المعلومة ذاتها لمراقب أقرب منه.

### وصول الاسم إلى tor مرهون بطريقة سؤال التطبيق

يقبل tor الأسماء بطريقتين. فالتطبيق الذي يتكلم بروتوكول SOCKS يستطيع أن يسلّم tor اسم المضيف ليحلّه مُرحِّل الخروج؛ أما الذي يحلّ الاسم أولًا ثم لا يسلّم tor إلا عنوانًا، فقد أجرى الاستعلام خارج Tor سلفًا. ويصف دليل tor الطريقة الثانية بأنها غير آمنة: فخيار SafeSocks «will reject application connections that use unsafe variants of the socks protocol — ones that only provide an IP address, meaning the application is doing a DNS resolve first»، وخيار TestSocks يسجّل نوع كل طلب، وهو ما «helps to determine whether an application using Tor is possibly leaking DNS requests» [[5]](https://2019.www.torproject.org/docs/tor-manual.html.en). ويستطيع tor كذلك أن يجيب بنفسه عن الاستعلامات عبر منفذ DNSPort، الذي «only handles A, AAAA, and PTR requests» [[5]](https://2019.www.torproject.org/docs/tor-manual.html.en). ويبقى تحذير مشروع Tor العام قائمًا: «Tor only protects applications that are properly configured to send their Internet traffic through Tor» [[6]](https://support.torproject.org/tor-browser/security/using-tb-safely/).

### في macOS تسأل التطبيقات محلِّلًا مشتركًا واحدًا

لا ترسل معظم تطبيقات Mac حزم DNS بنفسها. إذ ينص ملف README الخاص بـ mDNSResponder لدى Apple على أن «mDNSResponder is used on macOS as the system resolver» [[7]](https://github.com/apple-oss-distributions/mDNSResponder). فالاستعلام يغادر الجهاز إذن من عملية نظامية، لا من التطبيق الذي طلب الاسم، والأداة التي توجّه اتصالات تطبيقٍ بعينه لا ترى استعلاماته ما لم تتولَّ DNS هي الأخرى. وتوفّر Apple لهذا الغرض نقطة امتداد مستقلة هي NEDNSProxyProvider: «A DNS proxy allows your app to intercept all DNS traffic generated on a device»، وكل تدفّق يصله «corresponds to a socket opened by an app to UDP port 53 or TCP port 53» [[9]](https://developer.apple.com/documentation/networkextension/nednsproxyprovider).

### أسماء ‎.onion يجب ألّا تبلغ نظام DNS العادي أبدًا

تحجز RFC 7686 النطاق ‎.onion، وتنص على أن التطبيقات التي لا تدعم Tor «SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup»، وأن خوادم التخزين المؤقت «MUST generate NXDOMAIN for all such queries» [[4]](https://www.rfc-editor.org/rfc/rfc7686). ويشرح قسمها الأمني السبب: «A legacy client may inadvertently attempt to resolve a .onion name through the DNS. This causes a disclosure that the client is attempting to use Tor to reach a specific service» [[4]](https://www.rfc-editor.org/rfc/rfc7686). ويطبّق macOS جزءًا من ذلك بنفسه؛ ففي شيفرة configd التي تنشرها Apple، تبحث الدالة processOnionResolver عن محلِّل مضبوط نطاقه «onion» تمامًا، فإن لم تجده كان تعليق الشيفرة نفسه: «We do not have any such resolver. Add a system-wide “drop” policy for this domain» [[8]](https://github.com/apple-oss-distributions/configd/blob/main/Plugins/IPMonitor/controller.m). ففي جهاز Mac بإعداداته الأصلية يُسقَط استعلام ‎.onion قبل أن يبلغ الشبكة، وهذا يحمي الاسم، لكنه يعني أيضًا أن أي تطبيق لا يستطيع تحليله.

| الإعداد | من يجيب عن الاستعلام | من يعرف الاسم | المصدر |
| --- | --- | --- | --- |
| بلا نفق | محلِّل الشبكة | المحلِّل وكل من على المسار إليه | RFC 9076 |
| نفق، وDNS مضبوط خارجه | محلِّل الشبكة | الجهات نفسها، مع أن الحركة ذاتها داخل النفق | Perta وزملاؤه، PoPETs 2015 |
| تطبيق SOCKS يرسل اسم المضيف | محلِّل مُرحِّل الخروج | مُرحِّل الخروج ومحلِّله، لا الشبكة المحلية | دليل tor |
| تطبيق SOCKS يحلّ الاسم أولًا | محلِّل الشبكة | المحلِّل المحلي؛ ولا يرى tor إلا عنوانًا | دليل tor ‏(SafeSocks) |
| ‎.onion في برنامج لا يدعم Tor | لا أحد، إن التزم البرنامج RFC 7686 | عند التسرّب: المحلِّل، فيعرف الخدمة المقصودة | RFC 7686 |
| ‎.onion في Mac بإعداداته الأصلية | يُسقَط بسياسة على مستوى النظام | لا أحد، ولا يمكن تحليل الاسم | شيفرة configd لدى Apple |

*أين يذهب الاستعلام، ومن يعرف الاسم*

> يمرّر TorAi استعلامات DNS الخاصة بالتطبيقات التي توجّهها، وكل استعلام ‎.onion، عبر Tor، ويترك بقية جهاز Mac على حاله. [Download FireAI for Mac](https://hisnlabs.com/fireai/en/download)

## ما يعنيه ذلك لمستخدمي Mac

تترتب على ذلك ثلاث نتائج لكل من يوجّه بعض تطبيقاته عبر Tor على جهاز Mac. أولاها أن توجيه اتصالات التطبيق لا يكفي؛ فما لم تُعالَج استعلاماته أيضًا، يُخبر محلِّلُ النظام المشترك الشبكةَ المحلية بالأسماء التي يوشك ذلك التطبيق على بلوغها. والثانية أن الاستعلام المسرَّب أسوأ من الاتصال المسرَّب من وجه واحد: فهو يقع أولًا، وكثيرًا ما يكون غير مشفَّر، فيبلغ مراقبين لن يروا شيئًا من الحركة المشفَّرة التي تليه. والثالثة أن أسماء ‎.onion تحتاج إلى معاملة معاكسة لمعاملة الأسماء العادية: يجب أن تبلغ tor ولا شيء سواه، وهي في macOS لا تبلغ شيئًا على الإطلاق ما لم يُضبَط محلِّل لنطاق onion.

## توصيات

1. اعرض المحلِّلات التي يستخدمها macOS بالأمر `scutil --dns`، قبل تشغيل النفق وبعده، ولاحظ النطاقات التي يخدمها كلٌّ منها.
2. راقب حركة DNS على الواجهة النشطة أثناء استخدامك تطبيقًا موجَّهًا، بالأمر `sudo tcpdump -n -i en0 port 53` (استبدل en0 بواجهتك). ينبغي ألّا تظهر الأسماء التي يستعلم عنها ذلك التطبيق، وألّا يظهر اسم ‎.onion أبدًا.
3. في التطبيق الذي تضبطه عميلًا لـ SOCKS، تأكد من أنه يرسل أسماء المضيفين إلى tor بدل أن يحلّها أولًا؛ ويسجّل خيار TestSocks في tor نوع كل طلب.
4. تذكّر أن DNS المشفَّر نحو محلِّل عام يخفي استعلاماتك عن الشبكة المحلية، لا عن ذلك المحلِّل.
5. أعد التحقق بعد تغيير الشبكة أو تحديث macOS أو تحديث التطبيق، فإعدادات المحلِّل تتغير مع كلٍّ منها.
6. لا تكتب أسماء ‎.onion في برنامج غير موجَّه عبر Tor؛ وافتح خدمات onion في متصفح Tor أو في تطبيق تعلم أن استعلاماته تبلغ tor.

*التحقق من تسرّب DNS على macOS*

```console
$ scutil --dns
$ sudo tcpdump -n -i en0 port 53
```

## صلة ذلك بـ TorAi

TorAi تطبيق من HisnLabs لنظام macOS يوجّه التطبيقات التي يختارها المستخدم عبر Tor، لكلٍّ منها دائرته الخاصة، والإصدار 0.1.1 هو الإصدار الحالي. وقد عانت إصداراته التجريبية من الثغرة الموصوفة أعلاه تحديدًا: ففي وضع «التطبيقات المختارة» لم يكن محلِّل النظام تطبيقًا موجَّهًا، فكانت الاستعلامات التي تُجرى لحساب التطبيقات الموجَّهة، ومنها أسماء ‎.onion، تذهب إلى محلِّل الشبكة، وإن ظلت الاتصالات نفسها تمرّ عبر Tor. ومنذ الإصدار 0.1.0 يتضمن TorAi وكيل DNS مبنيًّا على NEDNSProxyProvider داخل امتداد النظام نفسه الذي يتولى التوجيه، ويقرّر مصير كل استعلام بحسب التطبيق الذي طرحه. فاستعلامات التطبيق الموجَّه تذهب إلى منفذ DNSPort في tor؛ وكل استعلام ‎.onion، من أي تطبيق، يذهب إلى tor؛ وكل تطبيق آخر يحتفظ بمحلِّله ولا ينتظر Tor أبدًا. ويطلب macOS الإذن مرة واحدة لتشغيل وكيل DNS.

وتتبع ذلك قاعدتان مستمدتان من تصميم tor وmacOS. فما دام tor غير جاهز، يُجاب استعلام التطبيق الموجَّه فورًا على الجهاز نفسه بإخفاق الخادم، ولا يُحال أبدًا إلى محلِّل الشبكة، اتساقًا مع قاعدة TorAi في حجب الحركة الموجَّهة بدل تمريرها خارج Tor؛ واختيار «إخفاق الخادم» بدل جواب «لا يوجد اسم كهذا» يمنع التطبيق من تخزين الاسم على أنه غير موجود. أما أنواع السجلات التي لا يستطيع DNSPort الإجابة عنها فتتلقى جوابًا فارغًا محليًّا. وبالنسبة لأسماء ‎.onion، ينشر امتداد النظام في TorAi، ما دام TorAi يعمل ومواقع ‎.onion مسموحة، محلِّلًا لنطاق onion وحده، على العنوان 127.0.0.1 والمنفذ 9183؛ فيرفع ذلك سياسة الإسقاط التي يفرضها macOS ما دام قائمًا، ويرفض كل اسم آخر، ويُحفَظ في إعدادات الشبكة الجارية للنظام لا في ملف، فيزول حين يتوقف الامتداد.

وما لا يفعله TorAi: لا يغيّر استعلامات التطبيقات غير الموجَّهة ولا يشفّرها ولا يسرّعها، فهي تذهب إلى محلِّل الشبكة كما كانت. ولا يخفي الاسم عن مُرحِّل الخروج في Tor الذي يتولى تحليله، كما هو الحال في أي استخدام لـ Tor. ولا يجعل التطبيق الذي يرفض أسماء ‎.onion يقبلها: فمنذ الإصدار 0.1.1 يتولى ضبط هذا الإعداد في متصفحات عائلة Firefox، مع إمكان التراجع من الإعدادات › الخصوصية، ولا يدّعي شيئًا بشأن المتصفحات المبنية على Chromium. التفاصيل في [صفحة TorAi](https://hisnlabs.com/torai/ar).

> ما دام Tor غير جاهز، يجيب TorAi عن استعلام التطبيق الموجَّه بخطأ على جهازك بدل أن يمرّره إلى محلِّل شبكتك. الإصدار 0.1.1، لنظام macOS 15 أو أحدث. [Download FireAI for Mac](https://hisnlabs.com/fireai/en/download)

> **Note:** لا يرتبط TorAi بمشروع Tor ‏(The Tor Project) ولا يحظى بتأييده. Tor علامة تجارية مملوكة لـ The Tor Project, Inc.

## حدود هذه المذكرة

تصف هذه المذكرة سلوك DNS انطلاقًا من المعايير ودراستين محكَّمتين والشيفرة التي تنشرها Apple، ولا تقيس أداء محلِّلات أو منتجات VPN بعينها. والرقم الوارد عند Greschbach وزملائه يخص استعلامات مُرحِّلات الخروج في Tor وقت إجراء الدراسة، وربما تغيّر منذئذ. وشيفرة configd وmDNSResponder مقروءة من مستودعات Apple العامة، وقد تختلف في التفاصيل عن النسخة المضمَّنة في إصدار بعينه من macOS. ولا يرى فحص tcpdump إلا DNS على المنفذ 53: فالتطبيقات التي تستخدم DNS مشفَّرًا خاصًّا بها لا تظهر فيه، ولا يقول الفحص شيئًا عن أنواع التسرّب الأخرى، مثل WebRTC أو حركة UDP. ويُوصَف سلوك TorAi هنا من ملاحظات الإصدار لدى HisnLabs واختباراتها الخاصة، لا من تدقيق مستقل، وHisnLabs هي من تصنع TorAi، وهو ما ينبغي للقارئ أن يأخذه في الحسبان. للاستزادة: درسا جامعة FireAI عن [وظيفة DNS](https://hisnlabs.com/ar/university/dns/what-dns-does) و[من يرى استعلامات DNS](https://hisnlabs.com/ar/university/dns/who-sees-your-dns-lookups)، والمقالان [ما يخفيه Tor وما لا يخفيه](https://hisnlabs.com/ar/blog/what-tor-hides-and-what-it-does-not) و[شرح خدمات onion](https://hisnlabs.com/ar/blog/onion-services-v3-addresses-rfc-7686).

## دور FireAI وHisnLabs

لا يمرّر FireAI أيّ حركة عبر Tor؛ بل يعرض بلغة واضحة كل اتصال تجريه تطبيقات جهاز Mac، ويترك لك أن تقرّر أيّها يمرّ.

FireAI هو منتج HisnLabs نفسها: جدار حماية بذكاء اصطناعي يعمل على جهاز Mac مباشرة. يعرض بلغة واضحة كل اتصال تجريه تطبيقاتك، ويترك لك القرار فيما يخرج من جهازك — ذكاؤه الاصطناعي يعمل محليًا، فلا يُرسَل ترافيكك إلينا ولا إلى أي جهة أخرى أبدًا. فريق أبحاث الأمن في HisnLabs هو من يحافظ على دقة هذه القرارات: يصنّف النطاقات بين قياس عن بُعد عادي وخدمة حقيقية، ويتتبّع بلد وشبكة كل اتصال، ويدرّب النموذج المحلي (ميزة FireAI Pilot) على حركة اتصال حقيقية، دون أن يغادر أي شيء جهاز Mac.

يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على [FireAI من HisnLabs](https://hisnlabs.com/fireai/ar/download).

## Sources

- [Wicinski (ed.), RFC 9076: DNS Privacy Considerations, IETF, July 2021](https://www.rfc-editor.org/rfc/rfc9076)
- [Greschbach, Pulls, Roberts, Winter and Feamster, “The Effect of DNS on Tor’s Anonymity”, arXiv:1609.08187, 26 September 2016](https://arxiv.org/abs/1609.08187)
- [Perta, Barbera, Tyson, Haddadi and Mei, “A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients”, PoPETs 2015](https://petsymposium.org/popets/2015/popets-2015-0006.php)
- [Appelbaum and Muffett, RFC 7686: The “.onion” Special-Use Domain Name, IETF, October 2015](https://www.rfc-editor.org/rfc/rfc7686)
- [The Tor Project: tor manual (DNSPort, AutomapHostsOnResolve, SafeSocks, TestSocks)](https://2019.www.torproject.org/docs/tor-manual.html.en)
- [The Tor Project: Tor Browser best practices](https://support.torproject.org/tor-browser/security/using-tb-safely/)
- [Apple open source: mDNSResponder, README](https://github.com/apple-oss-distributions/mDNSResponder)
- [Apple open source: configd, Plugins/IPMonitor/controller.m (processOnionResolver)](https://github.com/apple-oss-distributions/configd/blob/main/Plugins/IPMonitor/controller.m)
- [Apple Developer: NEDNSProxyProvider](https://developer.apple.com/documentation/networkextension/nednsproxyprovider)
- [HisnLabs: TorAi product page](https://hisnlabs.com/torai/en)