DNS یکی از سرویس‌هایی است که تقریباً تمام کاربران شبکه به‌صورت دائمی از آن استفاده می‌کنند، اما در بسیاری از شبکه‌های MikroTik هنوز فقط به شکل یک Resolver ساده با تنظیماتی مانند:

/ip/dns
set servers=1.1.1.1,8.8.8.8
set allow-remote-requests=yes

استفاده می‌شود.

در RouterOS 7، قابلیت‌های DNS بسیار فراتر از Cache و Forward کردن Queryها رفته‌اند. اکنون می‌توان از خود MikroTik برای سناریوهایی مانند:

  • رمزگذاری Queryهای DNS با DNS over HTTPS
  • مسدودکردن دامنه‌های تبلیغاتی و Tracking با Adlist
  • ارسال Queryهای یک Domain خاص به DNS Server متفاوت
  • ایجاد چند مجموعه DNS Forwarder
  • تبدیل پاسخ DNS به Firewall Address List
  • نام‌گذاری داخلی تجهیزات شبکه
  • Forward کردن mDNS بین VLANها
  • اجرای DNS در VRF مشخص
  • ساخت Dynamic DNS Record از DHCP Leaseها
  • تعریف CNAME، MX، TXT و NXDOMAIN

استفاده کرد.

نکته مهم: بیشتر قابلیت‌های DNS RouterOS زمانی روی Clientها اثر دارند که Client واقعاً از MikroTik به‌عنوان DNS Server استفاده کند. اگر Device مستقیماً از DNS دیگری مانند 1.1.1.1، 8.8.8.8 یا DoH داخلی مرورگر استفاده کند، Static DNS و Adlist روتر را دور می‌زند.

DNS در MikroTik چگونه کار می‌کند؟

RouterOS یک Caching DNS Resolver داخلی دارد.

روتر می‌تواند هم برای Queryهای خودش از DNS استفاده کند و هم در صورت فعال‌بودن:

allow-remote-requests=yes

به Clientهای شبکه روی UDP و TCP Port 53 پاسخ دهد.

نمونه:

/ip/dns
set servers=1.1.1.1,8.8.8.8 \
 allow-remote-requests=yes

سپس در DHCP Network آدرس Router را به‌عنوان DNS به Clientها ارائه می‌کنیم:

/ip/dhcp-server/network
set [find] dns-server=192.168.88.1

در این حالت مسیر Query:

Client
 ↓
MikroTik DNS
 ↓
Cache
 ↓
Upstream DNS
 ↓
Internet

خواهد بود.

فعال‌کردن DNS برای LAN بدون ساخت Open Resolver

یکی از مهم‌ترین نکات امنیتی این است که:

allow-remote-requests=yes

به معنی پاسخ‌دادن DNS روی IPهای Router است.

بنابراین Firewall باید اجازه DNS را فقط از شبکه‌های مورد اعتماد بدهد.

نمونه:

/ip/firewall/filter
add chain=input \
 protocol=udp \
 dst-port=53 \
 in-interface-list=LAN \
 action=accept \
 comment="Allow DNS from LAN"

/ip/firewall/filter
add chain=input \
 protocol=tcp \
 dst-port=53 \
 in-interface-list=LAN \
 action=accept \
 comment="Allow DNS TCP from LAN"

نباید DNS Resolver روتر بدون محدودیت از Internet قابل دسترس باشد.

Open DNS Resolver می‌تواند در DNS Amplification Attack مورد سوءاستفاده قرار گیرد. Firewall WAN را قبل از فعال‌کردن Remote DNS بررسی کنید.

Static DNS؛ ساخت نام داخلی تجهیزات

یکی از کاربردهای ساده ولی بسیار مفید MikroTik DNS ایجاد Local DNS Record است.

مثلاً:

/ip/dns/static
add name=nas.lan address=192.168.10.20

/ip/dns/static
add name=printer.lan address=192.168.10.30

/ip/dns/static
add name=nvr.lan address=192.168.70.10

از این پس کاربران شبکه می‌توانند به‌جای IP از نام استفاده کنند:

