اگر میخواهید درخواستهای DNS روتر MikroTik بهجای DNS معمولی روی UDP/TCP پورت 53، از یک Resolver سازگار با DNS over HTTPS عبور کند، RouterOS این قابلیت را با use-doh-server در بخش DNS فراهم میکند. نکته مهم این است که صرف وارد کردن URL کافی نیست؛ باید وضعیت Certificate، دسترسی شبکه، DNS اولیه برای Resolve کردن نام DoH و رفتار Cache را هم بررسی کنید.
در این راهنما یک سناریوی واقعی را از بکاپ تا تنظیم، تست، عیبیابی و Rollback انجام میدهیم. مرجع فنی اصلی، مستند رسمی DNS در RouterOS است.

سناریو و پیشنیازها
فرض میکنیم RouterOS 7 دارید، اینترنت روتر سالم است و میخواهید DNS خود روتر و در صورت نیاز کلاینتهای LAN را از DoH عبور دهید. قبل از تغییر، از تنظیمات بکاپ بگیرید؛ برای روش کامل میتوانید آموزش بکاپ و بازیابی تنظیمات MikroTik را ببینید.
/system backup save name=before-doh
/export file=before-doh-export
همچنین ساعت روتر باید درست باشد؛ خطای زمان میتواند اعتبارسنجی TLS/Certificate را خراب کند.
/system clock print
/system ntp client print
مرحله ۱: وضعیت فعلی DNS را ثبت کنید
/ip dns print
قبل از هر تغییری مقادیر servers، use-doh-server، verify-doh-cert و allow-remote-requests را یادداشت کنید. طبق مستند RouterOS، وقتی use-doh-server تنظیم شود، DoH برای Queryها نسبت به فهرست معمول servers اولویت پیدا میکند.
مرحله ۲: URL سرویس DoH را تنظیم کنید
URL دقیق را از مستندات Resolver مورد اعتماد خود بگیرید. مثال زیر صرفاً ساختار فرمان را نشان میدهد؛ URL را با Endpoint واقعی سرویس انتخابی جایگزین کنید.
/ip dns set use-doh-server="https://YOUR-DOH-ENDPOINT/dns-query"
سپس تنظیم را بررسی کنید:
/ip dns print
نکته Bootstrap: اگر Endpoint با hostname تعریف شده باشد، روتر برای برقراری اولین اتصال باید بتواند نام آن را Resolve کند. DNS معمولی یا یک رکورد Static مناسب را قبل از قطع مسیر Bootstrap نگه دارید.
مرحله ۳: Verify کردن Certificate را فعال کنید
برای استفاده امن، اعتبارسنجی Certificate اهمیت دارد. اگر CA مورد نیاز در RouterOS قابل اعتماد است، Verify را فعال کنید:
/ip dns set verify-doh-cert=yes
اگر با فعالسازی این گزینه اتصال قطع شد، بهجای خاموش نگهداشتن Verify، ابتدا ساعت سیستم، زنجیره CA، hostname موجود در Certificate و دسترسی HTTPS را بررسی کنید.
مرحله ۴: اگر کلاینتهای LAN از MikroTik بهعنوان DNS استفاده میکنند
RouterOS میتواند DNS Cache برای کلاینتها باشد. برای پاسخگویی به درخواستهای Remote باید این گزینه فعال باشد:
/ip dns set allow-remote-requests=yes
هشدار امنیتی: DNS روتر را برای اینترنت عمومی باز نکنید. Firewall باید درخواست DNS را فقط از شبکههای مورد اعتماد LAN بپذیرد. باز بودن TCP/UDP 53 از WAN میتواند روتر را به Resolver عمومی ناخواسته تبدیل کند.
مرحله ۵: Cache را پاک و تست کنید
/ip dns cache flush
/resolve example.com
/ip dns cache print where name~"example.com"
خروجی /resolve باید IP معتبر برگرداند و رکورد در Cache دیده شود. برای تست از یک کلاینت LAN نیز یک Query جدید اجرا کنید. اگر DNS عمومی و مشکلات معمول Resolution برایتان مبهم است، مقاله نقش DNS در شبکه و مشکلات رایج آن مسیر پایه عیبیابی را توضیح میدهد.
چطور مطمئن شویم DoH واقعاً کار میکند؟
فقط موفق شدن /resolve کافی نیست، چون ممکن است Query از Cache پاسخ داده شده باشد. Cache را Flush کنید، سپس Query یک نام جدید را اجرا کنید و همزمان Log و Connectionها را بررسی کنید. انتظار دارید ارتباط HTTPS به Endpoint DoH برقرار شود، نه اینکه Query جدید مستقیماً به Resolver خارجی روی پورت 53 ارسال شود.
/ip dns cache flush
/resolve www.iana.org
/log print where message~"dns"
/ip firewall connection print where dst-port=443
خطاهای رایج DoH در MikroTik
۱. با تنظیم use-doh-server کل DNS قطع میشود
اول اتصال IP را بررسی کنید، سپس Bootstrap DNS و Endpoint را. اگر hostname سرویس DoH قابل Resolve نباشد، اتصال HTTPS اصلاً شروع نمیشود.
/ping 1.1.1.1 count=4
/resolve YOUR-DOH-HOSTNAME
۲. با verify-doh-cert=yes خطا میگیرید
سه مورد را بررسی کنید: زمان روتر، Certificate/CA مورد اعتماد و تطابق hostname. خاموش کردن دائمی Verify راهحل مطلوب نیست؛ فقط برای تشخیص کوتاهمدت و در محیط کنترلشده میتواند نشان دهد مشکل از Validation است.
۳. خود روتر Resolve میکند اما کاربران LAN نه
allow-remote-requests، DHCP DNS و Firewall ورودی را بررسی کنید. کلاینت باید IP روتر را بهعنوان DNS دریافت کرده باشد.
/ip dns print
/ip dhcp-server network print
/ip firewall filter print
۴. بعد از تغییر، بعضی دامنهها نتیجه قدیمی دارند
Cache روتر و Cache کلاینت را پاک کنید. برای درک TTL و رفتار Cache میتوانید راهنمای DNS Caching را بخوانید.
نکات امنیتی و عملی
- Endpoint DoH را فقط از سرویس معتبر و مستند انتخاب کنید.
verify-doh-cert=yesرا پس از رفع مشکلات Certificate فعال نگه دارید.- اگر
allow-remote-requests=yesاست، دسترسی DNS از WAN را با Firewall محدود کنید. - قبل از تغییر DNS روی روتر Production، Backup و Export داشته باشید.
- بعد از ارتقای RouterOS، تنظیمات DNS و رفتار Resolver را دوباره تست کنید.
Rollback؛ چطور سریع به DNS قبلی برگردیم؟
اگر DoH باعث اختلال شد، ابتدا Endpoint را خالی کنید و DNS قبلی را برگردانید:
/ip dns set use-doh-server=""
/ip dns set servers=YOUR_PREVIOUS_DNS_1,YOUR_PREVIOUS_DNS_2
/ip dns cache flush
سپس با /resolve example.com صحت Resolution را تست کنید. اگر تغییرات گستردهتری دادهاید، Backup/Export ابتدای کار مسیر Recovery شماست.
جمعبندی
راهاندازی DoH در MikroTik فقط یک URL نیست؛ یک تنظیم سالم باید Bootstrap DNS، TLS Certificate، Cache، دسترسی کلاینتها و Firewall را با هم پوشش دهد. ترتیب امن کار این است: Backup، ثبت DNS فعلی، تنظیم Endpoint، فعالسازی Certificate Verification، تست Query جدید، بررسی کلاینت LAN و در نهایت آماده داشتن Rollback.
اگر میخواهید همین سناریو را روی RouterOS/CHR در یک محیط مستقل اجرا و تست کنید، میتوانید از سرور مجازی میکروتیک وانسرور برای راهاندازی روتر مجازی و سناریوهای DNS و شبکه استفاده کنید.
سوالات متداول
خیر. DoH فقط ترافیک DNS را داخل HTTPS حمل میکند و کل ترافیک دستگاه را تونل نمیکند.
لزومی ندارد بدون برنامه Bootstrap این کار را انجام دهید. ابتدا مطمئن شوید hostname سرویس DoH قابل Resolve است و سپس رفتار نهایی را تست کنید.
چون اعتبار Certificate سرور HTTPS را بررسی میکند و احتمال اتصال به Endpoint جعلی یا دارای گواهی نامعتبر را کاهش میدهد.
use-doh-server را خالی کنید، DNS قبلی را در servers برگردانید، Cache را Flush کنید و دوباره Resolution را تست کنید.
