DNS-over-HTTPS (DoH)

يوفّر نظام أسماء النطاقات العام من Google واجهات برمجة تطبيقات DoH مختلفة في نقاط النهاية هذه:

  • https://dns.google/dns-query – RFC 8484 (GET وPOST)
  • https://dns.google/Solve? – JSON API (GET)

تتضمّن الصفحة نظرة عامة حول النقل الآمن curl مثالاً عن سطر الأوامر لاستخدام كل من واجهات برمجة التطبيقات (API) بالإضافة إلى تفاصيل بروتوكول أمان طبقة النقل (TLS) والميزات الأخرى الشائعة لكلٍّ من نظام أسماء النطاقات عبر طبقة النقل الآمنة (DoT) وDoH.

تتوفّر DoH أيضًا لخدمة Google DNS DNS64 التابعة لبروتوكول IPv6 فقط.

لا يتيح نظام أسماء النطاقات العام من Google عناوين URL غير الآمنة لاستدعاءات واجهة برمجة التطبيقات http:.

طرق HTTP

الاطّلاع على
يمكن أن يؤدي استخدام طريقة GET إلى تقليل وقت الاستجابة، لأنه يتم تخزينه في ذاكرة التخزين المؤقت بفعالية أكبر. يجب أن تحتوي طلبات GET 8484 GET على معلّمة طلب بحث ?dns= مع رسالة نظام أسماء نطاقات مشفّر Base64Url. لا يمكن استخدام طريقة GET إلا لواجهة برمجة تطبيقات JSON.
مشاركة
لا تتوافق طريقة POST إلا مع واجهة برمجة التطبيقات RFC 8484 وتستخدم رسالة نظام أسماء النطاقات (DNS) الثنائية التي تتضمن تطبيقًا من نوع المحتوى/نظام أسماء النطاقات (DNS) في نص الطلب وفي استجابة HTTP DoH.
HEAD
HEAD غير متوافق حاليًا ويؤدي إلى عرض الخطأ 400 Bad Order.

تعرض طرق أخرى أخطاء 501 لم يتم التنفيذ.

رموز حالة HTTP

تعرض Google DoH في نظام أسماء النطاقات العام من Google رموز حالة HTTP التالية:

تم الإجراء بنجاح

200 حسنًا
نجح تحليل HTTP والتواصل مع برنامج تعيين نظام أسماء النطاقات، وكان محتوى نص الاستجابة هو استجابة نظام أسماء النطاقات إما في الترميز الثنائي أو ترميز JSON، بناءً على نقطة نهاية طلب البحث وقبول الرأس ومعلمات GET.

عمليات إعادة التوجيه

301 تم النقل نهائيًا
يجب على العملاء إعادة المحاولة على عنوان URL المقدّم في العنوان Location:. إذا كان طلب البحث الأصلي عبارة عن طلب POST، يجب على العملاء إعادة المحاولة باستخدام GET فقط إذا كان عنوان URL الجديد يحدد وسيطة معلمة GET dns. وبخلاف ذلك، على العملاء إعادة محاولة استخدام POST.

وقد يتم استخدام رموز أخرى مثل 302 عثرة أو إعادة توجيه مؤقتة 307 أو 308 إعادة توجيه دائمة في المستقبل، وعلى عملاء DoH معالجة كل الرموز الأربعة.

يجب تخزين الردود التي تتضمن رموز 301 و308 الدائمة مؤقتًا إلى أجل غير مسمى، وإذا كان ذلك ممكنًا، قد يُطلب من المستخدمين تحديث الضبط الأصلي باستخدام عنوان URL الجديد.

يجب دائمًا إعادة محاولة طلبات POST التي تتلقى ردود 307 أو 308 باستخدام POST.

الأخطاء

وستوضّح استجابات الخطأ حالة HTTP في النص، وذلك باستخدام HTML أو نص عادي.