nas.lan
printer.lan
nvr.lan

در شبکه‌های کوچک و متوسط این قابلیت می‌تواند نیاز به یک DNS Server مستقل را برای Local Name Resolutionهای ساده کاهش دهد.

match-subdomain چه کاری انجام می‌دهد؟

فرض کنیم می‌خواهیم یک Record علاوه بر Domain اصلی، تمام Subdomainهای آن را نیز Match کند.

/ip/dns/static
add name=example.lan \
 address=192.168.88.30 \
 match-subdomain=yes

در این حالت Queryهایی مانند:

example.lan
www.example.lan
app.example.lan
server01.example.lan

همگی Match می‌شوند.

این قابلیت برای Internal Domainها، Split DNS و Policyهای دامنه‌ای بسیار کاربردی است.

Static DNS فقط A Record نیست

RouterOS از چند نوع DNS Record مهم پشتیبانی می‌کند.

CNAME

برای ساخت Alias:

/ip/dns/static
add name=files.lan \
 type=CNAME \
 cname=nas.lan

NXDOMAIN

می‌توان Domain را به‌صورت صریح Non-existent اعلام کرد:

/ip/dns/static
add name=tracker.example.com \
 type=NXDOMAIN

MX

/ip/dns/static
add name=example.lan \
 type=MX \
 mx-exchange=mail.example.lan \
 mx-preference=10

TXT

/ip/dns/static
add name=example.lan \
 type=TXT \
 text="Managed by RouterOS"

همچنین می‌توان به‌جای نام ثابت از Regular Expression استفاده کرد.

مثال:

/ip/dns/static
add regexp="^host[0-9]+\\.lan\$" \
 address=192.168.88.40

این قابلیت برای Match کردن گروهی از Hostnameها مفید است، ولی Regexهای زیاد و پیچیده نباید بدون دلیل روی Routerهای ضعیف استفاده شوند.

قابلیت FWD؛ ارسال Domain خاص به DNS دیگر

یکی از کاربردی‌ترین قابلیت‌های DNS در RouterOS، Record نوع:

FWD

است.

فرض کنید DNS عمومی شبکه Cloudflare است، اما Queryهای:

corp.example.com

باید به DNS داخلی شرکت:

10.0.0.53

فرستاده شوند.

می‌توان نوشت:

/ip/dns/static
add name=corp.example.com \
 type=FWD \
 forward-to=10.0.0.53 \
 match-subdomain=yes

مسیر Resolution:

Public Domains
 ↓
Normal DNS


corp.example.com
 ↓
10.0.0.53

این قابلیت برای:

  • Active Directory
  • شبکه‌های شعب
  • Split DNS
  • Internal Domains
  • VPN
  • Multi-site Networks

بسیار کاربردی است.

DNS Forwarders؛ ساخت مجموعه‌های DNS مستقل

در RouterOS می‌توان یک Forwarder نام‌گذاری‌شده ایجاد کرد.

برای مثال:

/ip/dns/forwarders
add name=branch-dns \
 dns-servers=10.1.0.53,10.1.1.53

سپس Domain مشخص را به این Forwarder متصل کنیم:

/ip/dns/static
add name=branch.example.com \
 type=FWD \
 forward-to=branch-dns \
 match-subdomain=yes

این طراحی نسبت به تعریف DNS IP جدا برای هر Rule، Configuration مرتب‌تر و قابل نگهداری‌تری ایجاد می‌کند.

Forwarderها می‌توانند شامل DNS و DoH Serverهای مخصوص خود نیز باشند.

Forwarder را معادل Health-check Load Balancer در نظر نگیرید. اگر یک Server موجود در Forwarder پاسخ ندهد، Router الزاماً Query همان مرحله را به Server سالم بعدی Retry نمی‌کند و Query می‌تواند Fail شود. فقط DNS Serverهای قابل اعتماد را در Forwarder قرار دهید.

ساخت Firewall Address List از DNS Response

یکی از قابلیت‌های بسیار کاربردی RouterOS، اتصال DNS Resolution به Firewall Address List است.

مثلاً:

/ip/dns/static
add name=example.com \
 type=FWD \
 address-list=example-com \
 match-subdomain=yes

وقتی Client شبکه از طریق MikroTik نام:

example.com

را Resolve کند، IPهای دریافت‌شده از DNS به Address List:

example-com

اضافه می‌شوند.

سپس می‌توان از آن در:

  • Firewall Filter
  • Mangle
  • Policy Routing
  • Traffic Marking

استفاده کرد.

برای مشاهده:

/ip/firewall/address-list
print where list=example-com

می‌توان مدت باقی‌ماندن IPها را با:

address-list-extra-time

بیشتر کرد.

برای مثال:

/ip/dns
set address-list-extra-time=5m

این قابلیت Domain-based Firewall واقعی به معنای Application Control نیست. یک Domain ممکن است از CDN، IP مشترک یا IPهای متغیر استفاده کند؛ بنابراین قبل از استفاده برای Policy امنیتی حساس باید رفتار سرویس را بررسی کنید.

Adlist؛ مسدودکردن تبلیغات و Tracking در سطح DNS

RouterOS می‌تواند لیست Domainهای تبلیغاتی یا Tracking را مستقیماً وارد DNS کند.

ابتدا Cache را افزایش دهید:

/ip/dns
set cache-size=16384

سپس Adlist:

/ip/dns/adlist
add url="ADLIST-URL"

برای مشاهده وضعیت:

/ip/dns/adlist/print

دو Counter مهم:

name-count
match-count

هستند.

name-count تعداد Domainهای Import شده و match-count تعداد Queryهای Match شده را نشان می‌دهد.

وقتی یک Domain در Adlist قرار داشته باشد، Router برای Queryهای A و AAAA پاسخ:

A
→ 0.0.0.0

AAAA
→ ::

می‌دهد.

Adlist محلی

می‌توان فایل Local نیز ساخت:

/file/add name=adlist.txt \
contents="0.0.0.0 ads.example.net\ntracker.example.net\n"

/ip/dns/adlist
add file=adlist.txt

Pause کردن موقت Adlist

مثلاً برای ۱۰ دقیقه:

/ip/dns/adlist
pause duration=10m

Reload

/ip/dns/adlist/reload

Adlistها به‌صورت دوره‌ای نیز برای Update بررسی می‌شوند.

چقدر RAM برای Adlist نیاز داریم؟

Adlist در DNS Cache Memory نگهداری می‌شود.

بنابراین Routerهای دارای RAM محدود نباید Listهای بسیار بزرگ را بدون محاسبه استفاده کنند.

مثلاً List حدود 75 هزار Domain تقریباً چند مگابایت Cache مصرف می‌کند.

اگر Cache پر شود، Log مشابه:

adlist read: max cache size reached

نمایش داده می‌شود.

اگر Import به‌دلیل کمبود Cache متوقف شود، فقط افزایش cache-size ادامه Import قبلی را کامل نمی‌کند. پس از افزایش Cache، Adlist را مجدداً Import کنید.

Whitelist کردن Domain در Adlist

اگر یک Domain به اشتباه Block شده باشد، می‌توان با FWD آن را از Adlist مستثنا کرد:

/ip/dns/static
add name=ads.example.net \
 type=FWD

در این حالت Query به Upstream DNS Forward می‌شود.

این روش برای Exceptionهای محدود و کنترل‌شده بسیار کاربردی است.

محدودیت مهم Adlist

Adlist یک UTM یا Secure Web Gateway نیست.

محدودیت‌های آن شامل:

  • Domain-level Blocking
  • Block شدن A و AAAA
  • عدم پشتیبانی از Wildcard به شکل معمول
  • عدم بررسی محتوای HTTPS
  • امکان Bypass توسط DNS خارجی یا DoH Client

است.

بنابراین:

Adlist
≠
Complete Content Filtering

DNS over HTTPS در MikroTik

DNS معمولی روی UDP/TCP Port 53 به‌صورت رمزگذاری‌نشده منتقل می‌شود.

DoH Query را داخل HTTPS منتقل می‌کند.

نمونه Configuration:

/ip/dns
set use-doh-server="https://DOH-SERVER/dns-query" \
 verify-doh-cert=yes

فعال‌کردن:

verify-doh-cert=yes

برای جلوگیری از اعتماد بدون بررسی به Certificate اهمیت دارد.

یک نکته بسیار مهم درباره Failover

وقتی use-doh-server تنظیم شده باشد، Router Queryهای معمول Upstream را از DoH ارسال می‌کند.

اگر DoH Server در دسترس نباشد:

DoH unavailable
 ↓
SERVFAIL

Router به‌صورت خودکار به DNS معمولی تنظیم‌شده در servers Failover نمی‌کند.

DNS Serverهای عادی ممکن است فقط برای Resolve اولیه Hostname خود DoH Server استفاده شوند.

DoH بدون طراحی Availability می‌تواند خودش Single Point of Failure شود.

HTTP/2 و Architecture

در RouterOS جدید، ARM64 و x86/CHR می‌توانند برای DoH از HTTP/2 استفاده کنند.

برخی Providerهای DoH که HTTP/2 را الزامی می‌کنند ممکن است روی Architectureهای قدیمی‌تر قابل استفاده نباشند.

بنابراین Provider را قبل از Deployment روی همان Hardware تست کنید.

mDNS Repeater؛ AirPrint و Chromecast بین VLANها

mDNS برای کشف سرویس‌های Local استفاده می‌شود؛ برای مثال:

  • AirPrint
  • AirPlay
  • Chromecast
  • Printer Discovery
  • Smart Home Devices

مشکل اینجاست که mDNS معمولاً از Router عبور نمی‌کند.

فرض کنید:

VLAN 20
Users

VLAN 30
Printers

دارید.

می‌توان mDNS را بین دو Interface Repeat کرد:

/ip/dns
set mdns-repeat-ifaces=vlan20,vlan30

به این ترتیب Discovery می‌تواند میان VLANها انجام شود.

mDNS Repeater فعلی RouterOS برای IPv4 mDNS است. همچنین این قابلیت جایگزین Firewall Policy نیست؛ ارتباط واقعی بین Client و Service همچنان باید توسط Firewall مجاز باشد.

اگر Input Firewall پورت:

UDP 5353

را روی Interface مربوطه Block کند، Rule لازم را قبل از Drop ایجاد کنید:

/ip/firewall/filter
add chain=input \
 protocol=udp \
 dst-port=5353 \
 action=accept \
 comment="Allow mDNS"

DNS در VRF

در شبکه‌هایی که چند VRF دارند، RouterOS امکان مشخص‌کردن VRF برای DNS Resolver را فراهم می‌کند.

برای مثال:

/ip/dns
set vrf=main

برای دسترسی به Upstream DNS در VRF دیگر نیز می‌توان Server را همراه VRF تعریف کرد:

/ip/dns
set servers=10.0.0.53@vrf1

این قابلیت در شبکه‌های:

  • Enterprise
  • ISP
  • Multi-tenant
  • Segmentation پیشرفته

ارزش زیادی دارد.

ساخت خودکار DNS Entry برای Clientها

در RouterOS جدید، DHCP Server و بعضی مکانیزم‌های Neighbor Discovery می‌توانند Dynamic DNS Entry ایجاد کنند.

این قابلیت باعث می‌شود Clientهایی که Lease دریافت می‌کنند با نام قابل شناسایی باشند و نیازی به تعریف دستی تمام Hostها وجود نداشته باشد.

پارامترهای مرتبط شامل:

add-dns-entries
add-dns-entries-suffix

هستند.

سناریوی مفهومی:

Laptop DHCP Lease
 ↓
Hostname
 ↓
Dynamic DNS Entry
 ↓
laptop.office.lan

این قابلیت در شبکه‌هایی با تعداد زیاد Client، Lab، مدارس و دفاتر بسیار مفید است.

بهینه‌سازی DNS Cache

DNS Cache باعث می‌شود Router پاسخ Queryهای تکراری را بدون مراجعه مجدد به Upstream DNS ارائه کند.

برای مشاهده:

/ip/dns/cache/print

و برای مشاهده Recordهای بیشتر:

/ip/dns/cache/all/print

مقدار Cache:

/ip/dns
set cache-size=8192

باید براساس RAM، تعداد Clientها و Adlistها انتخاب شود.

پارامتر:

cache-max-ttl

نیز حداکثر زمانی را که پاسخ Upstream در Cache باقی می‌ماند کنترل می‌کند.

Timeout و Concurrent Query

برای شبکه‌های پرترافیک این پارامترها اهمیت دارند:

query-server-timeout
query-total-timeout
max-concurrent-queries

اگر تعداد Queryهای در انتظار به سقف max-concurrent-queries برسد، Queryهای جدید می‌توانند Drop شوند.

بنابراین در شبکه سازمانی بزرگ باید DNS Load و Router Resources نیز مانیتور شوند.

Troubleshooting DNS در RouterOS

تست Resolve از خود Router

:resolve example.com

مشاهده Configuration

/ip/dns/print

مشاهده Cache

/ip/dns/cache/print

مشاهده Static Entryها

/ip/dns/static/print detail

Adlist

/ip/dns/adlist/print detail

Forwarders

/ip/dns/forwarders/print detail

فعال‌کردن Log برای DNS

/system/logging
add topics=dns

در صورت مشکل DoH، Adlist یا Upstream Resolver، Log یکی از اولین محل‌هایی است که باید بررسی شود.

چرا Client از Static DNS یا Adlist استفاده نمی‌کند؟

اول بررسی کنید Client واقعاً MikroTik را به‌عنوان DNS دارد.

اگر Client DNS مستقیمی مانند:

8.8.8.8
1.1.1.1

یا DoH داخل Browser استفاده کند، Query از MikroTik عبور نمی‌کند.

ساختار مورد انتظار:

Client
 ↓
MikroTik DNS
 ↓
Policy / Cache / Adlist
 ↓
Upstream

است.

چند سناریوی کاربردی DNS در MikroTik

سناریو اول؛ شبکه اداری

Employees
 ↓
MikroTik DNS
 ↓
DoH
 ↓
Internet

Internal Domain
 ↓
FWD
 ↓
Active Directory DNS

سناریو دوم؛ مدرسه

Students
 ↓
MikroTik DNS
 ↓
Adlist / Filtered Upstream

Teachers
 ↓
Normal / Filtered DNS

Printers VLAN
 ↕
mDNS Repeater
 ↕
Teachers VLAN

سناریو سوم؛ شعب سازمان

Internet Domains
→ Public DNS

hq.example.com
→ HQ DNS

branch.example.com
→ Branch DNS

با FWD و Forwarder می‌توان این ساختار را بدون تغییر DNS اصلی Clientها پیاده‌سازی کرد.

سناریو چهارم؛ Policy Routing براساس Domain

Domain Query
 ↓
DNS FWD
 ↓
Dynamic Address List
 ↓
Mangle
 ↓
Policy Routing

این روش می‌تواند برای بعضی سناریوهای Routing مفید باشد، ولی در سرویس‌های CDN-heavy باید با احتیاط استفاده شود.

DNS MikroTik چه کارهایی را انجام نمی‌دهد؟

افزایش قابلیت‌های DNS RouterOS به این معنی نیست که Router به یک DNS Security Appliance کامل تبدیل شده است.

MikroTik DNS به‌تنهایی جایگزین:

  • Secure Web Gateway
  • NGFW Application Control
  • Enterprise DNS Security
  • DNS Threat Intelligence Platform
  • Content Inspection

نیست.

Adlist نیز صرفاً Domain-level Blocking انجام می‌دهد.

همچنین Client می‌تواند از:

  • DoH
  • DoT
  • VPN
  • Proxy

برای دورزدن DNS Policy محلی استفاده کند.

بهترین استفاده از MikroTik DNS این است که آن را بخشی از معماری امنیت شبکه بدانیم، نه تمام معماری امنیت.

