مهاجرت به anycast و RFC 8484 DoH

به‌عنوان بخشی از راه‌اندازی DoH در دامنه dns.google و آدرس‌های IP معروف anycast برای Google Public DNS، سرویس Beta DoH در دامنه dns.google.com با استفاده از آدرس‌های IP دیگر منسوخ شده و رد خواهد شد. .

نسخه آزمایشی RFC 8484 API نیز منسوخ شده است. dns.google /experimental پشتیبانی نمی‌شود و dns.google.com /experimental به dns.google/dns-query منتقل می‌شود.

جدول زمانی

تاریخ مرحله چرخش
2019-07-23 01-08-2019 dns.google.com/experimental Experimental به dns.google/dns-query – DONE
05/08/2019 2019-08-21 dns.google.com به آدرس‌های IP anycast DNS عمومی Google - انجام DONE
2019-09-24 آدرس‌های IP قدیمی برای dns.google.com به dns.google هدایت می‌شوند – DONE
23-06-2020 dns.google.com همه جا به dns.google هدایت می شود

تغییرات در این جدول زمانی در اینجا به‌روزرسانی شده و در public-dns-announce پست می‌شود. برای به روز رسانی در آن لیست پستی کم حجم مشترک شوید.

پنجشنبه 1 آگوست 2019

درخواست‌ها برای https://dns.google.com/experimental ، HTTP 301 را به https://dns.google/dns-query هدایت می‌کنند.

برنامه های DoH با استفاده از JSON API در /resolve تحت تأثیر قرار نمی گیرند.

چهارشنبه 21 آگوست 2019

dns.google.com به آدرس های IP anycast DNS عمومی Google حل می شود.

این برای اکثر برنامه های DoH شفاف است، بدون نیاز به تغییر.

سه شنبه 24 سپتامبر 2019

درخواست‌های DoH به آدرس‌های IP قبلی dns.google.com، HTTP 301 را به https://dns.google/ هدایت می‌کنند.

این ممکن است بر برنامه‌های DoH با استفاده از RFC 8484 یا JSON API تأثیر بگذارد.

برنامه‌هایی که درخواست‌های DoH را به آدرس‌های IP سخت‌کد، قابل تنظیم یا کش دائمی می‌فرستند باید یکی یا هر دو مورد زیر را پشتیبانی کنند:

سه شنبه 23 ژوئن 2020

درخواست‌های DoH به dns.google.com در آدرس‌های IP anycast، HTTP 301 را به dns.google هدایت می‌کنند.

این ممکن است بر برنامه‌های DoH با استفاده از RFC 8484 یا JSON API تأثیر بگذارد.

برای کار با Google DoH، برنامه ها باید حداقل یکی از موارد زیر را پشتیبانی کنند:

تغییرات برای مشتریان DoH

ریدایرکت های HTTP را دنبال کنید

سرورهای DoH فقط سرورهای HTTP هستند که پرس و جوهای DNS را مدیریت می کنند. به این ترتیب، آنها ممکن است ریدایرکت های HTTP (کدهای 301، 302، 307 یا 308) را برگردانند و کلاینت های DoH باید مانند هر مشتری HTTP دیگری از این تغییر مسیرها پیروی کنند.

توسعه دهندگان می توانند پشتیبانی از تغییر مسیر HTTP را با https://8.8.8.8/experimental یا https://8.8.8.8/resolve به عنوان پایه URL های DoH خود بررسی کنند. اینها HTTP 301 را به https://dns.google/dns-query و https://dns.google/resolve هدایت می‌کنند (با حفظ هر پارامتر GET).

از دامنه dns.google برای Google DoH استفاده کنید

برنامه های DoH باید به جای dns.google.com از dns.google استفاده کنند. خواه از RFC 8484 یا JSON API استفاده می‌کند، هر برنامه DoH با فهرست سخت‌کد یا پیکربندی‌شده از حل‌کننده‌های DoH باید dns.google.com را با dns.google در هر URL یا الگوی URI جایگزین کند.

از آدرس های IP anycast Google Public DNS استفاده کنید

برنامه‌های DoH که درخواست‌های DoH را به فهرستی از آدرس‌های IP با کد سخت یا پیکربندی شده ارسال می‌کنند (حتی فقط برای راه‌اندازی) باید آدرس‌های قبلی dns.google.com را با آدرس‌های IP anycast DNS عمومی Google جایگزین کنند.

الگوهای URI برای پیکربندی

برنامه های DoH باید قابلیت پیکربندی برای نقاط پایانی را فراهم کنند. راه مرجح و استاندارد برای انجام این کار با الگوهای URI است. توسعه دهندگان برنامه DoH با قابلیت پیکربندی کامل باید کاربران را از URL جدید مطلع کنند (الگوی URI: https://dns.google/dns-query{?dns} ).

از https://dns.google/dns-query برای RFC 8484 DoH استفاده کنید

برنامه‌های DoH با فهرست سخت‌کد یا پیکربندی‌شده از حل‌کننده‌های DoH باید https://dns.google.com/experimental URL را برای API پیش‌نویس اینترنت DoH با https://dns.google/dns-query جایگزین کرده و تأیید کنند. مطابقت کامل با RFC 8484.

API /experimental (فقط در dns.google.com موجود است) پرس و جوهایی را با استفاده از کدگذاری Base64 غیر ایمن و نوع محتوای application/dns-udpwireformat که توسط /dns-query API رد می‌شوند (فقط در dns.google موجود است) پذیرفته است. این تفاوت ها در دو بخش زیر توضیح داده شده است.

از رمزگذاری Base64Url برای پارامتر GET dns استفاده کنید

از رمزگذاری Websafe Base64Url برای پارامتر dns در درخواست های GET استفاده کنید، Base64 ( + / ) را با ( - _ ) جایگزین کنید و کاراکترهای padding ( = ) را حذف کنید.

پذیرش و ارسال application/dns-message

از application/dns-message در هدر Accept (و برای RFC 8484 POST، در هدر Content-Type) استفاده کنید و آن را به عنوان Content-Type پاسخ ها بپذیرید.

استفاده از Content-Type قدیمی برای POST با نوع رسانه پشتیبانی نشده 415 ناموفق خواهد بود.

برنامه‌هایی که از Content-Type قدیمی در هدر Accept استفاده می‌کنند، با Content-Type application/dns-message پاسخ دریافت می‌کنند. برنامه‌های DoH که این موارد را می‌پذیرند و به دلیل نوع محتوای غیرمنتظره آنها را نادیده نمی‌گیرند، همچنان کار خواهند کرد.