تصویر کلی
Unbound برای Recursive و Caching Resolution طراحی شده و می‌تواند Trust Anchorهای DNSSEC را اعتبارسنجی کند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Resolver باید پاسخ را از زنجیره DNS جمع‌آوری کند یا طبق تنظیم به Forwarder بدهد؛ این با Authoritative Server که مالک Zone است متفاوت است.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
Cache TTL، Serve Stale، Access Control و Root Trust Anchor باید با نیاز شبکه تنظیم شوند؛ عملکرد سالم با dig و آمار Resolver قابل سنجش است.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی NLnet Labs نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
پرس‌وجوی کاربر چه مسیری طی می‌کند؟
وقتی برنامه نام یک میزبان را می‌خواهد، معمولاً درخواست به حل‌کننده پیکربندی‌شده در سیستم می‌رسد. Unbound می‌تواند پاسخ معتبر موجود در کش را برگرداند یا برای یافتن پاسخ از مسیر بازگشتی استفاده کند. در حالت ارسال به حل‌کننده بالادستی، بخشی از این کار به مقصد دیگری سپرده می‌شود. انتخاب میان بازگشت مستقیم و ارسال بالادستی، مسیر شبکه، مرز اعتماد و شیوه عیب‌یابی را تغییر می‌دهد. این دو حالت را در مستند محیط صریح بنویسید تا تیم فرض‌های متناقض نداشته باشد.
حل‌کننده بازگشتی مالک همه نام‌هایی که پاسخ می‌دهد نیست. سرور مقتدر برای یک ناحیه، داده آن ناحیه را ارائه می‌کند؛ حل‌کننده پاسخ را برای کاربر پیدا و نگهداری می‌کند. اگر یک رکورد در سرور مقتدر اشتباه باشد، پاک کردن کش تنها باعث می‌شود پاسخ اشتباه دوباره دریافت شود. برای تشخیص، پاسخ کش‌شده و پاسخ منبع مقتدر را با توجه به مسیر و زمان مقایسه کنید. تغییر تصادفی تنظیم حل‌کننده همیشه محل واقعی خطا را اصلاح نمی‌کند.
کش و TTL به زبان کاربردی
زمان ماندگاری پاسخ تعیین می‌کند داده تا چه مدت می‌تواند در کش معتبر فرض شود. پاسخ سریع از کش با پاسخ تازه از شبکه از نظر هزینه و زمان متفاوت است، اما هر دو می‌توانند صحیح باشند. هنگام تغییر رکورد، کاربران مختلف ممکن است تا پایان اعتبار کش خود پاسخ قبلی را ببینند. این رفتار را نباید فوراً به انتشار ناقص یا خرابی سرور نسبت داد. زمان دریافت، TTL باقی‌مانده و مسیر حل نام را ثبت کنید تا انتظار واقع‌بینانه شکل بگیرد.
کش فقط برای پاسخ‌های موفق نیست؛ نبود نام یا نبود نوع رکورد نیز می‌تواند بر اساس قواعد مربوط نگهداری شود. بنابراین ایجاد رکورد تازه پس از یک پرس‌وجوی ناموفق ممکن است فوراً برای همه مصرف‌کنندگان دیده نشود. در آزمایش، یک نام اختصاصی ایجاد کنید و قبل و بعد از افزودن رکورد، پاسخ و زمان اعتبار را بررسی کنید. از نام واقعی سرویس حیاتی برای تمرین استفاده نکنید تا تغییر کش باعث اختلال ناخواسته کاربران نشود.
DNSSEC چه چیزی را اعتبارسنجی می‌کند؟
DNSSEC به اعتبارسنجی منشأ و تمامیت داده امضاشده در زنجیره اعتماد کمک می‌کند؛ این قابلیت با رمزگذاری محتوای پرس‌وجو یکسان نیست. اگر ارتباط معمول DNS استفاده شود، وجود امضا به تنهایی نام پرسیده‌شده را از دید مسیر شبکه پنهان نمی‌کند. همچنین همه ناحیه‌ها وضعیت امضای یکسان ندارند. نتیجه اعتبارسنجی را باید با وضعیت زنجیره اعتماد تفسیر کرد و نبود امضا را با امضای نامعتبر یکسان ندانست.
وقتی داده‌ای که باید معتبر باشد در اعتبارسنجی شکست می‌خورد، پاسخ ناموفق می‌تواند رفتار حفاظتی درست باشد. خاموش کردن اعتبارسنجی برای همه نام‌ها تنها نشانه را حذف می‌کند و تضمین امنیتی را عوض می‌کند. ابتدا ساعت سیستم، وضعیت لنگر اعتماد، ارتباط شبکه و امضاهای ناحیه مورد نظر را بررسی کنید. اگر مشکل فقط یک دامنه است، دامنه بررسی را همان‌جا نگه دارید و از تغییر سراسری بدون شواهد پرهیز کنید.
زمان و لنگر اعتماد بخشی از سرویس‌اند
اعتبار زمانی امضاها باعث می‌شود ساعت نادرست به خطاهای ظاهراً نامرتبط در حل نام منجر شود. ماشین تازه نصب‌شده یا بازیابی‌شده باید زمان درست داشته باشد. همچنین داده مربوط به لنگر اعتماد و سازوکار نگهداری آن باید در مسیر قابل نوشتن و با مجوز مناسب قرار گیرد. بالا آمدن فرایند بدون توان به‌روزرسانی وضعیت لازم، ممکن است مشکل را به آینده منتقل کند و تشخیص آن را دشوارتر سازد.
برای آزمون بازیابی، فقط فایل پیکربندی را برنگردانید؛ فایل‌ها و وضعیت لازم برای اعتبارسنجی را نیز مطابق مستندات نسخه در نظر بگیرید. پس از بازگردانی، یک نام معتبر امضاشده، یک نام عادی و یک مورد آزمایشی نامعتبر شناخته‌شده را در محیط مجاز بررسی کنید. نتیجه باید نشان دهد هم مسیر موفق کار می‌کند و هم داده نامعتبر به شکل مورد انتظار رد می‌شود. این جفت آزمون از سبز شدن صرف یک پرس‌وجوی معمول ارزش بیشتری دارد.
کنترل دسترسی و خطر حل‌کننده باز
سرویسی که برای شبکه داخلی طراحی شده نباید بی‌دلیل به همه اینترنت پاسخ بازگشتی بدهد. نشانی‌های شنونده و کنترل دسترسی باید با شبکه‌های مجاز هماهنگ شوند. بررسی تنها فایروال کافی نیست، زیرا تغییر شبکه یا انتشار پورت ممکن است مرز بیرونی را عوض کند. محدودیت در خود سرویس و شبکه باید مکمل هم باشند. آزمون را از یک مبدأ مجاز و یک مبدأ خارج از دامنه انجام دهید و نتیجه را ثبت کنید.
اگر شبکه چند بخش دارد، مشخص کنید کدام بخش باید به کدام حل‌کننده برسد. برنامه‌های داخلی ممکن است نام‌های خصوصی داشته باشند که نباید به مسیر عمومی ارسال شوند. برای چنین نام‌هایی، سیاست ارسال یا داده محلی باید روشن و محدود باشد. اشتباه در قاعده دامنه می‌تواند پرس‌وجوهای زیادی را به مقصد نامناسب ببرد. نمونه نام داخل دامنه، زیرنام و نام مشابه خارج از دامنه را جدا امتحان کنید تا مرز قاعده دقیق باشد.
UDP، TCP و اندازه پاسخ
DNS تنها به یک بسته کوچک UDP محدود نیست. پاسخ بزرگ، رفتار تجهیزات میانی و نیاز به ادامه ارتباط می‌تواند استفاده از TCP را ضروری کند. اگر بعضی نام‌ها کار می‌کنند و بعضی نه، مسیر هر دو نوع ارتباط و محدودیت اندازه را بررسی کنید. باز بودن UDP در فایروال به تنهایی اثبات نمی‌کند مسیر کامل حل نام سالم است. خطای وابسته به پاسخ بزرگ را نباید با افزایش بی‌هدف زمان انتظار پنهان کرد.
در بررسی شبکه، بسته‌های پرس‌وجو و پاسخ را با زمان یکسان مقایسه کنید و ببینید کدام طرف پاسخی دریافت نکرده است. ممکن است درخواست از حل‌کننده خارج شود ولی پاسخ در مسیر بازگشت حذف شود. همچنین IPv4 و IPv6 می‌توانند مسیرهای متفاوت داشته باشند. آزمایش کنترل‌شده هر خانواده آدرس کمک می‌کند مشکل مسیر از مشکل داده DNS جدا شود. نتیجه را به محیط و مسیر واقعی محدود کنید و از تعمیم یک آزمون به همه مقصدها پرهیز کنید.
Serve stale و مصالحه دسترس‌پذیری
ارائه پاسخ قدیمی در شرایط خاص می‌تواند هنگام مشکل موقت بالادست به دسترس‌پذیری کمک کند، اما پاسخ قدیمی همان پاسخ تازه نیست. اگر نشانی سرویس تغییر کرده یا مقصد قبلی حذف شده باشد، این انتخاب می‌تواند اثر متفاوتی داشته باشد. تنظیم چنین قابلیتی باید با نوع سرویس‌ها، مدت قابل قبول کهنگی و روش پایش هماهنگ باشد. فعال کردن آن بدون دانستن اینکه چه زمانی استفاده می‌شود، تحلیل حادثه را مبهم می‌کند.
برای آزمایش، یک نام کنترل‌شده با پاسخ شناخته‌شده داشته باشید و پس از پر شدن کش، دسترسی بالادستی را در محیط جدا مختل کنید. رفتار پاسخ و مدت ادامه آن را ثبت کنید. سپس بالادست را بازگردانید و زمان تازه شدن داده را ببینید. این تمرین نشان می‌دهد قابلیت برای سناریوی شما چه سود و چه محدودیتی دارد. از تغییر رکوردهای تولیدی برای چنین آزمایشی استفاده نکنید و نتیجه را با نسخه و تنظیمات دقیق نگه دارید.
پایش و حریم داده پرس‌وجو
نرخ پرس‌وجو، سهم پاسخ کش، خطاهای اعتبارسنجی و زمان پاسخ در کنار هم مفیدند. افزایش سهم کش لزوماً نشانه بهبود نیست اگر هم‌زمان تعداد پرس‌وجوهای کاربران افت کرده باشد. همچنین ثبت کامل نام‌ها می‌تواند اطلاعات حساسی درباره فعالیت کاربران و سامانه‌ها آشکار کند. برای پایش عادی، آمار تجمیعی را ترجیح دهید و جمع‌آوری جزئی را به مسئله و بازه مشخص محدود کنید. دسترسی و مدت نگهداری گزارش‌ها باید متناسب با حساسیت آنها باشد.
یک runbook خوب از نشانه آغاز می‌کند: همه نام‌ها شکست می‌خورند، فقط یک دامنه شکست می‌خورد یا پاسخ‌ها کند شده‌اند. برای هر نشانه، ترتیب بررسی ساعت، شبکه، کش، اعتبارسنجی و بالادست را مشخص کنید. پس از اصلاح، همان پرس‌وجوی اولیه و یک نمونه شاهد سالم را دوباره اجرا کنید. به این ترتیب می‌توان نشان داد مشکل رفع شده و تغییر، مسیرهای سالم را خراب نکرده است؛ این معیار از شروع دوباره موفق فرایند دقیق‌تر است.