چک‌لیست نهایی راه‌اندازی DNS در MikroTik

  1. RouterOS Version بررسی شده است.
  2. Upstream DNS مشخص شده است.
  3. Clientها MikroTik را به‌عنوان DNS دریافت می‌کنند.
  4. allow-remote-requests فقط در صورت نیاز فعال شده است.
  5. Firewall اجازه DNS را فقط از LAN می‌دهد.
  6. DNS از WAN قابل دسترس نیست.
  7. Static DNS Recordهای داخلی تعریف شده‌اند.
  8. match-subdomain در صورت نیاز استفاده شده است.
  9. FWD برای Internal Domainها بررسی شده است.
  10. Forwarderهای اضافی فقط شامل Resolverهای سالم هستند.
  11. DoH Certificate Verification فعال شده است.
  12. Unavailable شدن DoH در طراحی لحاظ شده است.
  13. Adlist متناسب با RAM انتخاب شده است.
  14. cache-size قبل از Import Adlist افزایش یافته است.
  15. Adlist Whitelist در صورت نیاز تعریف شده است.
  16. mDNS فقط بین VLANهای موردنیاز Repeat می‌شود.
  17. UDP 5353 در Firewall بررسی شده است.
  18. Dynamic DNS Entryهای DHCP در صورت نیاز فعال شده‌اند.
  19. DNS Address List فقط برای Policy مناسب استفاده می‌شود.
  20. Cache Usage مانیتور می‌شود.
  21. DNS Log در زمان Troubleshooting بررسی می‌شود.

سؤالات متداول درباره DNS در MikroTik

آیا MikroTik می‌تواند DNS Server باشد؟

بله. RouterOS دارای Caching DNS Resolver است و با فعال‌کردن allow-remote-requests می‌تواند به Clientهای شبکه پاسخ دهد.

آیا MikroTik از DNS over HTTPS پشتیبانی می‌کند؟

بله. می‌توان Upstream DNS را از طریق HTTPS رمزگذاری کرد.

آیا MikroTik از DoT پشتیبانی می‌کند؟

قابلیت اصلی رمزگذاری DNS در Resolver فعلی RouterOS بر مبنای DoH است و نباید DoH را با DNS over TLS یکسان دانست.

آیا می‌توان تبلیغات را با MikroTik Block کرد؟

بله. Adlist می‌تواند Domainهای مشخص را در سطح DNS برای Queryهای A و AAAA مسدود کند.

Adlist جایگزین Pi-hole است؟

برای Blocking ساده در سطح DNS می‌تواند بخشی از نیاز را پوشش دهد، اما امکانات گزارش‌گیری، UI، Group Policy و Extensionهای یک DNS Filtering Platform کامل را ندارد.

چرا Adlist من کامل Import نمی‌شود؟

یکی از دلایل رایج کمبود DNS Cache است. قبل از افزودن List بزرگ، cache-size را افزایش دهید.

چگونه یک Domain را از Adlist خارج کنیم؟

برای آن Domain یک Static DNS Entry از نوع FWD ایجاد کنید.

FWD در DNS MikroTik چیست؟

FWD اجازه می‌دهد Query یک Domain یا Subdomain مشخص به DNS Server یا Forwarder جداگانه ارسال شود.

آیا می‌توان Active Directory DNS را فقط برای Domain داخلی استفاده کرد؟

بله. با FWD و match-subdomain می‌توان Queryهای Domain سازمانی را به DNS داخلی و سایر Queryها را به Resolver عمومی ارسال کرد.

DNS Forwarder چه تفاوتی با FWD دارد؟

FWD Rule مشخص می‌کند کدام Domain Forward شود؛ Forwarder یک مجموعه نام‌گذاری‌شده از DNS/DoH Serverها است که FWD می‌تواند به آن ارجاع دهد.

آیا DNS Forwarder Failover کامل دارد؟

نباید آن را Health-aware Failover در نظر گرفت. Serverهای غیرفعال می‌توانند باعث Failure بعضی Queryها شوند.

DNS Address List چیست؟

Router می‌تواند IPهای پاسخ داده‌شده برای یک Domain را به Firewall Address List پویا اضافه کند تا در Firewall یا Policy Routing استفاده شوند.

آیا IPهای DNS Address List دائمی هستند؟

خیر. عمر آن‌ها به TTL پاسخ DNS و در صورت تنظیم به address-list-extra-time وابسته است.

mDNS Repeater چه کاری انجام می‌دهد؟

Discovery سرویس‌هایی مانند AirPrint و Chromecast را میان Interfaceها یا VLANهای انتخاب‌شده منتقل می‌کند.

آیا mDNS از WireGuard عبور می‌کند؟

WireGuard یک Tunnel لایه ۳ است و Multicast mDNS را به‌صورت Native حمل نمی‌کند؛ mDNS Repeater RouterOS نیز برای Interfaceهای Multicast طراحی شده است.

آیا mDNS Repeater از IPv6 پشتیبانی می‌کند؟

در پیاده‌سازی فعلی RouterOS، Repeater مستندشده مربوط به IPv4 mDNS است.

آیا MikroTik می‌تواند DNS را در VRF اجرا کند؟

بله. Resolver می‌تواند برای یک VRF مشخص تنظیم شود و Upstream Server نیز با پسوند VRF تعریف شود.

چرا Static DNS روی Client کار نمی‌کند؟

اغلب Client از DNS دیگری استفاده می‌کند یا Browser از DoH مستقل استفاده کرده است. ابتدا DNS واقعی Client را بررسی کنید.

آیا می‌توان DNS کاربران را مجبور کرد از MikroTik عبور کند؟

برای DNS معمولی روی Port 53 می‌توان Firewall Policy اعمال کرد، اما Client-side DoH، VPN و Proxy نیازمند کنترل‌های تکمیلی هستند.

آیا DNS Cache باعث افزایش سرعت می‌شود؟

برای Queryهای تکراری می‌تواند Latency Resolution را کاهش دهد و تعداد Queryهای Upstream را کم کند، ولی تأثیر آن روی سرعت انتقال Data نیست.

آیا Routerهای ضعیف برای Adlist بزرگ مناسب‌اند؟

الزاماً خیر. RAM، Storage، DNS Cache و تعداد Clientها باید قبل از انتخاب List بزرگ بررسی شوند.

جمع‌بندی؛ DNS در RouterOS 7 فراتر از یک Resolver ساده است

قابلیت‌های فعلی DNS در MikroTik را می‌توان این‌گونه خلاصه کرد:

DNS Cache
+
Static DNS
+
CNAME / MX / TXT / NXDOMAIN
+
FWD
+
Forwarders
+
DNS → Firewall Address List
+
Adlist
+
DNS over HTTPS
+
mDNS Repeater
+
VRF
+
Dynamic DNS Entries
=
Advanced RouterOS DNS

این مجموعه امکانات اجازه می‌دهد MikroTik در بسیاری از شبکه‌های کوچک و متوسط نقش DNS Resolver مرکزی، Split-DNS Gateway، Ad-blocking Resolver و واسط میان DNS و Firewall را ایفا کند.

با این حال، طراحی باید متناسب با نیاز واقعی شبکه انجام شود. Adlist جایگزین UTM نیست، DoH بدون Availability Planning می‌تواند Single Point of Failure ایجاد کند و DNS Address List نیز برای سرویس‌های CDN یا Shared IP نیازمند بررسی دقیق است.

قدرت اصلی DNS در RouterOS 7 زمانی مشخص می‌شود که DNS، Firewall، VLAN، DHCP و Policy Routing به‌صورت یک معماری واحد طراحی شوند.

طراحی DNS و Policy شبکه با MikroTik

اگر برای شبکه سازمانی، مدرسه، شعب یا زیرساخت MikroTik نیاز به DNS داخلی، Adlist، DoH، Split DNS، VLAN و Firewall Policy دارید، بهتر است Configuration براساس ساختار واقعی شبکه طراحی شود.

برای مشاوره فنی، طراحی زیرساخت و استعلام قیمت و موجودی تجهیزات MikroTik می‌توانید با تیم بیستون در ارتباط باشید.