400 طلب سيئ
مشاكل في تحليل مَعلمات GET أو رسالة طلب نظام أسماء نطاقات غير صالحة بالنسبة إلى معلمات GET غير صحيحة، يجب أن يشرح نص HTTP الخطأ. وفي معظم الحالات، تتلقّى معظم رسائل نظام أسماء النطاقات غير الصالحة خطأ 200 OK مع FORMERR، ويظهر خطأ HTTP للرسائل المشوهة التي لا تتضمّن قسم"الأسئلة"، أو علامة الاستجابة السريعة التي تشير إلى ردّ، أو غيرها من تركيبات العلامات التي لا معنى لها والتي تحتوي على أخطاء تحليل نظام أسماء النطاقات الثنائي.
413 حمولة كبيرة جدًا
تجاوز نص طلب RFC 8484 POST الحد الأقصى لحجم الرسالة والبالغ 512 بايت.
414 معرّف الموارد المنتظم (URI) طويل جدًا
كان عنوان طلب البحث GET كبيرًا جدًا أو تتضمن المعلمة dns رسالة Base64Url مشفّرة من نظام أسماء النطاقات تتجاوز الحد الأقصى لحجم الرسالة البالغ 512 بايت.
415 نوع وسائط غير متوافق
لم يحتوي نص POST على عنوان application/dns-message لنوع المحتوى.
429 عدد كبير جدًا من الطلبات
أرسَل العميل عددًا كبيرًا جدًا من الطلبات خلال فترة زمنية معيَّنة. يجب أن يتوقف العملاء عن إرسال الطلبات حتى الوقت المحدّد في عنوان إعادة المحاولة (بعد وقت نسبي بالثواني).
500 خطأ في الخادم الداخلي
أخطاء DoH داخلية في نظام أسماء النطاقات العام من Google.
501 لم يتم التنفيذ
يتم تنفيذ طرق GET وPOST فقط، ولكن يظهر هذا الخطأ بطرق أخرى.
502 Bad بوابة
تعذّر على خدمة DoH التواصل مع برامج تعيين نظام أسماء النطاقات العامة من Google.

في حالة الاستجابة 502، على الرغم من أن إعادة المحاولة على عنوان نظام أسماء نطاقات عام من Google عام قد تكون مفيدة، فإن الاستجابة البديلة الأكثر فعالية هي تجربة خدمة DoH أخرى، أو التبديل إلى نظام أسماء النطاقات (DNS) التقليدي لبروتوكول UDP أو TCP على الإصدار 8.8.8.8.

مزايا DoH

يوفّر استخدام HTTPS، وليس فقط تشفير طبقة النقل الآمنة، بعض المزايا العملية:

  • تسهّل واجهات برمجة التطبيقات HTTPS المتوفّرة على نطاق واسع وعملية التنفيذ تنفيذ كل من نظام أسماء النطاقات العام من Google والعملاء المحتملين.
  • توفر خدمة HTTPS لتطبيقات الويب إمكانية الدخول إلى جميع أنواع سجلات نظام أسماء النطاقات، مع تجنب القيود لواجهات برمجة التطبيقات الحالية لنظام أسماء النطاقات في المتصفّح ونظام التشغيل، والتي توفّر بشكل عام عمليات البحث عن مضيف إلى عنوان.
  • ويستطيع العملاء الذين ينفِّذون بروتوكول HTTPS المستند إلى بروتوكول QUIC، تجنُّب حدوث مشاكل، مثل حظر عناوين الرأس التي قد تحدث عند استخدام بروتوكول TCP.

أفضل ممارسات الخصوصية لـ DoH

وعلى مطوّري تطبيقات DoH مراعاة أفضل الممارسات المتعلّقة بالخصوصية والموضَّحة في RFC 8484 وتوسيعها أدناه:

  • تقييد استخدام عناوين HTTP

    تكشف عناوين HTTP معلومات عن تنفيذ DoH للعميل، ويمكن استخدامها في إزالة هوية العملاء. تُعد العناوين مثل ملف تعريف الارتباط ووكيل المستخدم و لغة القبول أسوأ الانتهاكات، ولكن يمكن أيضًا الكشف عن مجموعة العناوين المُرسَلة. للحد من هذا الخطر، أرسِل عناوين HTTP المطلوبة فقط لل DoH: المضيف وContent-Type (لـ POST) واستخدِم "قبول" إذا لزم الأمر. يجب تضمين وكيل المستخدم في أي من إصدارات التطوير أو الاختبار.

  • استخدام خيارات تعبئة نظام أسماء النطاقات (DNS)

    اتّبِع الإرشادات الواردة في RFC 8467 لاستخدام خيارات المساحة المتروكة في نظام أسماء النطاقات (DNS) لإضافة طلبات بحث DoH إلى بضعة أطوال شائعة للحماية من تحليل الزيارات. من الممكن أيضًا استخدام المساحة المتروكة في HTTP/2، ولكن على عكس المساحة المتروكة الخاصة بـ EDNS، لن يستدعي المساحة المتروكة على الردود الواردة من خوادم DoH.

  • استخدام RFC 8484 POST فقط للتطبيقات أو أوضاع الخصوصية الحساسة

    يؤدي استخدام طريقة POST لطلبات بحث DoH إلى تقليل قابلية التخزين المؤقت للاستجابات ويمكن أن يزيد من وقت استجابة نظام أسماء النطاقات، لذا لا ننصح بشكل عام. ومع ذلك، فإن تقليل التخزين المؤقت أمر مطلوب على الأرجح بالنسبة إلى التطبيقات الحساسة بالخصوصية، وقد يساعد في حماية هجمات التوقيت من تطبيقات الويب التي تحاول تحديد النطاقات التي زارها المستخدم مؤخرًا.

المشاكل

للإبلاغ عن خطأ أو طلب ميزة جديدة، يُرجى فتح مشكلة في DoH.