با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Router میتواند Resolver برای LAN باشد
RouterOS میتواند برای Clientهای LAN نقش DNS Cache و Resolver میانی را داشته باشد؛ در این حالت Clientها IP روتر را به عنوان DNS دریافت میکنند و روتر درخواستها را به DNS Serverهای بالادستی میفرستد و پاسخهای قابل Cache را نگه میدارد؛ این طراحی در شبکههای کوچک مدیریت DNS را ساده میکند، چون اگر DNS بالادستی تغییر کند لازم نیست تکتک Clientها تغییر کنند؛ با این حال باید فرق بین «DNS خود روتر» و «DNSی که به Clientها معرفی میشود» را بفهمی؛ اگر Client مستقیماً DNS دیگری بگیرد، Cache روتر در مسیر آن درخواست قرار نمیگیرد؛ در عیبیابی ابتدا بررسی کن Client چه DNSی دارد، بعد ببین RouterOS چه Serverهای Static یا Dynamicی میشناسد و آیا خودش میتواند نام را Resolve کند. Ping به IP و سپس تست نام دامنه کمک میکند مشکل Routing را از DNS جدا کنی. DNS زمانی خوب کار میکند که Route رسیدن به Resolver بالادستی، Firewall و تنظیم DHCP با هم سازگار باشند. Resolver روتر باید بخشی از طراحی باشد، نه یک گزینه فعالشده بدون کنترل
Allow Remote Requests باید محدود شود
گزینه Allow Remote Requests تعیین میکند RouterOS به درخواستهای DNS دستگاههای دیگر پاسخ بدهد؛ وقتی این گزینه فعال است، روتر روی TCP و UDP پورت ۵۳ درخواست DNS را میپذیرد و به همین دلیل باید دسترسی به آن فقط از شبکههای شناختهشده مجاز باشد؛ مستندات MikroTik صریحاً هشدار میدهند که اگر Remote Requests فعال است، Firewall باید دسترسی DNS را به Hostها یا شبکههای مورد اعتماد محدود کند؛ باز گذاشتن DNS Resolver روی WAN میتواند روتر را در معرض سوءاستفاده به عنوان Open Resolver قرار دهد و ترافیک ناخواسته ایجاد کند؛ برای پشتیبان شبکه کافی نیست فقط گزینه را روشن کند و ببیند کاربران اینترنت دارند؛ باید Chain ورودی Firewall و Interfaceهای مجاز را هم بررسی کند؛ اگر DNS برای LAN لازم است، دسترسی از LAN یا VLANهای مشخص مجاز و از WAN مسدود شود؛ در زمان عیبیابی اگر Client به IP روتر Ping دارد ولی DNS پاسخ نمیدهد، علاوه بر تنظیم DNS، Ruleهای input و پورت ۵۳ را بررسی کن؛ امنیت DNS و کارکرد آن دو موضوع جدا نیستند و باید همزمان طراحی شوند
Static DNS برای نام داخلی ساده مفید است
Static DNS Entry در RouterOS اجازه میدهد برای بعضی نامها پاسخ مشخص محلی تعریف کنی؛ این قابلیت برای شبکههای سادهای که چند سرویس داخلی محدود دارند میتواند مفید باشد، اما جای DNS سازمانی کامل مثل DNS مرتبط با Active Directory را نمیگیرد؛ اگر یک Server داخلی نام مشخصی دارد و همه Clientها MikroTik را به عنوان Resolver استفاده میکنند، Static Entry میتواند همان نام را به IP داخلی برگرداند؛ هنگام استفاده باید به TTL، تغییر IP و احتمال وجود رکورد مشابه در DNS بالادستی توجه کنی؛ اگر یک رکورد قدیمی باقی بماند، کاربران ممکن است به Address اشتباه هدایت شوند و تصور شود خود سرویس خراب است؛ قبل از افزودن رکورد، مشخص کن نام در کدام Domain قرار دارد و منبع authoritative واقعی آن چیست؛ در محیط Domain، رکوردهای Active Directory باید در DNS مناسب همان Domain مدیریت شوند. Static DNS روی MikroTik بیشتر برای نیازهای ساده و محدود مناسب است؛ در عیبیابی Cache و Static Entryها را با نتیجه Query مقایسه کن و اگر IP سرویس تغییر کرده، فقط Client را مقصر ندان
Cache پاسخها را نگه میدارد
DNS Cache پاسخهایی را که Resolver دریافت کرده برای مدتی نگه میدارد تا درخواستهای بعدی سریعتر پاسخ داده شوند و Query تکراری کمتری به Server بالادستی ارسال شود؛ هر رکورد بر اساس TTL مدت مشخصی معتبر میماند و بعد باید دوباره Resolve شود؛ این رفتار معمولاً مفید است، اما هنگام تغییر IP یک سرویس ممکن است تا پایان TTL پاسخ قبلی در Cache باقی بماند؛ در عیبیابی باید فرق بین خطای Cache و خطای Server بالادستی را تشخیص بدهی؛ اگر یک نام روی روتر پاسخ قدیمی میدهد، Cache را بررسی کن و ببین رکورد از نوع Dynamic است یا Static؛ پاک کردن Cache میتواند برای آزمایش مفید باشد، اما اگر علت اصلی یک Static Entry اشتباه یا DNS بالادستی نادرست باشد، مشکل دوباره برمیگردد؛ حجم Cache و زمان نگهداری نیز باید با نقش روتر متناسب باشد؛ برای پشتیبان مهم است بداند Cache یک لایه میانی است؛ بنابراین نتیجه DNSی که Client میبیند ممکن است محصول تنظیم Client، MikroTik و Resolver بالادستی به صورت همزمان باشد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در RouterOS هر تغییر باید با درک Packet Flow و جای Rule در مسیر انجام شود؛ Bridge، VLAN، IP، Routing، NAT و Firewall به هم مرتبطاند و تغییر در یکی میتواند اثر بخش دیگری را تغییر دهد؛ قبل از ویرایش، Export یا Backup متناسب، ثبت نسخه RouterOS و شناخت Interface مدیریتی کمک میکند خطر قطع دسترسی کمتر شود
DNS بالادستی باید قابل دسترسی باشد
DNS Server بالادستی باید هم از نظر Route و هم از نظر Firewall قابل دسترسی باشد؛ اگر MikroTik برای Query به یک DNS عمومی یا DNS سازمانی تنظیم شده اما Route رسیدن به آن وجود ندارد، درخواستها Timeout میشوند؛ اگر چند WAN یا Policy Routing داری، ممکن است Query از مسیری خارج شود که پاسخ آن به درستی برنمیگردد؛ همچنین DNS میتواند از UDP و در بعضی شرایط از TCP استفاده کند، بنابراین Ruleهای بیش از حد محدودکننده ممکن است بخشی از Queryها را مختل کنند؛ در عیبیابی از خود روتر نام را Resolve کن و همزمان Ping یا Route به DNS Server را بررسی کن؛ اگر DNS داخلی برای Domain استفاده میشود، نباید بدون بررسی آن را با DNS عمومی جایگزین کنی، چون نامهای داخلی دیگر شناخته نمیشوند؛ ترتیب و منبع DNSهای Static و Dynamic را هم ببین؛ DHCP Client ممکن است DNS تازهای وارد کرده باشد؛ یک پشتیبان خوب اول مشخص میکند «چه Resolverی باید پاسخ بدهد»، بعد مسیر رسیدن به آن را تست میکند و در آخر Cache و Client را بررسی میکند
فرض کن در Router MikroTik مشکلی گزارش شده و احتمال میدهی به DNS در MikroTik مربوط باشد. قبل از تغییر، وضعیت فعلی را با WinBox، Ping، Traceroute، Torch و Log بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمیگیرد
- Cache را با فضای ذخیرهسازی یا Cache مرورگر اشتباه نکن
- تغییر دادن تنظیمات مرتبط با DNS در MikroTik قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با DNS در MikroTik، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با WinBox، Ping، Traceroute، Torch و Log وضعیت مرتبط با DNS در MikroTik را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با DNS در MikroTik بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Router میتواند Resolver برای LAN باشد
- Allow Remote Requests باید محدود شود
- Static DNS برای نام داخلی ساده مفید است
- Cache پاسخها را نگه میدارد
- DNS بالادستی باید قابل دسترسی باشد
- قبل از تغییر گسترده در MikroTik، Export و Backup بگیر و برای کار Remote از Safe Mode استفاده کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Router میتواند Resolver برای LAN باشد. بعد بگو در عمل چطور آن را بررسی میکنی.
MikroTik میتواند Queryهای DNS کاربران LAN را Resolve یا Forward کند؛ اگر این نقش را میدهد باید Server بالادستی، Cache و دسترسی Clientها درست باشند
این نکته را با یک مثال توضیح بده: Allow Remote Requests باید محدود شود. بعد بگو در عمل چطور آن را بررسی میکنی.
Allow Remote Requests باعث میشود Router به Queryهای DNS دیگر Deviceها پاسخ دهد؛ آن را فقط برای شبکههای مورد اعتماد باز کن تا Resolver عمومی ناخواسته نسازی
این نکته را با یک مثال توضیح بده: Static DNS برای نام داخلی ساده مفید است. بعد بگو در عمل چطور آن را بررسی میکنی.
DNS نام را به اطلاعاتی مانند IP تبدیل میکند تا کاربر مجبور نباشد نشانی عددی سرویسها را حفظ کند؛ اگر IP مقصد کار میکند ولی نام نه، Query DNS را جداگانه آزمایش کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
