چرا اشتباهات رایج در تنظیم DNS این‌قدر خطرناک است؟

سال‌ها پیش، در یک پروژه‌ی فروشگاهی، یک باگ عجیب دیدم: بخشی از کاربران، صفحه‌ی محصول را درست می‌دیدند و بخشی دیگر، نسخه‌ی چند ساعت قبل را. تیم فنی ابتدا سراغ کش رفت و به نتیجه نرسید. وقتی رکوردهای DNS را با دقت بررسی کردیم، معلوم شد دو رکورد A برای یک نام وجود دارد: یکی به IP قدیمی و یکی به IP جدید. پروژه‌ی مهاجرت نیمه‌کاره مانده بود و TTL بالای رکورد قدیمی، باعث می‌شد بعضی Resolverها نسخه‌ی قدیمی را ببینند. آن روز یاد گرفتم که اکثر بحران‌های DNS، از اشتباهات کوچکی می‌آیند که در لحظه ساده به نظر می‌رسند. این مقاله، فهرست دقیق همان اشتباهات و راه پیشگیری از هرکدام است.

اگر با مفاهیم پایه‌ی DNS آشنا نیستید، پیش از ادامه DNS چیست و چگونه کار می‌کند را بخوانید و برای درک اثر تغییرات، تغییر DNS چه تاثیری بر سایت و رتبه Google دارد را ببینید.

۱. تنظیم TTL نامناسب

TTL (Time To Live) در تنظیمات DNS، دو نقش متضاد دارد: TTL بالا یعنی ترافیک کوئری کمتر به سرور Authoritative و کش طولانی‌تر، اما هر تغییر کندتر منتشر می‌شود. TTL پایین عکس این است. اشتباه رایج، انتخاب یک مقدار ثابت برای همه‌ی رکوردها بدون توجه به نقش آن‌هاست.

راهکار عملی من: برای رکوردهای پایدار مثل MX و TXT، TTL بالا (۸۶۴۰۰ ثانیه یا یک روز) مناسب است. برای رکوردهای A و CNAME که ممکن است تغییر کنند، TTL ۳۶۰۰ ثانیه یا کمتر منطقی‌تر است. اگر در حال برنامه‌ریزی یک مهاجرت هستید، پیش از تغییر، TTL را به ۳۰۰ ثانیه کاهش دهید و پس از تثبیت، به مقدار اصلی برگردانید. جزئیات این مکانیزم را در پروپاگیشن DNS چیست و چقدر طول می‌کشد آورده‌ام.

۲. اشتباه تایپی در مقدار رکورد

یک اشتباه کوچک در IP یا نام دامنه، سایت را از کار می‌اندازد. رایج‌ترین موارد:

• تایپ IP با یک رقم اشتباه که به سرور نامرتبط اشاره می‌کند.
• جا انداختن نقطه‌ی پایانی (Trailing Dot) در برخی رکوردهای CNAME و MX که باعث می‌شود سیستم آن را نسبی تفسیر کند.
• استفاده از فاصله یا کاراکتر نامعتبر در رکورد TXT که در برخی ارائه‌دهندگان خطا می‌دهد.

پیش از ذخیره‌ی هر رکورد، یک بار با چشم آن را بازبینی کنید و اگر ابزار ارائه‌دهنده اجازه می‌دهد، از Validate استفاده کنید. برای عیب‌یابی سریع پس از هر تغییر، چگونه DNS را عیب‌یابی کنیم را ببینید.

۳. فراموش کردن رکوردهای حیاتی

هرگاه Nameserver را تغییر می‌دهید، باید تمام رکوردها به سرویس جدید منتقل شوند. رکوردهایی که معمولاً فراموش می‌شوند:

1. رکوردهای MX و SPF و DKIM و DMARC برای ایمیل سازمانی.
2. رکوردهای TXT تأیید سرویس‌های شخص ثالث (Google، Microsoft، Facebook و…).
3. رکوردهای CNAME برای سرویس‌های SaaS.
4. رکوردهای زیرساختی مثل TXT برای DMARC و رکوردهای مرتبط با CDN.
5. رکوردهای سطح سرویس مثل رکوردهای تأیید SSL و رکوردهای ACME Challenge.

