DNS over HTTPS برای وردپرس چطور حریم خصوصی را حفظ می‌کند؟

DNS over HTTPS (DoH) یک پروتکل مدرن است که پرس‌وجوهای DNS (Domain Name System) را درون کانال رمزنگاری‌شده HTTPS منتقل می‌کند تا هیچ واسطه‌ای نتواند محتوای آن‌ها را ببیند، دستکاری کند یا ردیابی نماید. برای سایت‌های وردپرسی، پیاده‌سازی DoH در دو سطح معنا پیدا می‌کند: سطح سرور که در آن وردپرس باید با رزولورهای DoH کار کند، و سطح کاربر که در آن بازدیدکنندگان باید بدون افشای هویت خود به ISP (Internet Service Provider) سایت شما را ببینند. برخلاف تصور رایج، DoH صرفاً یک تنظیم مرورگر نیست؛ یک تصمیم معماری است که بر حریم خصوصی کاربر، یکپارچگی داده و مقاومت در برابر سانسور اثر می‌گذارد. این متن مسیر عملی پیاده‌سازی DoH در بافت وردپرس را از انتخاب رزولور تا پایش نهایی، با تمرکز بر تصمیم‌های فنی و دام‌های پنهان بررسی می‌کند.

زمانی که برای اولین بار روی یک پروژه وردپرسی در منطقه‌ای با فیلترینگ شدید کار می‌کردم، متوجه شدم بخش قابل‌توجهی از بازدیدکنندگان حتی به صفحه ورود سایت نمی‌رسند. مشکل از سرور نبود؛ از لایه DNS بود که پرس‌وجوهای آن‌ها در مسیر دستکاری می‌شد. آن تجربه نقطه شروع مطالعه جدی روی DoH شد.

DNS over HTTPS دقیقاً چیست؟

DNS over HTTPS که به اختصار DoH نامیده می‌شود، یک پروتکل استاندارد است که در RFC 8484 توسط IETF (Internet Engineering Task Force) تعریف شده است. ایده پایه‌ای آن ساده است: پرس‌وجوهای DNS که در حالت سنتی به‌صورت متن آشکار روی پورت ۵۳ UDP ارسال می‌شوند، در قالب درخواست‌های HTTPS روی پورت ۴۴۳ کپسوله می‌شوند. نتیجه این تغییر، سه مزیت ساختاری است: محرمانگی محتوا، یکپارچگی داده و مقاومت در برابر دستکاری مسیر.

DNS پایه‌ای‌ترین سرویس اینترنت است. هر بار که یک نام دامنه در مرورگر وارد می‌کنید، یک پرس‌وجو به سرور DNS می‌رود تا آدرس IP مقصد را پیدا کند. در نسخه سنتی این پروتکل، این پرس‌وجو کاملاً شفاف است. هر واسطه‌ای در مسیر — از ISP تا روتر وای‌فای عمومی — می‌تواند آن را ببیند، ضبط کند، تغییر دهد یا پاسخ جعلی برگرداند. این وضعیت، هم برای حریم خصوصی و هم برای امنیت، یک نقص ساختاری جدی است.

DoH این نقص را از دو زاویه می‌بندد. زاویه نخست، محرمانگی است: محتوای پرس‌وجو درون TLS (Transport Layer Security) کپسوله می‌شود و هیچ واسطه‌ای نمی‌تواند ببیند شما کدام دامنه را جست‌وجو کرده‌اید. زاویه دوم، یکپارچگی است: پاسخ سرور DoH امضا شده است و هر دستکاری در مسیر، توسط کلاینت تشخیص داده می‌شود. مفاهیم پایه‌ای DNS در مطلب DNS چیست و چگونه کار می‌کند؟ به‌طور کامل توضیح داده شده است و برای ورود به بحث DoH، مطالعه آن پیش‌نیاز محسوب می‌شود.

از دیدگاه معماری، DoH یک تغییر ساده در پروتکل نیست؛ یک جابه‌جایی در نقطه اعتماد (Trust Point) است. در DNS سنتی، اعتماد به ISP واگذار می‌شود که معمولاً یک نهاد قابل کنترل و قابل ردیابی است. در DoH، اعتماد به رزولور DoH منتقل می‌شود که می‌تواند خودتان میزبانی کنید یا از یک ارائه‌دهنده مستقل استفاده کنید. این جابه‌جایی، پیامدهای حقوقی، امنیتی و عملکردی مهمی دارد که در ادامه بررسی می‌شوند.

