درس ۵ از ۱۲

عیب‌یابی حرفه‌ای DNS

این درس درباره عیب‌یابی حرفه‌ای DNS است؛ مسیر را مرحله‌به‌مرحله جلو می‌بریم: اول مفهوم، بعد مشاهده در سیستم واقعی و در آخر عیب‌یابی؛ وقتی درس تمام شد باید بتوانی با DNS Manager، nslookup، DHCP Console و ipconfig وضعیت این بخش را بررسی کنی و نتیجه را با حالت سالم مقایسه کنی در این درس موضوع را در چارچوب Windows Server و سرویس‌های سازمانی بررسی می‌کنیم؛ Server معمولاً به DNS، Time، Identity، Network و Storage وابسته است و تغییر در یک Role می‌تواند روی چند سرویس اثر بگذارد؛ هدف این است که پیش‌نیازها، وابستگی‌ها، روش بررسی سلامت و راه بازگشت را بشناسی و صرف موفق شدن یک Wizard را پایان کار ندانی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

nslookup یا Resolve-DnsName پاسخ را بررسی می‌کند

این ابزارها نشان می‌دهند Query از کدام DNS پاسخ گرفته و چه Recordی برگشته است؛ نام، نوع Record، Server پاسخ‌دهنده و خطای Timeout/NXDOMAIN را دقیق ثبت کن DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که در سرویس‌های نام‌گذاری و آدرس‌دهی، مستندسازی Scope، Exclusion، Reservation، Option، Zone و Recordهای مهم ضروری است؛ تغییر کوچک در Optionهای DHCP می‌تواند روی تعداد زیادی Client اثر بگذارد و خطای DNS در Domain می‌تواند Authentication و سرویس‌های وابسته را مختل کند؛ پس تغییرات باید کنترل‌شده و قابل بازگشت باشند

نام داخلی و اینترنتی را جدا تست کن

DNS داخلی ممکن است برای نام‌های سازمانی از Zone داخلی و برای اینترنت از Forwarder استفاده کند؛ یک نام داخلی و یک نام عمومی را جدا Query کن تا مشخص شود مشکل در Zone داخلی است یا مسیر Resolution بیرونی DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود

Cache می‌تواند پاسخ قدیمی نگه دارد

حافظه Cache داده‌ها و دستورهای پرتکرار را بسیار نزدیک پردازنده نگه می‌دارد تا نیاز به مراجعه به RAM کمتر شود؛ Cache معمولاً توسط سخت‌افزار و سیستم‌عامل مدیریت می‌شود و کارشناس پشتیبانی مستقیماً آن را تنظیم نمی‌کند Cache را با فضای ذخیره‌سازی یا Cache مرورگر اشتباه نکن DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود

Record و Zone و Resolver Client را جدا بررسی کن

برای DNS سه سطح را جدا کن: آیا Record درست است، آیا Zone آن را درست میزبانی می‌کند و آیا Resolver Client از Server صحیح سؤال می‌پرسد؛ مشکل هر سطح نشانه مشابه می‌دهد DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود

دسترسی با IP و عدم دسترسی با نام سرنخ مهمی است

اگر همان سرویس با IP باز می‌شود ولی با Hostname نه، مسیر شبکه احتمالاً تا مقصد برقرار است و DNS یا Name Resolution باید جدی‌تر بررسی شود؛ البته نرم‌افزار ممکن است به نام خاص حساس باشد نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص می‌کند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده می‌شود و همین موضوع تعیین می‌کند مقصد محلی است یا باید به Router فرستاده شود؛ در عیب‌یابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند

مثال محیط واقعی

فرض کن در DNS و DHCP سازمان مشکلی گزارش شده و احتمال می‌دهی به عیب‌یابی حرفه‌ای DNS مربوط باشد. قبل از تغییر، وضعیت فعلی را با DNS Manager، nslookup، DHCP Console و ipconfig بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • Cache را با فضای ذخیره‌سازی یا Cache مرورگر اشتباه نکن
  • تغییر دادن تنظیمات مرتبط با عیب‌یابی حرفه‌ای DNS قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
  • نتیجه‌گیری درباره عیب‌یابی حرفه‌ای DNS فقط از روی یک نشانه و بدون انجام تست نهایی
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با عیب‌یابی حرفه‌ای DNS، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با DNS Manager، nslookup، DHCP Console و ipconfig وضعیت مرتبط با عیب‌یابی حرفه‌ای DNS را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با عیب‌یابی حرفه‌ای DNS بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

نکته‌هایی که باید با خودت ببری

  • nslookup یا Resolve-DnsName پاسخ را بررسی می‌کند
  • نام داخلی و اینترنتی را جدا تست کن
  • Cache می‌تواند پاسخ قدیمی نگه دارد
  • Record و Zone و Resolver Client را جدا بررسی کن
  • دسترسی با IP و عدم دسترسی با نام سرنخ مهمی است
  • Record، Scope یا Option را بدون بررسی وابستگی‌ها حذف نکن
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

این نکته را با یک مثال توضیح بده: nslookup یا Resolve-DnsName پاسخ را بررسی می‌کند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

این ابزارها نشان می‌دهند Query از کدام DNS پاسخ گرفته و چه Recordی برگشته است. نام، نوع Record، Server پاسخ‌دهنده و خطای Timeout/NXDOMAIN را دقیق ثبت کن

چرا باید نام داخلی و اینترنتی را جدا تست کنی و از کجا می‌فهمی نتیجه درست است؟

DNS داخلی ممکن است برای نام‌های سازمانی از Zone داخلی و برای اینترنت از Forwarder استفاده کند. یک نام داخلی و یک نام عمومی را جدا Query کن تا مشخص شود مشکل در Zone داخلی است یا مسیر Resolution بیرونی

این نکته را با یک مثال توضیح بده: Cache می‌تواند پاسخ قدیمی نگه دارد. بعد بگو در عمل چطور آن را بررسی می‌کنی.

حافظه Cache داده‌ها و دستورهای پرتکرار را بسیار نزدیک پردازنده نگه می‌دارد تا نیاز به مراجعه به RAM کمتر شود؛ Cache معمولاً توسط سخت‌افزار و سیستم‌عامل مدیریت می‌شود و کارشناس پشتیبانی مستقیماً آن را تنظیم نمی‌کند

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی