فجأة ، بدون إعلان أولي ، بدأ DNS عبر TLS في العمل على
8.8.8.8 . سابقًا ، أعلنت Google عن دعم
DNS فقط
عبر HTTPS.قام محلل CloudFlare العام بعنوان IP
1.1.1.1 بدعم DNS عبر TLS منذ بدء المشروع.
لماذا هو ضروري
باستخدام مخطط DNS الكلاسيكي ، يمكن لمقدمي الخدمة الزحف إلى الكفوف القذرة في حزم DNS الخاصة بك ، وتصفح المجالات التي تطلبها ، وتبادل الردود كما تريد. يقوم المخادعون بالشيء نفسه ، حيث يستبدلون المحللون على أجهزة التوجيه المخترقة من أجل توجيه المستخدم إلى خادم مزيف.
مع DNS عبر TLS / HTTPS ، يتم إرسال الطلبات داخل نفق مشفر حتى لا يتمكن الموفر من استبدال الطلب أو عرضه.
ومع ظهور تشفير اسم النطاق في شهادات X.509 (
ESNI ) ، سيصبح من المستحيل الحظر عبر DPI عبر SNI (إشارة اسم الخادم ، وهو حقل خاص يتم فيه نقل اسم المجال في حزمة TLS الأولى) ، والتي يتم استخدامها الآن من قبل بعض كبار الموفرين.
كيف يعمل
يتم إجراء اتصال TLS بـ TCP: 853 ، ويتم التحقق من شهادة المحلل باستخدام شهادات جذر النظام ، تمامًا مثل HTTPS في المستعرض. هذا يلغي الحاجة إلى إضافة أي مفاتيح يدويًا. داخل النفق ، يتم إجراء استعلام DNS منتظم. يؤدي هذا إلى إنشاء حمل أقل من DNS عبر HTTPS ، مما يضيف رؤوس HTTP إلى الطلب والاستجابة.
لسوء الحظ ، لا يتم حاليًا سوى دعم Android 9 (Pie) لنظام أسماء النطاقات عبر TLS في محلل النظام.
تعليمات الإعداد لنظام Android 9 .
بالنسبة للأنظمة الأخرى ، يُقترح استخدام برنامج خفي من جهة خارجية ، وإرسال محلل النظام إلى المضيف المحلي (127.0.0.1).
الإعداد على macOS
دعونا نحلل DNS عبر TLS على أحدث إصدار من macOS ، باستخدام محلل
العقدة كمثال
التثبيت
brew install knot-resolver
بشكل افتراضي ، ستعمل العقدة مثل محلل عودي عادي ، مثل dnsmasq.
تحرير التكوين
nano /usr/local/etc/kresd/config
وأضف إلى نهاية الملف:
policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
ونتيجة لذلك ، يبدو التكوين الخاص بي كما يلي:
قم بتوسيع المفسد -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
تعرف على المزيد حول اسم المضيف ومصادقة شهادة TLS.إن معلمة
hostname في هذه الحالة هي الاسم الشائع (CN) أو اسم Alt للموضوع (SAN) للشهادة. أي اسم المجال الذي تم إصدار الشهادة له. يتحقق من صحة شهادة الخادم.
فيما يلي قيم SAN للشهادة التي يتم استخدامها عند الاتصال بـ 8.8.8.8:853
dns.google 8888.google 8.8.4.4 8.8.8.8 2001:4860:4860:0:0:0:0:64 2001:4860:4860:0:0:0:0:6464 2001:4860:4860:0:0:0:0:8844 2001:4860:4860:0:0:0:0:8888
يمكن استخدام أي من هذه القيم كمعلمة اسم المضيف. إذا كنت ستقوم بنشر محلل العودية العام الخاص بك ، فمن غير المحتمل أن تتمكن من إصدار شهادة X.509 لعنوان IP ، لذلك سيكون عليك تحديد اسم المجال في معلمة اسم المضيف.
إطلاق البرنامج الخفي
sudo brew services start knot-resolver
يمكنك التحقق مما إذا كان البرنامج الخفي بدأ بنجاح باستخدام الأمر:
sudo lsof -i -P -n | grep kresd
يجب أن تستمع عملية kresd على المنفذ 53 على المضيف المحلي.
إذا حدث خطأ ما ، فانظر إلى سجل الأخطاء:
cat /usr/local/var/log/kresd.log
فحص عملية المحلل
dig @127.0.0.1 habr.com
تأكد من أن المحلل المحلي يستجيب بشكل صحيح.
التثبيت كمحلل للنظام
إذا كان كل شيء يعمل بشكل صحيح ، يمكنك تعيين محلل نظام في خصائص محول الشبكة:
UPDما الفرق بين DNSCrypt و DNSSEC و DNS عبر TLS / HTTPS.
يمكن أن يعمل
DNSCrypt على UDP و TCP. الاتصال بالمنفذ 443. للتشفير ، يتم استخدام البروتوكول الخاص به ، والذي يختلف عن HTTPS. يمكن تمييزه بسهولة باستخدام DPI. إنها بالأحرى مسودة ، تم اختبارها قبل إدخال DNS عبر TLS / HTTPS ، نظرًا لأنها لا تحتوي على RFC ، أي أنها ليست معيار إنترنت رسمي. على الأرجح ، قريبًا ، سيتم استبداله بالكامل بالأخير.
DNS عبر TLS (DoT) - يحدث اتصال TCP على المنفذ 853 ، يتم إرسال طلب DNS عادي داخل النفق. يرى الموفر أن هذا استعلام DNS ولكن لا يمكنه التدخل فيه. الأشياء الأخرى متساوية ، في DNS عبر TLS يجب أن يكون هناك حمل أقل قليلاً لكل طلب مما هو عليه في HTTPS.
DNS عبر HTTP (DoH) - اتصال TCP بالمنفذ 443 ، على غرار HTTPS العادي. يوجد في الداخل تنسيق طلب مختلف ، مع رؤوس HTTP. ومع ذلك ، بالنسبة إلى الموفر ، سيُنظر إلى هذا الطلب على أنه اتصال HTTPS عادي. أفترض أن هذا البروتوكول قد تم اختراعه في حالة حظر استعلامات DNS للخوادم الأجنبية من أجل إخفاء حركة مرور الويب العادية. وأيضًا ، حتى تتمكن المتصفحات من حل النطاقات نفسها وعدم إنشاء حركة مرور غير طبيعية.
في الواقع ، DNS عبر HTTPS وعبر TLS هو نفس الشيء ، مع تنسيق طلب مختلف قليلاً. يتم قبول كل من هذه البروتوكولات كمعايير ولها RFC. على الأرجح ، في المستقبل القريب سنرى التوزيع الجماعي لكليهما.
DNSSEC هو بروتوكول لتوقيع سجلات DNS رقميًا. لا يتعلق بالتشفير ، حيث يتم إرسال جميع الطلبات في نص واضح. يمكن أن يعمل على حد سواء عبر بروتوكول DNS الكلاسيكي القديم ، أي UDP / TCP على المنفذ 53 ، وداخل DNS عبر TLS / HTTPS. الغرض من DNSSEC هو مصادقة سجل DNS. يمكن لمالك النطاق إضافة مفتاح عام إلى الخوادم الجذر لمنطقة المجال الخاصة به وتوقيع كافة الإدخالات على خادم NS الرئيسي. في الواقع ، لكل سجل DNS ، على سبيل المثال ، سجل A أو سجل MX ، يتم إضافة سجل آخر من نوع RRSIG يحتوي على التوقيع. يسمح لك إجراء التحقق من DNSSEC على محلل عودي بتحديد ما إذا كان هذا السجل قد تم إنشاؤه بالفعل بواسطة مالك المجال.
مقارنة أكثر تفصيلاً لجميع البروتوكولات
dnscrypt.info/faq (فقرة بروتوكولات أخرى)