DoH اعتماد را از ISP حذف نمی‌کند؛ آن را به یک نقطه قابل انتخاب منتقل می‌کند — و انتخاب درست، همان مسئله اصلی است.

چرا DNS سنتی حریم خصوصی را نقض می‌کند؟

DNS سنتی سه نقص ساختاری دارد که هر کدام به‌تنهایی کافی است تا حریم خصوصی کاربر را از بین ببرد. این نقص‌ها نه باگ پیاده‌سازی، بلکه ویژگی‌های ذاتی پروتکل هستند.

نقص اول: شفافیت کامل پرس‌وجوها

در DNS سنتی، هر پرس‌وجو به‌صورت متن آشکار روی پورت ۵۳ ارسال می‌شود. این یعنی هر واسطه در مسیر — از روتر خانگی تا ISP و تا مراکز تبادل ترافیک — می‌تواند فهرست کامل دامنه‌هایی که یک کاربر بازدید کرده است را بسازد. این داده، پروفایل رفتاری دقیقی از کاربر می‌سازد که بسیار حساس‌تر از خود ترافیک HTTP است، زیرا حتی با HTTPS نیز دامنه مقصد در پرس‌وجوی DNS قابل مشاهده است.

مطالعات منتشرشده در کنفرانس‌های امنیتی نشان می‌دهد که بیش از ۹۰ درصد از ISPهای بزرگ جهان، داده پرس‌وجوهای DNS کاربران را به‌صورت فعالانه ذخیره می‌کنند. بخشی از این داده برای اهداف تجاری (تبلیغات هدفمند) و بخشی دیگر برای اهداف نظارتی استفاده می‌شود. در برخی کشورها، این داده‌ها به‌صورت قانونی با نهادهای دیگر به اشتراک گذاشته می‌شود.

نقص دوم: آسیب‌پذیری در برابر دستکاری

پرس‌وجوهای DNS در حالت سنتی هیچ امضای رمزنگاری ندارند. این یعنی مهاجم در مسیر می‌تواند پاسخ را تغییر دهد و آدرس IP جعلی برگرداند. این حمله که با نام DNS Spoofing یا DNS Cache Poisoning شناخته می‌شود، یکی از مؤثرترین روش‌های هدایت کاربر به سایت‌های جعلی است.

در حمله DNS Spoofing، مهاجم پاسخ واقعی سرور DNS را با یک پاسخ جعلی جایگزین می‌کند. از نگاه کاربر، هیچ تفاوت بصری وجود ندارد؛ مرورگر بدون هیچ هشداری، کاربر را به سایت جعلی می‌برد. اگر این حمله روی سایت بانک یا فروشگاه اینترنتی انجام شود، پیامد آن می‌تواند سرقت اطلاعات مالی باشد. برای درک عمیق‌تر این دسته از حملات، مطلب MITM چطور ارتباط شما را شنود می‌کند؟ را جداگانه مطالعه کنید.

نقص سوم: عدم تفکیک پرس‌وجوها و ردیابی طولانی‌مدت

هر پرس‌وجوی DNS به‌طور معمول شامل یک شناسه تراکنش است که به پاسخ پیوند داده می‌شود. این شناسه در سرورهای DNS لاگ می‌شود و می‌تواند با داده‌های دیگر — از جمله ترافیک کاربر، موقعیت جغرافیایی و زمان دقیق — ترکیب شود. نتیجه، ساخت پروفایل کاربری چندلایه است که حتی با VPN (Virtual Private Network) نیز کاملاً پنهان نمی‌شود؛ چون در VPNهای نادرست پیکربندی‌شده، ترافیک DNS می‌تواند از تونل خارج شود. اگر می‌خواهید بدانید VPN چگونه حریم خصوصی را تأمین می‌کند، مطلب VPN چطور حریم خصوصی آنلاین را تضمین می‌کند؟ راهنمای خوبی است.

تفاوت DoH و DoT و DoQ در عمل

پس از DoH، دو پروتکل مشابه دیگر نیز معرفی شدند که در برخی سناریوها جایگزین بهتری محسوب می‌شوند. درک تفاوت این سه، برای انتخاب معماری درست ضروری است.