قاعده‌ی من: پیش از تغییر Nameserver، همیشه یک Export کامل از Zone File بگیرید و آن را مبنای کار قرار دهید. برای شناخت انواع رکوردها، رکوردهای DNS کدامند راهنمای دقیقی است.

۴. رکوردهای یتیم و بدون مالک

در پروژه‌های قدیمی، رکوردهایی وجود دارند که سال‌ها پیش اضافه شده‌اند و کسی نمی‌داند چرا. رکوردی که به سرور از رده خارج اشاره می‌کند، یا رکوردی که برای تست یک سرویس اضافه شده و باقی مانده. این رکوردها سه ریسک دارند: تأخیر در پروپاگیشن، سطح حمله‌ی بزرگ‌تر (چون هر رکورد یک نام است که به IP اشاره می‌کند)، و گیجی در عیب‌یابی.

پیشنهاد من: حداقل یک بار در سال، Zone File را کامل بازبینی کنید و هر رکوردی را که نمی‌توانید هدفش را توجیه کنید، حذف کنید. اگر مطمئن نیستید، ابتدا TTL آن را بالا ببرید و در بازه‌ای چند هفته‌ای ترافیک آن را پایش کنید.

۵. استفاده‌ی نادرست از CNAME

دو اشتباه رایج در CNAME:

• CNAME برای دامنه‌ی ریشه: استاندارد DNS اجازه نمی‌دهد دامنه‌ی ریشه (example.com) CNAME داشته باشد. اگر ارائه‌دهنده اجازه دهد، رفتار مرورگرها غیرقابل پیش‌بینی می‌شود. راه‌حل: از ALIAS یا ANAME رکورد (که بعضی سرویس‌ها ارائه می‌دهند) استفاده کنید.
• زنجیره‌ی طولانی CNAME: اگر یک CNAME به CNAME دیگری اشاره کند و زنجیره طولانی شود، زمان حل شدن افزایش می‌یابد و در مواردی loop ایجاد می‌شود. تا حد ممکن زنجیره را کوتاه نگه دارید.

۶. ناسازگاری Nameserver و رکوردها

پس از تغییر Nameserver، حتماً باید مطمئن شوید که رکوردها در سرورهای Authoritative جدید کامل ثبت شده‌اند. اگر تنها یکی از چند Nameserver معرفی‌شده به سرویس جدید اشاره کند و بقیه به سرویس قدیمی، کاربران بسته به Resolverشان، پاسخ‌های متفاوت می‌گیرند.

قاعده: یا همه‌ی Nameserverها به یک سرویس مشخص اشاره کنند، یا اگر در حال مهاجرت هستید، این کار را به‌صورت مرحله‌ای و با پایش دقیق انجام دهید. برای درک تفاوت مفاهیم، تفاوت DNS و Nameserver چیست را بخوانید.

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

۷. فعال‌سازی DNSSEC بدون آماده‌سازی

DNSSEC (Domain Name System Security Extensions) امنیت DNS را تقویت می‌کند، اما اگر اشتباه فعال شود، می‌تواند سایت را کامل از دسترس خارج کند. اشتباهات رایج:

• فعال‌سازی DNSSEC بدون هماهنگی با Registrar.
• فراموش کردن تنظیم DS Record در Registrar پس از فعال‌سازی در سرویس DNS.
• چرخش کلید (Key Rollover) بدون برنامه‌ی دقیق.

پیش از فعال‌سازی DNSSEC، ابتدا محیط را در یک دامنه‌ی تستی تمرین کنید. اگر سرویس DNS شما DNSSEC را اتوماتیک مدیریت می‌کند، مطمئن شوید که Registrar هم این را می‌داند. برای اصول امنیت DNS، DNS امن چیست و چه مزایایی دارد را ببینید.

۸. مسائل امنیتی در پیکربندی DNS

