‏DNS برای آدم‌هاست، نه برای زیرساخت داخلی

این مقاله با یه ایده ساده شروع می‌کنه: DNS برای این وجود داره که آدم‌ها نمی‌تونن آدرس‌های IP رو راحت حفظ کنن و اسم دامنه خیلی راحت‌تره. نویسنده می‌گه برای وب‌سایت‌ها و APIهای عمومی که آدم‌ها باهاشون سر و کار دارن، استفاده از DNS کاملاً منطقیه؛ مزیت اضافه‌ش هم اینه که IP می‌تونه عوض بشه بدون اینکه کلاینت به مشکل بخوره. ولی نویسنده این رو زیر سؤال می‌بره که آیا باید برای زیرساخت داخلی IT (چه ابری چه On-prem) هم از DNS استفاده کنیم.

استدلال اصلی نویسنده درباره قابلیت اطمینانه. هر قطعه‌ای که به سیستم اضافه می‌کنی، یه ریسک شکست تازه می‌سازه و ممکنه رفتارها و وابستگی‌های پیش‌بینی‌نشده (مثل وابستگی‌های دایره‌ای) درست کنه. نویسنده به اون هایکوی معروف دنیای sysadmin اشاره می‌کنه که حال و هوای کار با DNS رو خوب نشون می‌ده:

It's not DNS
There's no way it's DNS
It was DNS

نویسنده می‌گه تو حادثه‌های بزرگی مثل قطعی فیسبوک/متا، ریشه مشکل خودِ DNS نبوده، ولی چون DNS تو مسیر بحرانی تقریباً همه سرویس‌ها قرار داره، شعاع تخریبش (blast radius) خیلی بزرگ می‌شه. تو مورد متا، وابستگی دایره‌ای به DNS باعث شد آدم‌ها حتی از در ساختمون هم نتونن رد بشن.

یه ایراد عملیاتی دیگه اینه که کلاینت‌های DNS رکوردها رو بر اساس TTL کش می‌کنن و رفتار پیاده‌سازی‌های مختلف فرق داره؛ برای همین مطمئن‌شدن از اینکه همه سرورها IP جدید رو گرفتن سخته. به گفته نویسنده، برای ارتباط ماشین به ماشین اصلاً لازم نیست DNS داشته باشیم. می‌شه IP درست رو مستقیم با ابزارهایی مثل Ansible یا pyinfra تو فایل‌های کانفیگ تزریق کرد، یا اگه دوست داری با اسم دامنه کار کنی، از همون /etc/hosts استفاده کنی که هم provision کردنش راحته و هم پاسخگوییش سریعه؛ این‌طوری بدون سرویس DNS وانمود می‌کنی داری از DNS استفاده می‌کنی.

نویسنده بُعد امنیتی رو هم پررنگ می‌کنه. امروز بیشتر ترافیک شبکه به‌صورت پیش‌فرض رمزگذاری شده، ولی DNS استثناست و رمزگذاری‌نشده‌ست؛ حمله و جعل بسته (spoofing) روش می‌تونه خیلی مخرب باشه. راه‌حلی مثل DNSSEC هم خودش یه لایه پیچیدگی و بار مدیریتی تازه با ریسک پیکربندی غلط اضافه می‌کنه.

مهم‌ترین ریسک امنیتی که نویسنده مطرح می‌کنه، استفاده از DNS برای خروج داده (Exfiltration) هست. چون فیلتر کردن ترافیک خروجی (Egress filtering) دردسر داره، خیلی وقت‌ها انجام نمی‌شه. در نتیجه یه مهاجم می‌تونه از طریق کوئری‌های DNS به یه دامنه‌ای که خودش کنترلش می‌کنه، داده‌های حساس رو از سیستم هک‌شده بیرون بکشه؛ این کوئری‌ها از سرور DNS داخلی عبور می‌کنن و به nameserver معتبر مهاجم می‌رسن و اون داده‌ها رو از لاگ سرور خودش درمیاره. نویسنده می‌گه ابزارهایی مثل dnscat2 و iodine دقیقاً همین کارو می‌کنن و توصیه‌ش اینه که حداقل اجازه کوئری مستقیم به رکوردهای عمومی DNS رو به سیستم‌ها ندیم و دسترسی لازم به اینترنت رو از طریق یه پروکسی با لیست دامنه‌های مجاز بدیم.

نویسنده تو جمع‌بندی تأکید می‌کنه که همه‌چیز یه trade-off هست و باید با توجه به زمینه، اشتهای ریسک و حتی فرهنگ سازمانی تصمیم گرفت؛ ولی به نظرش معقوله که آدم بررسی کنه آیا می‌شه DNS رو کلاً از زیرساخت داخلی حذف کرد تا قابلیت اطمینان و استحکام بالاتر بره.

نکات کلیدی:

• DNS برای سرویس‌های عمومی منطقیه ولی برای زیرساخت داخلی یه قطعه اضافه و نقطه شکست بالقوه‌ست
• شعاع تخریب DNS خیلی بزرگه؛ تو قطعی متا وابستگی دایره‌ای حتی دسترسی فیزیکی رو هم قفل کرد
• به‌جای DNS داخلی می‌شه IP رو مستقیم تو کانفیگ یا تو /etc/hosts گذاشت
• DNS به‌صورت پیش‌فرض رمزگذاری‌نشده‌ست و DNSSEC هم خودش پیچیدگی و بار مدیریتی اضافه می‌کنه
• نبود Egress filtering باعث می‌شه DNS به یه مسیر خروج داده برای مهاجم تبدیل بشه