DNS-over-HTTPS (DoH)

Google Public DNS دو API DoH مجزا را در این نقاط پایانی ارائه می دهد:

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

صفحه بررسی اجمالی حمل و نقل ایمن دارای نمونه‌های خط فرمان curl برای استفاده از هر دو API و همچنین جزئیات TLS و سایر ویژگی‌های مشترک برای DNS از طریق TLS (DoT) و DoH است.

DoH همچنین برای سرویس Google Public DNS64 فقط IPv6 پشتیبانی می‌شود.

Google Public DNS از آدرس های http: ناامن برای تماس های API پشتیبانی نمی کند.

روش های HTTP

گرفتن

استفاده از روش GET می تواند تاخیر را کاهش دهد، زیرا به طور موثرتری در حافظه پنهان ذخیره می شود. درخواست های RFC 8484 GET باید دارای یک پارامتر پرس و جو ?dns= با پیام DNS کدگذاری شده Base64Url باشند. متد GET تنها روشی است که برای JSON API پشتیبانی می شود.

پست

روش POST فقط برای RFC 8484 API پشتیبانی می‌شود و از یک پیام DNS باینری با Content-Type application/dns-message در بدنه درخواست و در پاسخ HTTP DoH استفاده می‌کند.

سر

HEAD در حال حاضر پشتیبانی نمی‌شود و یک خطای 400 Bad Request را برمی‌گرداند .

روش‌های دیگر خطاهای 501 Not Implemented را برمی‌گردانند.

کدهای وضعیت HTTP

Google Public DNS DoH کدهای وضعیت HTTP زیر را برمی گرداند:

موفقیت

200 باشه

تجزیه HTTP و ارتباط با حل‌کننده DNS موفقیت‌آمیز بود، و محتوای بدنه پاسخ، بسته به نقطه پایانی پرس و جو، هدر پذیرش و پارامترهای GET، یک پاسخ DNS در کدگذاری باینری یا JSON است.

تغییر مسیرها

301 به طور دائم منتقل شد

مشتریان باید در URL ارائه شده در هدر Location: دوباره امتحان کنند. اگر پرس و جو اصلی یک درخواست POST بود، کلاینت ها فقط باید با GET دوباره امتحان کنند که URL جدید یک آرگومان پارامتر dns GET را مشخص کند. در غیر این صورت مشتریان باید با POST دوباره امتحان کنند.

ممکن است در آینده از کدهای دیگری مانند 302 Found، 307 Temporary Redirect یا 308 Permanent Redirect استفاده شود و مشتریان DoH باید هر چهار کد را کنترل کنند.

پاسخ‌هایی با کدهای 301 و 308 دائمی باید به‌طور نامحدود ذخیره شوند و در صورت عملی، ممکن است از کاربران خواسته شود که پیکربندی اصلی خود را با استفاده از URL جدید به‌روزرسانی کنند.

درخواست های POST که 307 یا 308 پاسخ می گیرند همیشه باید با POST دوباره امتحان شوند.

خطاها

پاسخ های خطا با استفاده از HTML یا متن ساده توضیحی درباره وضعیت HTTP در بدنه خواهند داشت.

400 درخواست بد

مشکل در تجزیه پارامترهای GET یا پیام درخواست DNS نامعتبر. برای پارامترهای بد GET، بدنه HTTP باید خطا را توضیح دهد. اکثر پیام های DNS نامعتبر با FORMERR 200 OK دریافت می کنند. خطای HTTP برای پیام‌های مخدوش بدون بخش سؤال، یک پرچم QR که نشان‌دهنده پاسخ است، یا سایر ترکیب‌های پرچم غیرمعنا با خطاهای تجزیه DNS باینری بازگردانده می‌شود.

413 محموله خیلی بزرگ

یک بدنه درخواست RFC 8484 POST از حداکثر اندازه پیام 512 بایت فراتر رفته است.

414 URI خیلی طولانی است

سرصفحه پرس و جو GET خیلی بزرگ بود یا پارامتر dns یک پیام DNS رمزگذاری شده Base64Url داشت که از حداکثر اندازه پیام 512 بایت بیشتر بود.

415 نوع رسانه پشتیبانی نشده

بدنه POST هدر application/dns-message Content-Type نداشت.

429 درخواست خیلی زیاد