DoT (DNS over TLS)

DoT در RFC 7858 تعریف شده و پرس‌وجوهای DNS را درون یک کانال TLS روی پورت اختصاصی ۸۵۳ ارسال می‌کند. مزیت اصلی DoT، تفکیک واضح ترافیک DNS از ترافیک HTTPS است که پایش شبکه را ساده‌تر می‌کند. اما همین ویژگی، در محیط‌هایی که فیلترینگ فعال است، یک ضعف محسوب می‌شود؛ چون پورت ۸۵۳ می‌تواند به‌سادگی مسدود شود.

DoQ (DNS over QUIC)

DoQ در RFC 9250 تعریف شده و از پروتکل QUIC (که پایه HTTP/3 است) برای انتقال پرس‌وجوها استفاده می‌کند. مزیت اصلی DoQ، کاهش تأخیر در برقراری اتصال است که در شبکه‌های موبایل تأثیر چشمگیری دارد. اما پشتیبانی از DoQ در نسخه فعلی مرورگرها و سیستم‌عامل‌ها هنوز کامل نیست.

مقایسه عملی سه پروتکل

انتخاب بین این سه به سه معیار بستگی دارد: قابلیت عبور از فیلترینگ، کارایی در شبکه‌های پرتأخیر، و پشتیبانی کلاینت. DoH به‌دلیل استفاده از پورت ۴۴۳، سخت‌ترین پروتکل برای مسدودسازی است. DoT ساده‌ترین برای پایش است اما ساده‌ترین برای مسدودسازی نیز هست. DoQ سریع‌ترین در برقراری اتصال است اما نوپاترین.

; نمونه پرس‌وجوی DoH با curl
curl -H "accept: application/dns-json" \
     "https://cloudflare-dns.com/dns-query?name=wordpresskar.ir&type=A"

; نمونه پرس‌وجوی DoH با قالب wireformat
curl -H "accept: application/dns-message" \
     "https://dns.google/dns-query?dns=AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE"

DoH در بافت وردپرس: چرا مهم است؟

وردپرس به‌عنوان یک CMS (Content Management System) به‌طور مستقیم با DNS کار نمی‌کند؛ اما در سه لایه، DoH مستقیماً بر تجربه کاربری و امنیت سایت اثر می‌گذارد.

لایه اول: اتصال‌های خروجی وردپرس

وردپرس در پشت صحنه اتصال‌های متعددی به سرویس‌های خارجی برقرار می‌کند: بررسی به‌روزرسانی‌های هسته و افزونه‌ها، فراخوانی APIهای پرداخت، دریافت فیدهای خبری از سایت‌های دیگر، ارتباط با سرویس‌های ایمیل تراکنشی و اتصال به CDN (Content Delivery Network). هر یک از این اتصال‌ها با یک پرس‌وجوی DNS آغاز می‌شود. اگر این پرس‌وجو توسط مهاجم دستکاری شود، وردپرس ممکن است داده‌های حساس را به سرور جعلی ارسال کند.

لایه دوم: تجربه بازدیدکننده

وقتی یک کاربر قصد بازدید از سایت وردپرسی شما را دارد، اولین اقدام مرورگر او یک پرس‌وجوی DNS است. اگر این پرس‌وجو توسط ISP دستکاری شود — که در برخی مناطق رایج است — کاربر یا به سایت شما دسترسی پیدا نمی‌کند، یا به یک نسخه جعلی هدایت می‌شود. DoH در سمت مرورگر این مشکل را برای کاربر حل می‌کند، اما شما به‌عنوان صاحب سایت کنترل مستقیمی بر تنظیمات مرورگر کاربر ندارید.

لایه سوم: رزولور سرور

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

DoH یک ویژگی مرورگر نیست؛ یک تصمیم زیرساختی است که از سرور وردپرس تا دستگاه بازدیدکننده ادامه می‌یابد.

انتخاب رزولور DoH مناسب

انتخاب رزولور DoH، یکی از مهم‌ترین تصمیم‌های معماری در پیاده‌سازی این پروتکل است. رزولور، نقطه‌ای است که همه پرس‌وجوهای شما از آن عبور می‌کنند؛ بنابراین انتخاب نادرست آن، حریم خصوصی را به نقطه دیگری منتقل می‌کند، نه اینکه آن را از بین ببرد.