پیکربندی DNS، سطح حمله‌ی گسترده‌ای دارد. سه اشتباه امنیتی رایج:

• Zone Transfer باز (AXFR): اجازه دادن به هر کسی برای دریافت کامل لیست رکوردها. این کار اطلاعات زیادی درباره‌ی زیرساخت شما لو می‌دهد. راه‌حل: محدودسازی AXFR به IPهای مشخص یا غیرفعال کردن کامل.
• DNS Caching Poisoning: اگر Resolver شما ضعیف باشد، مهاجم می‌تواند پاسخ‌های نادرست را در Cache آن تزریق کند. راه‌حل: استفاده از Resolverهای امن با DNSSEC.
• عدم استفاده از DNSSEC: هرچند پیچیده است، اما DNSSEC جلوی بسیاری از حملات Spoofing را می‌گیرد.

در حالت کلی، امنیت DNS به‌همان اندازه‌ی امنیت سرور مهم است و در پروژه‌های حساس، از ابتدا باید بخشی از استراتژی امنیتی باشد. برای چارچوب کلی، امنیت وب چیست و چه اصولی دارد را ببینید.

۹. تنظیم نادرست GeoDNS و Load Balancing

GeoDNS و Latency-Based Routing می‌توانند تجربه‌ی کاربران مختلف را به‌طور معناداری بهتر کنند، اما پیکربندی نادرست آن‌ها مشکلات پیچیده‌ای می‌سازد:

• عدم Fallback: اگر پاسخ GeoDNS برای یک منطقه خالی باشد، کاربر به هیچ سروری نمی‌رسد.
• تست ناکافی: GeoDNS را باید از چند نقطه‌ی جغرافیایی تست کرد، نه فقط از یک نقطه.
• عدم هماهنگی با Health Check: اگر Health Check سروری را سالم اعلام کند اما آن سرور در واقع مشکل داشته باشد، کاربران به سرور خراب هدایت می‌شوند.

۱۰. نداشتن بکاپ از Zone File

شاید ساده‌ترین اشتباه و در عین حال پرتکرارترین. اگر بکاپ Zone File نداشته باشید، در صورت خطا در پیکربندی، بازگشت ممکن است ساعات طول بکشد. حتی اگر پنل DNS شما تاریخچه‌ی تغییرات داشته باشد، توصیه‌ی من این است که به‌صورت دوره‌ای Export Zone File بگیرید و آن را در جایی خارج از سرویس DNS نگه دارید.

۱۱. نبود پایش و هشدار

DNS یک سرویس پویاست که می‌تواند بی‌سروصدا خراب شود. رکوردهایی که منقضی می‌شوند، سرورهایی که از کار می‌افتند، و پیکربندی‌هایی که به‌طور تصادفی تغییر می‌کنند. نبود پایش، این مشکلات را از دید تیم دور می‌کند.

حداقل پایشی که پیشنهاد می‌کنم:

1. پایش پاسخ رکوردهای کلیدی (A، MX، TXT) از چند نقطه‌ی جغرافیایی.
2. هشدار در صورت تغییر مقدار هر رکورد (که معمولاً نشانه‌ی تغییر غیرمجاز است).
3. هشدار نزدیک به سررسید دامنه و انقضای DNSSEC.
4. پایش عملکرد سرویس DNS از نظر زمان پاسخ.

ابزارهای زیادی برای این کار وجود دارد، از سرویس‌های تجاری تا اسکریپت‌های ساده با dig و curl. حتی یک اسکریپت ساده‌ی Cron می‌تواند بخش بزرگی از این ریسک را پوشش دهد.

جدول خلاصه: اشتباه در برابر رویکرد درست

پرسش‌های پرتکرار درباره تنظیمات DNS

چطور بفهمم رکوردهای من درست تنظیم شده‌اند؟ با ابزارهای آنلاین DNS Lookup، از چند نقطه‌ی مختلف، رکوردها را بپرسید و نتیجه را با مقدار مورد انتظار مقایسه کنید. برای رکوردهای پیچیده‌تر مثل SPF، از ابزارهای تخصصی Validation استفاده کنید. اگر شک دارید، مسیر عیب‌یابی را در چگونه DNS را عیب‌یابی کنیم دنبال کنید.

