معالجة نظام أسماء النطاقات عبر بروتوكول HTTPS (DoH)

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

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

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

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

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

طرق HTTP

GET
يمكن أن يؤدي استخدام طريقة GET إلى تقليل وقت الاستجابة، حيث يتم تخزينها مؤقتًا بشكل أكثر فاعلية. يجب أن تحتوي طلبات RFC 8484 GET على معلمة طلب البحث ?dns= مع رسالة نظام أسماء النطاقات بترميز Base64Url. وطريقة GET هي الطريقة الوحيدة المتوافقة مع JSON API.
POST
لا يمكن استخدام طريقة POST إلا مع RFC 8484 API واستخدام رسالة نظام أسماء النطاقات الثنائية مع Content-Type/dns-message في نص الطلب وفي استجابة DoH HTTP.
HEAD
HEAD غير متاح حاليًا، ويعرض الخطأ 400 "طلب غير صالح".

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

رموز حالة HTTP

تعرض خدمة Google Public DNS DoH رموز حالة HTTP التالية:

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

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

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

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

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

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

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

الأخطاء

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

400 طلب غير صالح
حدثت مشاكل أثناء تحليل معلَمات GET، أو رسالة طلب غير صالحة لنظام أسماء النطاقات. بالنسبة إلى معلمات GET غير صحيحة، يجب أن يشرح نص HTTP الخطأ. تحصل معظم رسائل نظام أسماء النطاقات غير الصالحة على نسبة 200 مقبولة مع 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 مدخل غير صالح
تعذّر على خدمة وزارة الصحة التواصل مع برامج تعيين نظام أسماء النطاقات العام من Google.

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

مزايا DoH

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

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

أفضل ممارسات الخصوصية لدى وزارة الصحة

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

  • الحدّ من استخدام عناوين HTTP

    تكشف عناوين HTTP عن معلومات حول تنفيذ DoH لدى العميل ويمكن استخدامها لإخفاء هوية العملاء. إن العناوين، مثل Cookie وUser-Agent وAccept-Language، هي أكثر الأخطاء تعقيدًا، ولكن حتى مجموعة العناوين المرسَلة قد تكون ظاهرة. للحد من هذا الخطر، أرسل فقط عناوين HTTP المطلوبة لـ DoH: المضيف، ونوع المحتوى (لـ POST)، والقبول إذا لزم الأمر. يجب تضمين وكيل المستخدم في أي إصدارات للتطوير أو الاختبار.

  • استخدام خيارات المساحة المتروكة في EDNS

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

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

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

المشاكل

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