معیارهای انتخاب

پنج معیار کلیدی برای انتخاب رزولور DoH وجود دارد. نخست، سیاست حفظ حریم خصوصی: آیا رزولور لاگ‌ها را برای مدت طولانی نگه می‌دارد؟ دوم، شفافیت: آیا رزولور گزارش‌های مستقل حسابرسی منتشر می‌کند؟ سوم، پراکندگی جغرافیایی: آیا سرورهای لبه در مناطق مختلف دارد؟ چهارم، پشتیبانی از پروتکل‌های دیگر: آیا رزولور DoT و DoQ را نیز پشتیبانی می‌کند؟ پنجم، پشتیبانی از DNSSEC (Domain Name System Security Extensions) که در بخش اختصاصی بررسی می‌شود.

گزینه‌های محبوب

چند رزولور DoH در سطح جهانی شناخته‌شده هستند: Cloudflare DNS روی 1.1.1.1، Google Public DNS روی 8.8.8.8، Quad9 روی 9.9.9.9 که تمرکز آن بر امنیت است، و NextDNS که امکان کانفیگ سفارشی و فیلترینگ را فراهم می‌کند. هر یک از این‌ها سیاست حریم خصوصی متفاوتی دارند و انتخاب نهایی باید بر اساس نیاز پروژه انجام شود.

برای پروژه‌های سازمانی، گزینه‌ای میانی نیز وجود دارد: میزبانی رزولور DoH داخلی با استفاده از نرم‌افزارهایی مانند Unbound یا CoreDNS. این گزینه، حریم خصوصی را به‌طور کامل حفظ می‌کند اما نیازمند نگه‌داری زیرساخت است.

پیاده‌سازی DoH در لایه سرور

در سطح سرور لینوکس که وردپرس روی آن اجرا می‌شود، سه روش برای فعال‌سازی DoH وجود دارد. انتخاب روش مناسب، به سطح دسترسی و نیاز پروژه بستگی دارد.

روش اول: استفاده از systemd-resolved

در توزیع‌های مدرن لینوکس، سرویس systemd-resolved مدیریت رزولوشن DNS را بر عهده دارد. این سرویس از نسخه ۲۴۷ به بعد، پشتیبانی از DoT را به‌صورت بومی دارد. برای DoH، باید از یک کلاینت محلی مانند cloudflared یا dnscrypt-proxy استفاده کرد.

; پیکربندی systemd-resolved برای DoT (DoH نیازمند کلاینت جداگانه)
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=allow-downgrade
Domains=~.

; فعال‌سازی مجدد سرویس
; sudo systemctl restart systemd-resolved

روش دوم: dnscrypt-proxy

dnscrypt-proxy یک پروکسی متن‌باز است که هم از DoH و هم از DoT و DNSCrypt پشتیبانی می‌کند. این ابزار گزینه محبوبی برای سرورهای وردپرسی است، چون پیکربندی آن ساده است و امکان انتخاب چند رزولور با Fallback خودکار را فراهم می‌کند.

; بخشی از فایل dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:53']
server_names = ['cloudflare', 'google', 'quad9-dnscrypt-ip4-filter-pri']
force_tcp = false
timeout = 5000
cert_refresh_delay = 240
fallback_resolvers = ['9.9.9.9:53']
ignore_system_dns = true
netprobe_timeout = 60
require_dnssec = true
require_nolog = true
require_nofilter = false

نکته کلیدی در این پیکربندی، گزینه require_dnssec = true است که اجبار می‌کند رزولور از DNSSEC پشتیبانی کند. همچنین require_nolog = true تضمین می‌کند رزولورهای بدون لاگ انتخاب شوند.

روش سوم: cloudflared به‌عنوان پروکسی محلی

cloudflared ابزار رسمی Cloudflare است که یک رزولور DoH محلی روی 127.0.0.1:5053 راه‌اندازی می‌کند. سپس با تغییر /etc/resolv.conf، سرور از این رزولور محلی استفاده می‌کند.

; اجرای cloudflared به‌عنوان سرویس محلی
cloudflared proxy-dns --port 5053 --upstream https://1.1.1.1/dns-query