مشتری در مدت زمان معین درخواست های زیادی ارسال کرده است. مشتریان باید ارسال درخواست ها را تا زمان مشخص شده در سربرگ Retry-After متوقف کنند (زمان نسبی بر حسب ثانیه).

500 خطای سرور داخلی

خطاهای DoH داخلی DNS عمومی Google.

501 اجرا نشد

فقط متدهای GET و POST پیاده سازی می شوند، روش های دیگر این خطا را دریافت می کنند.

دروازه بد 502

سرویس DoH نمی تواند با حل کننده های DNS عمومی Google تماس بگیرد.

در مورد یک پاسخ 502، اگرچه تلاش مجدد بر روی یک آدرس DNS عمومی Google جایگزین ممکن است کمک کند، یک پاسخ بازگشتی موثرتر این است که سرویس DoH دیگری را امتحان کنید یا به UDP سنتی یا TCP DNS در 8.8.8.8 تغییر دهید.

مزایای DoH

استفاده از HTTPS، نه فقط رمزگذاری TLS، مزایای عملی دارد:

• API های HTTPS به طور گسترده در دسترس و با پشتیبانی خوب، پیاده سازی را هم برای خود DNS عمومی Google و هم برای مشتریان بالقوه ساده می کند.
• یک سرویس HTTPS به برنامه‌های وب دسترسی به انواع رکوردهای DNS را فراهم می‌کند، و از محدودیت‌های موجود در مرورگر و APIهای DNS سیستم‌عامل، که عموماً فقط جستجوهای میزبان به آدرس را پشتیبانی می‌کنند، اجتناب می‌کند.
• کلاینت هایی که پشتیبانی از HTTPS مبتنی بر UDP QUIC را اجرا می کنند، می توانند از مشکلاتی مانند مسدود کردن سر خط که هنگام استفاده از انتقال TCP رخ می دهد، جلوگیری کنند.

بهترین شیوه های حفظ حریم خصوصی برای DoH

توسعه دهندگان برنامه های کاربردی DoH باید بهترین شیوه های حفظ حریم خصوصی را که در RFC 8484 بیان شده و در زیر گسترش یافته است، در نظر بگیرند:

• استفاده از هدرهای HTTP را محدود کنید

  هدرهای HTTP اطلاعاتی را در مورد اجرای DoH کلاینت نشان می‌دهند و می‌توان از آنها برای بی‌نام کردن کلاینت‌ها استفاده کرد. سرصفحه هایی مانند Cookie، User-Agent و Accept-Language بدترین متخلفان هستند، اما حتی مجموعه هدرهای ارسال شده نیز می تواند فاش کننده باشد. برای به حداقل رساندن این خطر، فقط هدرهای HTTP مورد نیاز برای DoH را ارسال کنید: Host، Content-Type (برای POST)، و در صورت لزوم، Accept. User-Agent باید در هر نسخه توسعه یا آزمایشی گنجانده شود.

• از گزینه های EDNS padding استفاده کنید

  دستورالعمل RFC 8467 را برای استفاده از گزینه‌های padding EDNS برای تکمیل درخواست‌های DoH به چند طول معمول برای محافظت در برابر تجزیه و تحلیل ترافیک دنبال کنید. استفاده از padding HTTP/2 نیز امکان پذیر است، اما بر خلاف EDNS padding، باعث ایجاد padding در پاسخ ها از سرورهای DoH نمی شود.

• از RFC 8484 POST فقط برای برنامه های حساس به حریم خصوصی یا حالت های مرورگر استفاده کنید

  استفاده از POST برای پرس و جوهای DoH قابلیت ذخیره سازی پاسخ ها را کاهش می دهد و می تواند تأخیر DNS را افزایش دهد، بنابراین به طور کلی توصیه نمی شود. با این حال، کاهش حافظه پنهان احتمالاً برای برنامه‌های حساس به حریم خصوصی مطلوب است و ممکن است در برابر حملات زمان‌بندی برنامه‌های وب که تلاش می‌کنند تعیین کنند کاربر اخیراً از چه دامنه‌هایی بازدید کرده است محافظت کند.

مسائل

برای گزارش یک اشکال یا درخواست یک ویژگی جدید، لطفاً یک مشکل را برای DoH باز کنید.