آیا استفاده از DNS ابری این اشتباهات را کم می‌کند؟ تاحدی. سرویس‌های DNS ابری معمولاً رابط کاربری مدرن، Validate خودکار، و ابزارهای Import دارند که خطاهای تایپی را کاهش می‌دهند. اما اشتباهات مفهومی مثل DNSSEC بدون آماده‌سازی، در هر سرویسی می‌تواند رخ دهد. مفهوم DNS ابری را در DNS ابری چیست و چه تفاوتی با DNS سنتی دارد توضیح داده‌ام.

آیا برای سایت شخصی هم این اشتباهات مهم است؟ بعضی از آن‌ها مثل DNSSEC و GeoDNS، برای سایت‌های کوچک اولویت پایینی دارند. اما TTL، بکاپ Zone File و پایش رکوردهای کلیدی، برای هر اندازه‌ای مهم‌اند. سایت شخصی هم اگر از دسترس خارج شود، همان درد را دارد.

چطور یک رکورد یتیم را تشخیص دهم؟ سه نشانه: IP مقصد دیگر پاسخ نمی‌دهد، هیچ سرویسی به آن ارجاع نمی‌دهد، یا مدتی طولانی هیچ کوئری ندارد. برای بررسی آخرین مورد، اگر سرویس DNS شما گزارش Query دارد، می‌توانید استفاده کنید. اگر در شک هستید، ابتدا TTL را بالا ببرید و بازه‌ی چند هفته‌ای پایش کنید.

آیا DNSSEC ارزش فعال‌سازی دارد؟ برای سایت‌های حساس یا پربازدید، بله. DNSSEC از حملات Spoofing و Cache Poisoning جلوگیری می‌کند. برای سایت‌های کوچک، ارزش آن به سطح حساسیت بستگی دارد. اگر فعال می‌کنید، آماده‌سازی کامل را جدی بگیرید. برای اصول، DNS امن چیست و چه مزایایی دارد.

آیا تنظیمات DNS روی سرعت سایت اثر دارد؟ بله، از دو مسیر: زمان پاسخ Resolverها و مکانیزم‌هایی مثل Anycast یا Latency-Based Routing. برای بهبود سرعت DNS، چگونه سرعت DNS را بهبود دهیم را ببینید.

چه چیزی این اشتباهات را پنهان می‌کند؟

اگر بخواهم جان مطلب را در یک جمله بگویم: اشتباهات DNS به این دلیل خطرناک‌اند که معمولاً بی‌سروصدا هستند. سایت شاید سالم به نظر برسد، ولی بخشی از کاربران تجربه‌ی متفاوتی دارند. ایمیل شاید کار کند، ولی بخشی از پیام‌ها در اسپم می‌روند. Resolverها شاید پاسخ درست بدهند، ولی یک رکورد یتیم از سال‌ها پیش باقی مانده و منتظر یک بحران است.

سه چیز، این اشتباهات را از حالت پنهان به حالت آشکار می‌برد: مستندسازی دقیق رکوردها، بازبینی دوره‌ای Zone File و پایش مداوم از چند نقطه‌ی جغرافیایی. اگر این سه را در تیم جا بیندازید، بخش بزرگی از بحران‌های DNS از پیش گرفته می‌شود.

در چرخه‌ی کلی مدیریت دامنه، این مقاله در کنار چگونه DNS دامنه را تنظیم کنیم و تغییر DNS چه تاثیری بر سایت و رتبه Google دارد خوانده می‌شود. اگر در پروژه‌ای با یک اشتباه DNS روبه‌رو شده‌اید که ساعت‌ها وقت برد، در دیدگاه بنویسید. اسم رکورد و سناریو را دقیق بگویید تا فهرست پرچم‌های قرمز این مقاله را دقیق‌تر کنیم. 🧭