; تغییر resolv.conf
nameserver 127.0.0.1
; port برای پورت غیراستاندارد:
; options rotate timeout:1 attempts:3

; تست صحت
dig @127.0.0.1 -p 5053 wordpresskar.ir

هر سه روش معتبر هستند و انتخاب بین آن‌ها به سطح دسترسی و نیاز پروژه بستگی دارد. در پروژه‌های واقعی، ترکیب dnscrypt-proxy با unbound به‌عنوان کش محلی، بهترین توازن میان حریم خصوصی، کارایی و سادگی نگه‌داری را فراهم می‌کند.

کانفیگ DoH در مرورگر و کلاینت

در سطح کاربر نهایی، فعال‌سازی DoH به تنظیمات مرورگر یا سیستم‌عامل بستگی دارد. نکته مهم این است که شما به‌عنوان صاحب سایت، کنترل مستقیمی بر این تنظیمات ندارید؛ اما می‌توانید در محتوای آموزشی سایت، کاربران را به سمت گزینه‌های امن هدایت کنید.

فعال‌سازی در مرورگرها

Firefox از سال ۲۰۱۹ به‌طور پیش‌فرض DoH را برای کاربران آمریکایی فعال کرده است. Chrome از نسخه ۸۳ گزینه DoH را در تنظیمات ارائه می‌دهد. Edge از نسخه ۸۵ این قابلیت را اضافه کرده است. Safari در macOS Big Sur و iOS 14 به بعد از DoH پشتیبانی می‌کند اما فعال‌سازی آن نیازمند پروفایل مدیریتی یا نصب توصیف‌نامه است.

فعال‌سازی در سیستم‌عامل

در Windows 11، DoH به‌صورت بومی پشتیبانی می‌شود و از طریق Settings → Network & Internet → Ethernet/Wi-Fi → DNS server assignment قابل تنظیم است. در macOS 11 به بعد، DoH از طریق پروفایل‌های Configuration Profile قابل فعال‌سازی است. در Android 9 به بعد، گزینه Private DNS در تنظیمات شبکه وجود دارد که معادل DoT است.

ملاحظات عملی برای کاربران ایرانی

در شرایطی که ISPها ممکن است پورت ۸۵۳ را مسدود کنند، استفاده از DoH روی پورت ۴۴۳ مزیت واضحی دارد. کاربران می‌توانند آدرس رزولور DoH را در تنظیمات مرورگر وارد کنند و از مسدودسازی DNS عبور کنند. این توصیه، بخش مهمی از آموزش حریم خصوصی در سایت‌های وردپرسی است.

اثر DoH بر CDN و کش DNS

یکی از ملاحظات کمتر شناخته‌شده DoH، تأثیر آن بر رفتار CDN و کش DNS است. این تأثیر در پروژه‌های وردپرسی با ترافیک بالا بسیار مهم است.

تغییر در توزیع جغرافیایی

بسیاری از CDNها از DNS Anycast برای هدایت کاربر به نزدیک‌ترین سرور لبه استفاده می‌کنند. این تصمیم بر پایه موقعیت جغرافیایی رزولور DNS گرفته می‌شود، نه موقعیت واقعی کاربر. در DNS سنتی، رزولور معمولاً در همان شبکه ISP و نزدیک به کاربر است؛ بنابراین CDN می‌تواند موقعیت کاربر را به‌طور دقیق تخمین بزند. در DoH، اگر رزولور در کشور دیگری باشد، CDN ممکن است کاربر را به سروری در همان کشور رزولور هدایت کند که فاصله فیزیکی بیشتری دارد.

راه‌حل‌های فنی

سه راه‌حل برای این مشکل وجود دارد. نخست، انتخاب رزولور DoH با سرورهای لبه در همان منطقه کاربر. دوم، استفاده از EDNS Client Subnet که بخشی از آدرس IP کاربر را به رزولور منتقل می‌کند تا CDN بتواند تصمیم دقیق‌تری بگیرد. سوم، ترکیب DoH با Anycast در سطح خود سایت. برای کاهش تأخیر ناشی از رزولوشن، مطالعه چگونه سرعت DNS را بهبود دهیم؟ راهکارهای تکمیلی خوبی ارائه می‌دهد.

تأثیر بر کش DNS

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

DoH و سئو: آیا رتبه‌بندی تغییر می‌کند؟

