آیا تنظیم DNS در اینترنت دوپاره ایران کار می کند؟

در ماههای اخیر، با افزایش اختلالات ارتباطی میان شبکه داخلی ایران و اینترنت بین‌الملل با شروع جنگ و محدودیتهای داخلی، بسیاری از مدیران سرور و صاحبان وب‌سایت‌ها با مسئله‌ای روبه‌رو شده‌اند که در معماری کلاسیک اینترنت کمتر مورد توجه قرار می‌گرفت: «دوپاره شدن شبکه» یا Network Fragmentation.

در چنین شرایطی، دیگر نمی‌توان فرض کرد که تمامی کاربران، DNS Serverها، سرویس‌های اعتبارسنجی SSL و زیرساخت‌های جهانی اینترنت، به‌صورت متقابل و پایدار به همه سرورها دسترسی دارند. نتیجه این وضعیت، بروز مشکلاتی در Resolve شدن دامنه‌ها، صدور و تمدید گواهینامه‌های SSL، دسترسی کاربران داخل و خارج کشور به سرویس‌ها و حتی عملکرد صحیح Name Serverها است.

این مقاله به بررسی جامع این مسئله، رفتار واقعی DNS در چنین شرایطی، معماری‌های قابل پیاده‌سازی و راهکارهای عملی برای حفظ پایداری سرویس‌ها می‌پردازد.

سامانه DNS بر این فرض طراحی شده است که:

• تمامی Authoritative Name Serverها از سراسر اینترنت قابل دسترس هستند.
• ارتباط میان Resolverها و Name Serverها پایدار است.
• تاخیر شبکه محدود و قابل پیش‌بینی است.
• مسیرهای ارتباطی بین‌المللی پایدار هستند.

در حالت عادی، زمانی که کاربری دامنه‌ای را درخواست می‌کند، Resolver سیستم او فهرست Name Serverهای دامنه را دریافت کرده و به یکی از آن‌ها متصل می‌شود. اگر یکی از Name Serverها پاسخ ندهد، Resolver معمولاً Name Server بعدی را امتحان می‌کند.

اما در شرایط اختلالات شبکه‌ای، این فرض‌ها دیگر معتبر نیستند.

مفهوم Network Fragmentation

در وضعیت Fragmentation، شبکه عملاً به دو بخش تبدیل می‌شود:

• کاربران و سرورهای داخل کشور
• کاربران و سرورهای خارج کشور

در چنین حالتی ممکن است:

• کاربران داخلی به سرورهای خارجی دسترسی نداشته باشند.
• کاربران خارجی نتوانند به سرورهای داخلی متصل شوند.
• Name Serverهای داخلی از خارج قابل Resolve نباشند.
• ارتباط میان DNSهای داخلی و خارجی ناپایدار یا غیرممکن شود.

این وضعیت باعث می‌شود معماری‌های رایج DNS دیگر رفتار قابل پیش‌بینی نداشته باشند.

رفتار واقعی Resolverها در حضور چند Name Server

بسیاری تصور می‌کنند اگر چند NS برای دامنه تعریف شود، Resolver بر اساس موقعیت جغرافیایی بهترین Name Server را انتخاب می‌کند. اما در عمل چنین نیست.

Resolver معمولاً:

1. فهرست NSها را دریافت می‌کند.
2. یکی از آن‌ها را انتخاب می‌کند.
3. در صورت Timeout یا Failure به سراغ NS بعدی می‌رود.

نکته مهم این است که انتخاب اولیه همیشه قابل پیش‌بینی نیست. برخی Resolverها:

• اولین NS را ترجیح می‌دهند.
• NS موفق قبلی را Cache می‌کنند.
• رفتار تصادفی دارند.
• ترتیب NSها را تغییر می‌دهند.

بنابراین صرف قرار دادن Name Serverهای داخلی و خارجی در کنار یکدیگر، تضمین نمی‌کند که کاربران داخلی به DNS داخلی و کاربران خارجی به DNS خارجی هدایت شوند.

معماری رایج در شرایط اختلال شبکه

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

برای مثال:

• دو Name Server در ایران
• دو Name Server در خارج کشور

در این مدل، انتظار می‌رود:

• Resolverهای داخلی به NSهای داخلی دسترسی پیدا کنند.
• Resolverهای خارجی به NSهای خارجی متصل شوند.

در عمل این روش تا حدی کار می‌کند، اما یک معماری قطعی و استاندارد محسوب نمی‌شود، زیرا رفتار Resolverها تضمین‌شده نیست.

مشکل اصلی: Timeout و تاخیر در Resolve

وقتی Resolver ابتدا NS غیرقابل دسترس را انتخاب کند، چند ثانیه Timeout رخ می‌دهد و سپس Resolver سراغ NS بعدی می‌رود.

نتایج این وضعیت:

• افزایش زمان Resolve
• تاخیر در بارگذاری سایت
• Failureهای موقت
• رفتار ناپایدار در برخی ISPها

خواهد بود.

تفاوت GeoDNS با معماری چند NS

GeoDNS سامانه‌ای است که بر اساس موقعیت جغرافیایی درخواست‌کننده، IP متفاوتی بازمی‌گرداند.

برای مثال:

• کاربران داخلی → IP سرور ایران
• کاربران خارجی → IP سرور خارج

اما در شرایط Fragmentation، GeoDNS نیز ممکن است با مشکل مواجه شود، زیرا:

• Resolverها همیشه IP واقعی کاربر را منتقل نمی‌کنند.
• برخی کاربران از DNSهای خارجی استفاده می‌کنند.
• برخی DNSهای خارجی از داخل کشور در دسترس نیستند.

بنابراین GeoDNS به‌تنهایی راه‌حل قطعی این مسئله نیست.

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

در چنین شرایطی، معماری DNS باید با درنظر گرفتن محدودیت‌های واقعی شبکه طراحی شود.

مهم‌ترین اصول عبارت‌اند از:

1. جداسازی زیرساخت داخلی و خارجی

بهتر است:

• سرور داخلی مستقل باشد.
• سرور خارجی مستقل باشد.
• هرکدام قابلیت سرویس‌دهی مستقل داشته باشند.

2. کاهش وابستگی به سرویس‌های واسط خارجی

در شرایط اختلال، استفاده از CDNها یا سرویس‌های خارجی ممکن است باعث عدم دسترسی کاربران داخلی شود.

بنابراین باید معماری به‌گونه‌ای طراحی شود که حتی بدون دسترسی به سرویس‌های واسط نیز قابل استفاده باشد.

3. TTL پایین

برای رکوردهای DNS بهتر است TTL پایین تنظیم شود، مثلاً:

• 60 ثانیه
• 120 ثانیه

این کار باعث می‌شود تغییرات سریع‌تر منتشر شوند و Cacheهای قدیمی کمتر مشکل ایجاد کنند.

4. حفظ استقلال سرویس‌دهی

هر سرور باید بتواند مستقل عمل کند:

• وب‌سرور
• DNS
• SSL
• پایگاه داده

نباید به‌گونه‌ای طراحی شود که اختلال در یک سمت، سمت دیگر را نیز از کار بیندازد.

چالش SSL در شرایط اختلال شبکه

یکی از مهم‌ترین مشکلات، صدور و تمدید گواهینامه‌های SSL است.

سرویس‌های ACME برای اعتبارسنجی دامنه باید:

1. DNS دامنه را Resolve کنند.
2. به سرور متصل شوند.
3. Challenge را بررسی کنند.

اگر Name Serverهای داخلی از خارج قابل دسترس نباشند، فرآیند اعتبارسنجی شکست می‌خورد، حتی اگر سایت برای کاربران داخلی کاملاً در دسترس باشد.

علت خطاهای رایج ACME

خطاهایی مانند:

• DNS query timeout
• NXDOMAIN
• Authorization invalid

اغلب ناشی از این هستند که:

• Authoritative DNS از خارج قابل دسترس نیست.
• رکوردهای DNS به‌درستی Resolve نمی‌شوند.
• ارتباط بین‌المللی سرور محدود شده است.

راهکار مناسب برای SSL

در چنین معماری‌هایی، بهترین راهکار معمولاً این است که:

• صدور و تمدید SSL روی سرور خارجی انجام شود.
• گواهینامه به سرور داخلی منتقل شود.
• یا از DNSهای globally reachable استفاده شود.

همچنین بهتر است:

• گواهینامه‌ها قابل Export باشند.
• از وابستگی کامل به Certificate Store سیستم‌عامل اجتناب شود.

اهمیت Authoritative DNS قابل دسترس جهانی

حتی اگر وب‌سایت داخلی باشد، DNS دامنه باید تا حد ممکن از خارج قابل دسترس باقی بماند، زیرا بسیاری از سرویس‌های اینترنتی برای اعتبارسنجی و Resolve دامنه به آن وابسته‌اند.

عدم دسترسی جهانی به DNS ممکن است باعث اختلال در:

• SSL
• ایمیل
• سرویس‌های مانیتورینگ
• موتورهای جستجو
• APIهای خارجی

شود.

جمع‌بندی

در شرایط اختلال میان شبکه داخلی و اینترنت جهانی، معماری سنتی DNS دیگر پاسخ‌گوی نیازها نیست. در چنین وضعیتی باید واقعیت‌های شبکه را پذیرفت و معماری را بر اساس محدودیت‌های عملی طراحی کرد.

استفاده هم‌زمان از Name Serverهای داخلی و خارجی می‌تواند تا حدی مؤثر باشد، اما تضمینی برای رفتار پایدار Resolverها ایجاد نمی‌کند. همچنین سرویس‌هایی مانند ACME و SSL به دسترسی جهانی DNS وابسته‌اند و در صورت عدم دسترسی Name Serverها از خارج، فرآیند اعتبارسنجی شکست خواهد خورد.

راهکار مناسب در این شرایط، طراحی زیرساختی مستقل، انعطاف‌پذیر و کم‌وابسته به مسیرهای بین‌المللی است؛ زیرساختی که بتواند حتی در صورت Fragmentation شبکه، برای کاربران داخل و خارج کشور به‌صورت مستقل سرویس‌دهی کند.