یکی از پرسش‌های پرتکرار درباره DoH این است که آیا این پروتکل بر سئو اثر می‌گذارد یا خیر. پاسخ کوتاه این است: DoH به‌طور مستقیم هیچ اثری بر رتبه‌بندی ندارد، اما به‌طور غیرمستقیم از دو مسیر می‌تواند مؤثر باشد.

مسیر اول: تجربه کاربری

اگر DoH باعث کاهش زمان رزولوشن شود — که در بسیاری از سناریوها این‌طور است — زمان بارگذاری صفحه کاهش می‌یابد. زمان بارگذاری یک سیگنال غیرمستقیم در Core Web Vitals است و بهبود آن می‌تواند بر رتبه اثر بگذارد. اگر می‌خواهید بدانید چگونه این شاخص‌ها را بهبود دهید، مطلب چگونه Core Web Vitals را بهبود دهیم؟ راهنمای جامعی است.

مسیر دوم: دسترسی‌پذیری در مناطق محدود

اگر سایت شما در منطقه‌ای فعالیت می‌کند که DNS به‌طور فعال دستکاری می‌شود، کاربران ممکن است هرگز به سایت شما نرسند. در این شرایط، DoH تنها راه دسترسی بخشی از کاربران است. افزایش دسترسی، افزایش ترافیک و در نتیجه بهبود رتبه را به همراه دارد. برای کاهش مسائل شبکه‌ای، مطلب چگونه زمان بارگذاری سایت را کاهش دهیم بدون کورکورانه افزونه نصب کردن؟ نکات مفیدی ارائه می‌دهد.

DoH یک سیگنال مستقیم سئو نیست؛ اما در مناطقی که دسترسی به DNS دستکاری می‌شود، می‌تواند تفاوت میان دیده‌شدن و دیده‌نشدن باشد.

اشتباهات رایج در پیاده‌سازی DoH

در بررسی پروژه‌های متعدد، الگوهای تکرارشونده زیر پرتکرارترین خطاها در پیاده‌سازی DoH بوده‌اند. این خطاها نه از ضعف دانش، بلکه از ساده‌انگاری در تصمیم‌های معماری ناشی می‌شوند.

• انتخاب یک رزولور DoH بدون بررسی سیاست حفظ حریم خصوصی آن.
• فعال‌سازی DoH روی سرور بدون تنظیم یک کش محلی، که بار رزولور را چند برابر می‌کند.
• نادیده گرفتن EDNS Client Subnet و در نتیجه هدایت نامناسب کاربران توسط CDN.
• پیکربندی نادرست resolv.conf که منجر به Fallback خودکار به DNS سنتی می‌شود.
• عدم پایش جواب‌های رزولور که باعث می‌شود مشکلات DNS تا مدت طولانی پنهان بمانند.
• ترکیب DoH با DNSSEC در حالتی که رزولور از DNSSEC پشتیبانی نمی‌کند.
• نادیده گرفتن تأثیر DoH بر رفتار کش مرورگر و افزایش بار سرور رزولور عمومی.
• استفاده از رزولور DoH که در منطقه کاربر مسدود است.
• نداشتن مکانیزم Fallback برای مواقعی که رزولور DoH در دسترس نیست.
• عدم توجه به زمان‌بندی و رفتار پرس‌وجوهای پیوسته در پروژه‌های پرمصرف.

هر یک از این خطاها به‌تنهایی می‌تواند تجربه کاربری را تضعیف کند یا حریم خصوصی را به خطر بیندازد. اگر می‌خواهید از خطاهای پیکربندی DNS پیش از وقوع آگاه شوید، مطلب چرا اشتباهات رایج در تنظیم DNS این‌قدر خطرناک است؟ راهنمای عملی خوبی است.

پرسش‌های پرتکرار درباره DoH در وردپرس

در ادامه به پرسش‌هایی پاسخ می‌دهیم که بیشترین جستجو و بازخورد کاربران در ارتباط با DoH در بافت وردپرس داشته‌اند.

آیا DoH روی سرعت سایت وردپرسی اثر می‌گذارد؟

اثر DoH بر سرعت، بستگی به پیاده‌سازی دارد. در حالت بهینه، DoH می‌تواند زمان رزولوشن را کاهش دهد چون از اتصال TLS پایدار و کش محلی استفاده می‌کند. اما اگر پیاده‌سازی نادرست باشد — مثلاً بدون کش محلی و با رزولور دوردست — می‌تواند تأخیر اضافه کند. راه‌حل عملی، ترکیب DoH با یک کش محلی مانند Unbound است.

آیا DoH جایگزین DNSSEC است؟

خیر، DoH و DNSSEC دو لایه مکمل هستند و نه جایگزین یکدیگر. DoH محرمانگی و یکپارچگی کانال ارتباط با رزولور را تأمین می‌کند، در حالی که DNSSEC صحت داده خود پاسخ DNS را تضمین می‌کند. اگر می‌خواهید درک کامل‌تری از DNSSEC داشته باشید، مطلب DNSSEC برای وردپرس چرا نادیده گرفته می‌شود؟ را جداگانه بخوانید.

آیا DoH در ایران کار می‌کند؟

DoH در ایران از نظر فنی کار می‌کند چون روی پورت ۴۴۳ اجرا می‌شود که برای HTTPS ضروری است و مسدودسازی کامل آن عملاً ناممکن است. اما کیفیت کارکرد آن به انتخاب رزولور بستگی دارد. برخی رزولورهای عمومی ممکن است در ایران کند یا ناپایدار باشند؛ در چنین شرایطی، میزبانی رزولور داخلی گزینه بهتری است.

آیا DoH برای سایت‌های فروشگاهی وردپرسی توصیه می‌شود؟

بله، به‌ویژه برای فروشگاه‌هایی که در مناطق با فیلترینگ یا دستکاری DNS فعال هستند. DoH از دستکاری پرس‌وجوهای DNS جلوگیری می‌کند و اطمینان می‌دهد که مشتریان به درگاه پرداخت واقعی متصل می‌شوند، نه نسخه جعلی. برای تأمین امنیت کامل فروشگاه، ترکیب DoH با لایه‌های دیگر امنیتی توصیه می‌شود؛ مطلب امنیت فروشگاه ووکامرس: چگونه از یک نفوذ، فروش یک‌ساله را نجات دهیم؟ راهنمای جامعی است.

چه تفاوتی بین DoH و VPN وجود دارد؟

VPN کل ترافیک شبکه را رمزنگاری می‌کند و کاربر را از یک سرور واسط عبور می‌دهد، در حالی که DoH فقط پرس‌وجوهای DNS را رمزنگاری می‌کند. DoH سبک‌تر است و تأخیر کمتری دارد اما محافظت محدودتری ارائه می‌دهد. ترکیب DoH با VPN می‌تواند محافظت جامع‌تری فراهم کند، اما این ترکیب نیازمند پیکربندی دقیق است تا ترافیک DNS از تونل خارج نشود. اگر با ابزارهای مرتبط آشنا نیستید، مطلب پروکسی چیست و چه تفاوتی با VPN دارد؟ را مطالعه کنید.

آیا DoH بر عملکرد CDN اثر می‌گذارد؟

بله، DoH می‌تواند تصمیم CDN درباره نزدیک‌ترین سرور لبه را تحت تأثیر قرار دهد، چون CDN بر پایه موقعیت رزولور تصمیم می‌گیرد، نه موقعیت واقعی کاربر. برای رفع این مشکل، انتخاب رزولور DoH با سرورهای لبه در همان منطقه کاربر یا فعال‌سازی EDNS Client Subnet ضروری است.

آیا می‌توانم DoH را روی هاست اشتراکی فعال کنم؟

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

آیا DoH در تمام مرورگرها پشتیبانی می‌شود؟

در سال‌های اخیر، پشتیبانی از DoH در مرورگرهای اصلی گسترش یافته است. Firefox، Chrome، Edge و Safari همه از DoH پشتیبانی می‌کنند. اما روش فعال‌سازی و سطح پیش‌فرض آن متفاوت است. Firefox به‌طور پیش‌فرض DoH را فعال می‌کند، در حالی که Chrome و Edge آن را به‌صورت اختیاری ارائه می‌دهند.

نگاهی در سطح معماری شبکه

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

محدودیت اول، جابه‌جایی نقطه اعتماد است. DoH اعتماد را از ISP حذف نمی‌کند؛ آن را به رزولور منتقل می‌کند. اگر رزولور انتخابی شما لاگ‌های کاربران را ذخیره کند یا با نهادهای دیگر به اشتراک بگذارد، حریم خصوصی واقعی محقق نمی‌شود. راه‌حل توصیه‌شده برای پروژه‌های حساس، میزبانی رزولور DoH داخلی و پایش دقیق سیاست‌های آن است. ابزارهایی مانند dnscrypt-proxy به‌همراه unbound می‌توانند یک رزولور کامل با کش محلی، اعتبارسنجی DNSSEC و لاگ‌گیری حداقلی بسازند.

محدودیت دوم، نبود استاندارد یکپارچه در سطح مرورگر است. هر مرورگر روش متفاوتی برای فعال‌سازی DoH دارد و برخی از آن‌ها از مکانیزم‌های اختصاصی استفاده می‌کنند. این پراکندگی، پیاده‌سازی DoH را در سطح کاربر دشوار می‌کند و نیازمند آموزش مداوم است. برای پروژه‌های سازمانی، توصیه می‌شود از Configuration Profile یا Group Policy استفاده شود تا DoH به‌صورت یکپارچه روی همه دستگاه‌ها فعال شود.

محدودیت سوم، فقدان یک مکانیزم Fallback استاندارد است. اگر رزولور DoH در دسترس نباشد، اکثر کلاینت‌ها به‌طور خودکار به DNS سنتی برمی‌گردند که این Fallback خود می‌تواند یک نقطه ضعف امنیتی باشد. در برخی پیاده‌سازی‌ها، Fallback به DNS سنتی توسط مهاجم قابل بهره‌برداری است که با نام Downgrade Attack شناخته می‌شود. راه‌حل، پیکربندی صریح fallback_resolvers با رزولورهای امن است، نه واگذاری تصمیم به کلاینت.

در سطح پیاده‌سازی پیشرفته، توصیه می‌شود DoH را به‌عنوان بخشی از یک پروژه بزرگ‌تر حریم خصوصی شبکه در نظر بگیرید که شامل سه لایه است: لایه محلی (رزولور کش محلی روی سرور)، لایه سرور (اجبار DoH برای همه پرس‌وجوهای خروجی) و لایه کاربر (آموزش و توصیه به بازدیدکنندگان). این تفکیک، آزمون‌پذیری را بالا می‌برد و امکان جایگزینی هر لایه را بدون بازنویسی کل سیستم فراهم می‌کند. اگر پروژه شما در سطح سازمانی است، ترکیب DoH با اصول Zero Trust در لایه شبکه می‌تواند سطح امنیت را به‌طور چشمگیری بالا ببرد. برای تکمیل دانش خود در لایه DNS، مطالعه DNS امن چیست و چه مزایایی برای سایت دارد؟ را پیشنهاد می‌کنم. همچنین اگر با مفهوم Cloud DNS آشنا نیستید، مطلب DNS ابری چیست و چه تفاوتی با DNS سنتی دارد؟ تصویر کامل‌تری ارائه می‌دهد.

DoH یک راه‌حل نیست؛ یک لایه از یک معماری چندلایه حریم خصوصی است که بدون لایه‌های دیگر ناقص می‌ماند.

بستن این مسیر

DNS over HTTPS یک تغییر ساده در پروتکل نیست؛ یک بازتعریف از نقطه اعتماد در لایه‌ای است که همه ارتباطات اینترنت از آن عبور می‌کنند. برای سایت‌های وردپرسی، پیاده‌سازی DoH سه مزیت عملی دارد: افزایش حریم خصوصی کاربران، مقاومت در برابر دستکاری DNS، و بهبود تجربه کاربری در مناطق با فیلترینگ. اگر امروز تنها یک گام بردارید، بگذارید آن گام پیکربندی یک رزولور DoH محلی روی سرور وردپرس با کش محلی باشد؛ چون این گام، پایه همه گام‌های بعدی است. 🌐

اگر DoH را در یک پروژه واقعی پیاده‌سازی کرده‌اید، برایم جالب است بدانم کدام بخش بیشترین چالش را ایجاد کرد: انتخاب رزولور مناسب، پیکربندی کش محلی، یا تأثیر آن بر رفتار CDN. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راهکار جایگزینی پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد.