آیا خطای DNS سایت شما را از دسترس خارج کرده است؟

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

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

DNS در معماری وب دقیقاً چه نقشی دارد؟

DNS (Domain Name System) سامانه‌ای است که نام‌های دامنه‌ی خوانا برای انسان را به آدرس‌های عددی قابل‌فهم برای ماشین ترجمه می‌کند. کاربر example.com را در مرورگر می‌نویسد و DNS می‌گوید این دامنه معادل کدام آدرس آی‌پی است. اگر این ترجمه به هر دلیل شکست بخورد، مرورگر هرگز به سرور شما نمی‌رسد و خطای DNS نمایش می‌دهد. توضیح تکمیلی این سامانه در ویکی‌پدیا موجود است، ولی جان ماجرا در همین نقش ترجمه‌ای است.

نکته‌ای که در پروژه‌های واقعی بارها دیده‌ام این است که خطای DNS همیشه از خود سرور شما نیست. DNS یک سیستم توزیع‌شده است که از چند لایه تشکیل می‌شود: resolver روی دستگاه کاربر، resolver شرکت اینترنت، resolver عمومی مثل Google DNS، سرورهای ریشه، سرورهای TLD و در نهایت نام‌سرورهای معتبر دامنه‌ی شما. خطا می‌تواند در هر یک از این لایه‌ها رخ دهد و از دید کاربر، همه‌ی آن‌ها یک پیام مشابه می‌سازند. مباحث پایه‌ای این سامانه در DNS چیست و چگونه کار می‌کند با جزئیات باز شده است.

در تجربه‌ی چندساله‌ام، تفکیک میان دو نوع خطای DNS بسیار مهم است: خطای ترجمه (resolution failure) که در آن دامنه به آی‌پی ترجمه نمی‌شود، و خطای نفوذ یا مسمومیت (poisoning) که در آن دامنه به آی‌پی نادرست ترجمه می‌شود. دسته‌ی اول معمولاً ناشی از پیکربندی نادرست است، ولی دسته‌ی دوم نشانه‌ی حمله یا نفوذ به DNS است و نیازمند واکنش امنیتی فوری است. مباحث مرتبط با این حوزه در امنیت وب چیست و چه اصولی دارد باز شده است.

DNS، دفترچه‌ی تلفن اینترنت است. اگر این دفترچه گم شود، شماره‌ی شما در دنیای دیجیتال هم گم می‌شود، حتی اگر خط تلفن سالم باشد.

انواع پیام‌های خطای DNS و معنای واقعی هرکدام

مرورگرها و ابزارهای خط فرمان، پیام‌های متنوعی برای خطاهای DNS نشان می‌دهند. هر پیام به یک ریشه‌ی مشخص اشاره دارد و مسیر عیب‌یابی هر یک متفاوت است:

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

ده ریشه‌ی پنهان خطای DNS در سرور

در عیب‌یابی خطای DNS روی سرورهای تولیدی، این ده ریشه بیش از بقیه تکرار می‌شوند. تشخیص دقیق، نیمی از راه‌حل است:

ریشه‌ی اول: انقضای دامنه

شایع‌ترین و در عین حال قابل‌پیشگیری‌ترین دلیل. اگر تمدید دامنه به‌موقع انجام نشود، دامنه منقضی می‌شود و تمام درخواست‌های DNS برای آن دامنه با NXDOMAIN پاسخ می‌گیرند. این خطا فقط بعد از انقضا رخ نمی‌دهد؛ در بازه‌ی ۳۰ روزه‌ی grace period هم ممکن است دامنه به‌طور موقت از دسترس خارج شود. راه‌حل: فعال‌سازی auto-renewal و پایش ماهانه انقضا. مباحث مرتبط در تمدید دامنه و مراحل آن باز شده است.

ریشه‌ی دوم: نام‌سرورهای نادرست

اگر نام‌سرورهای ثبت‌شده در registrar با نام‌سرورهای فعلی هاست هماهنگ نباشند، DNS نمی‌تواند به zone معتبر برسد. این سناریو معمولاً بعد از مهاجرت هاست رخ می‌دهد، وقتی که نام‌سرورها در registrar به‌روز نشده‌اند. راه‌حل: بررسی NS records دامنه و هماهنگ‌سازی آن‌ها با پنل هاست.

ریشه‌ی سوم: حذف رکورد A

اگر رکورد A که دامنه را به آی‌پی سرور متصل می‌کند، به‌اشتباه حذف یا تغییر داده شود، دامنه به آی‌پی اشتباه یا به هیچ آی‌پی اشاره نمی‌کند. این سناریو در ویرایش دستی zone با خطای تایپی شایع است. مباحث مرتبط با انواع رکوردها در رکوردهای DNS و انواع آن باز شده است.

ریشه‌ی چهارم: ناهماهنگی با کش قبلی

اگر مقدار TTL رکوردها بالا باشد و تغییرات DNS به‌تازگی انجام شده باشد، resolverهای کاربران تا انقضای کش، پاسخ قدیمی را ارائه می‌دهند. این سناریو در مهاجرت‌های سریع شایع است و کاربران بسته به resolver خود، نتایج متفاوتی می‌بینند. مباحث مرتبط در انتشار DNS و مدت زمان آن باز شده است.

ریشه‌ی پنجم: خطا در پیکربندی zone

اگر فایل zone روی نام‌سرور با خطای نگارشی ذخیره شود یا رکورد SOA نادرست باشد، نام‌سرور نمی‌تواند پاسخ درست بدهد و SERVFAIL برمی‌گرداند. این سناریو در سرورهای BIND یا PowerDNS که مدیریت دستی دارند، شایع‌تر است.

ریشه‌ی ششم: DNSSEC معیوب

DNSSEC (Domain Name System Security Extensions) یک لایه‌ی امنیتی است که صحت پاسخ‌های DNS را تضمین می‌کند. اگر امضای DNSSEC منقضی یا ناسازگار باشد، resolverهای DNSSEC-aware پاسخ را رد می‌کنند و کاربران پیام SERVFAIL می‌بینند، حتی اگر zone از نظر معمولی سالم باشد. این سناریو یکی از پیچیده‌ترین موارد خطای DNS است.

ریشه‌ی هفتم: پیکربندی نادرست CDN

اگر سایت شما روی CDN مثل Cloudflare تنظیم شده باشد ولی رکوردهای CNAME یا NS به‌درستی به CDN اشاره نکنند، یا اگر نام‌سرورهای CDN و registrar هماهنگ نباشند، خطای DNS رخ می‌دهد. این سناریو در مهاجرت‌های ناموفق به CDN شایع است.

ریشه‌ی هشتم: حمله DNS Hijacking

در حمله‌ی DNS Hijacking یا DNS Spoofing، مهاجم پاسخ‌های DNS را تغییر می‌دهد و کاربران را به سرور خودش هدایت می‌کند. این سناریو در سایت‌هایی که حساب registrar آن‌ها هک شده یا نام‌سرورهایشان به سرور مهاجم تغییر داده شده، شایع‌تر است. نشانه‌ی این سناریو: دامنه به آی‌پی غیرمنتظره اشاره می‌کند، حتی وقتی zone داخلی شما سالم است.

ریشه‌ی نهم: محدودیت‌های فایروال و ACL

اگر نام‌سرور شما پشت فایروال باشد و پورت ۵۳ برای ترافیک ورودی محدود شده باشد، resolverهای عمومی نمی‌توانند با آن ارتباط برقرار کنند و خطای TIMEOUT یا REFUSED رخ می‌دهد. راه‌حل: باز کردن پورت ۵۳ در فایروال و بررسی ACL در پیکربندی نام‌سرور.

ریشه‌ی دهم: خطا در resolver کاربر

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

پروتکل واکنش سریع در بحران

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

1. تعیین دامنه‌ی خطا: سریع تست کنید که آیا خطا در همه‌ی کاربران است یا فقط بعضی. اگر همه‌ی کاربران خطا می‌بینند، احتمالاً ریشه در zone یا نام‌سرور است. اگر فقط بعضی، ریشه در resolver یا کش آن‌هاست.
2. بررسی انقضای دامنه: از پنل registrar، تاریخ انقضای دامنه را چک کنید. اگر نزدیک به انقضا یا منقضی است، سریعاً تمدید کنید.
3. تست با dig و nslookup: با این ابزارها می‌توانید ببینید که resolver فعلی چه پاسخی می‌دهد و آیا با انتظار شما هماهنگ است. جزئیات این کار در بخش تشخیص آمده است.
4. بررسی پنل CDN و registrar: اگر از CDN استفاده می‌کنید، وضعیت DNS را در پنل CDN بررسی کنید. اگر در registrar هم تغییرات اخیر داشته‌اید، آن‌ها را بازبینی کنید.
5. تست از resolver عمومی: با dig @8.8.8.8 yourdomain.com می‌توانید پاسخ Google DNS را ببینید. اگر پاسخ درست بود ولی در مرورگر خطا می‌دیدید، ریشه در resolver کاربر یا کش مرورگر است.

نکته‌ی میدانی: در بحران DNS، هیچ‌گاه به‌طور همزمان چند تغییر در zone اعمال نکنید. اگر یکی از تغییرات باعث خطا شود، تشخیص مقصر دشوار می‌شود. تغییرات را یکی‌یکی و با تست بین‌شان اعمال کنید.

تشخیص دقیق با dig، nslookup و ابزارهای آنلاین

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

dig: ابزار جامع DNS

دستور dig در لینوکس و مک، دقیق‌ترین ابزار برای بررسی DNS است. چند الگوی کاربردی:

# بررسی رکورد A دامنه
dig yourdomain.com A

# بررسی رکورد A از resolver مشخص
dig @8.8.8.8 yourdomain.com A

# بررسی نام‌سرورهای دامنه
dig yourdomain.com NS

# بررسی رکورد MX (ایمیل)
dig yourdomain.com MX

# بررسی زنجیره‌ی کامل از ریشه
dig yourdomain.com +trace

خروجی dig بخش‌های مختلفی دارد. دو بخش کلیدی، مقدار status در قسمت HEADER و رکوردهای ANSWER هستند. اگر status: NXDOMAIN دیدید، دامنه در DNS وجود ندارد. اگر status: SERVFAIL دیدید، نام‌سرور نتوانسته پاسخ بدهد.

nslookup: ابزار ساده‌تر

دستور nslookup در ویندوز و لینوکس موجود است و برای تست سریع مناسب است:

nslookup yourdomain.com
nslookup yourdomain.com 8.8.8.8

ابزارهای آنلاین

ابزارهایی مثل DNS Checker، What’s My DNS و MX Toolbox می‌توانند پاسخ DNS را از ده‌ها resolver مختلف در سراسر جهان تست کنند. این ابزارها برای تشخیص مشکلات propagation بسیار مفید هستند. اگر بعضی resolvers پاسخ درست می‌دهند و بعضی نه، مشکل شما propagation ناقص است.

توجه کنید که ابزار dig و nslookup ممکن است پاسخ‌های متفاوتی بدهند، چون هرکدام از resolver متفاوتی استفاده می‌کنند. برای تست دقیق، همیشه از resolverهای متعدد استفاده کنید.

رکوردهای DNS و خطاهای پیکربندی رایج

رکوردهای DNS واحدهای اصلی zone هستند و هرکدام نقش مشخصی دارند. خطاهای پیکربندی این رکوردها، شایع‌ترین دلیل خطای DNS در سرور است:

رکورد A

رکورد A دامنه را به یک آدرس آی‌پی IPv4 متصل می‌کند. خطاهای رایج:

• آی‌پی اشتباه (تایپ نادرست).
• آی‌پی سرور قدیمی که دیگر معتبر نیست.
• عدم هماهنگی با تغییرات سرور.

رکورد AAAA

رکورد AAAA معادل رکورد A برای IPv6 است. اگر سرور شما IPv6 ندارد ولی رکورد AAAA تنظیم شده باشد، کاربران با اتصال‌های IPv6 نمی‌توانند سایت شما را باز کنند.

رکورد CNAME

رکورد CNAME یک نام را به نام دیگر متصل می‌کند. خطای رایج: CNAME برای ریشه‌ی دامنه (root domain) که در RFC منع شده است. برای اتصال ریشه‌ی دامنه به CDN، باید از CNAME flattening یا ALIAS استفاده کنید.

رکورد MX

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

رکورد TXT

رکورد TXT برای اطلاعات متنی مثل SPF، DKIM و DMARC استفاده می‌شود. خطای رایج: چند رکورد TXT متناقض که باعث رد شدن ایمیل می‌شود.

رکورد NS

رکورد NS نام‌سرورهای معتبر دامنه را مشخص می‌کند. خطای رایج: ناهماهنگی NS ثبت‌شده در registrar با NS اعلام‌شده توسط zone. این ناهماهنگی باعث می‌شود resolverها نتوانند نام‌سرور معتبر را پیدا کنند.

مباحث دقیق‌تر درباره‌ی انواع رکوردها و پیکربندی آن‌ها در تنظیم DNS دامنه و اشتباهات رایج در تنظیم DNS باز شده است.

نام‌سرورها و نقش آن‌ها در دسترس بودن سایت

نام‌سرورها (Name Servers) سرورهایی هستند که پاسخ معتبر برای دامنه‌ی شما ارائه می‌دهند. تفاوت نام‌سرور با resolver را می‌توان در تفاوت DNS و Nameserver با جزئیات دید. دو سناریوی رایج خطا در این لایه:

ناهماهنگی NS در registrar

وقتی دامنه ثبت می‌شود، registrar از شما می‌پرسد که نام‌سرورهای شما کدام‌اند. اگر این نام‌سرورها با نام‌سرورهای فعلی هاست هماهنگ نباشند، resolverها نمی‌توانند به zone معتبر برسند. این سناریو در مهاجرت از یک هاست به هاست دیگر شایع است.

نام‌سرور پاسخ‌نداده

اگر نام‌سرور شما به هر دلیل از کار بیفتد (خرابی سرور، محدودیت فایروال، یا قطع شبکه)، resolverها پس از چند ثانیه انتظار، خطای TIMEOUT یا SERVFAIL برمی‌گردانند. برای کاهش ریسک، توصیه می‌شود همیشه حداقل دو نام‌سرور در نقاط جغرافیایی مختلف داشته باشید.

انتشار DNS و بازه‌ی انتظار

انتشار DNS (DNS Propagation) فرآیند به‌روزرسانی پاسخ‌های DNS در resolverهای سراسر جهان است. این فرآیند به‌طور خودکار و بر اساس مقدار TTL انجام می‌شود، ولی مدت زمان آن می‌تواند از چند دقیقه تا چند روز متغیر باشد. سه عامل مؤثر بر زمان انتشار:

1. مقدار TTL رکوردها: TTL پایین‌تر یعنی انتشار سریع‌تر، ولی ترافیک بالاتر برای نام‌سرور.
2. رفتار resolverها: بعضی resolverها مقدار TTL را نادیده می‌گیرند و کش را بیشتر نگه می‌دارند.
3. مکان جغرافیایی: کاربران در مناطق مختلف، بسته به resolver پیش‌فرض، زمان متفاوتی از انتشار را تجربه می‌کنند.

نکته‌ی میدانی: قبل از هر مهاجرت DNS، مقدار TTL را به ۳۰۰ ثانیه یا کمتر کاهش دهید. این کار باعث می‌شود بعد از مهاجرت، انتشار سریع‌تر انجام شود. بعد از اطمینان از انتشار کامل، TTL را می‌توانید به مقدار عادی برگردانید. مباحث مرتبط در انتشار DNS و مدت زمان آن باز شده است.

کش DNS و مقدار TTL

کش DNS، لایه‌ای است که پاسخ‌های DNS را برای مدتی مشخص ذخیره می‌کند تا درخواست‌های بعدی سریع‌تر پاسخ بگیرند. مقدار TTL (Time To Live) در هر رکورد، مدت زمان نگه‌داری در کش را مشخص می‌کند. اهمیت این مقدار در سناریوهای خطای DNS:

TTL بالا و تغییرات سریع

اگر TTL روی ۲۴ ساعت تنظیم شده باشد و شما یک تغییر سریع در DNS اعمال کنید، تا ۲۴ ساعت بعد در بعضی resolverها، پاسخ قدیمی همچنان ارائه می‌شود. این سناریو به ظاهر خطا نمی‌سازد، ولی کاربران رفتار متناقضی می‌بینند: بعضی سایت را می‌بینند، بعضی خطای DNS می‌گیرند.

TTL پایین و بار سرور

TTL پایین (مثل ۶۰ ثانیه) انتشار را سریع می‌کند ولی بار روی نام‌سرور را افزایش می‌دهد، چون resolverها مرتب باید پاسخ را از zone بگیرند. این تنظیم برای سایت‌های پرترافیک می‌تواند هزینه‌ی پهنای باند داشته باشد.

ارزش پیشنهادی TTL

مقدار پیشنهادی من برای اکثر سایت‌ها، TTL بین ۳۶۰۰ تا ۱۴۴۰۰ ثانیه (۱ تا ۴ ساعت) است. این مقدار تعادل خوبی بین سرعت انتشار و بار سرور ایجاد می‌کند. برای مواقع مهاجرت، می‌توانید موقتاً به ۳۰۰ ثانیه کاهش دهید.

DNSSEC و خطاهای مربوط به آن

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

خطاهای رایج DNSSEC

سه سناریوی شایع:

• انقضای امضا: امضای DNSSEC باید مرتب تمدید شود. اگر امضا منقضی شود، resolverهای DNSSEC-aware پاسخ را رد می‌کنند.
• ناهماهنگی کلیدها: کلید عمومی در zone با کلید ثبت‌شده در والد (parent zone) هماهنگ نیست.
• عدم پشتیبانی resolver: بعضی resolverهای قدیمی DNSSEC را پشتیبانی نمی‌کنند و ممکن است پاسخ را نادیده بگیرند.

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

CDN، پراکسی و خطاهای DNS در لبه‌ی شبکه

اگر سایت شما روی CDN مثل Cloudflare تنظیم شده باشد، لایه‌ی DNS پیچیده‌تر می‌شود. دو سناریوی رایج:

حالت Proxied در برابر DNS Only

در Cloudflare، رکوردهای DNS می‌توانند در دو حالت باشند: Proxied (ترافیک از Cloudflare عبور می‌کند) و DNS Only (ترافیک مستقیم به سرور می‌رود). اگر رکوردی که باید Proxied باشد، DNS Only تنظیم شود، ممکن است آی‌پی سرور اصلی در DNS عمومی لو برود یا رفتار ناهمگون داشته باشد.

ناهماهنگی نام‌سرورهای CDN

وقتی سایت را به CDN منتقل می‌کنید، باید نام‌سرورهای registrar را به نام‌سرورهای CDN تغییر دهید. اگر این تغییر ناقص انجام شود یا در بازه‌ی انتقال رخ دهد، خطای DNS می‌تواند تا ۴۸ ساعت ادامه داشته باشد. راه‌حل: قبل از انتقال، برنامه‌ریزی دقیق و کاهش TTL.

نکته‌ی میدانی: در یکی از پروژه‌ها، خطای DNS فقط برای کاربران موبایل رخ می‌داد. ریشه این بود که رکورد AAAA (برای IPv6) به آی‌پی اشتباه اشاره می‌کرد و شبکه‌های موبایل بیشتر از IPv6 استفاده می‌کنند. حذف رکورد AAAA نادرست، مسئله را در چند دقیقه حل کرد. مباحث مرتبط با CDN در مدیریت DNS در cPanel و اتصال هاست به دامنه باز شده است.

بازگردانی سرویس و اولویت‌بندی

بعد از پیدا کردن ریشه، نوبت به بازگردانی سرویس می‌رسد. ترتیب اولویت‌بندی من در پروژه‌های واقعی:

1. اصلاح سریع رکورد: اگر ریشه در رکورد نادرست است، همان رکورد را تصحیح کنید و تست بگیرید.
2. بررسی و تصحیح نام‌سرور: اگر ریشه در ناهماهنگی نام‌سرور است، آن را در registrar یا پنل CDN اصلاح کنید.
3. کاهش TTL برای انتشار سریع: اگر تصحیح نیاز به انتشار دارد، TTL را به مقدار پایین کاهش دهید تا تغییرات سریع‌تر به resolverها برسد.
4. اطلاع‌رسانی به کاربران: اگر سایت برای همه در دسترس نیست، از طریق کانال‌های دیگر (شبکه‌های اجتماعی، ایمیل) به کاربران اطلاع دهید که مشکل موقتی است.
5. مستندسازی: ریشه، روش تشخیص و راه‌حل را ثبت کنید. این یادداشت در بحران بعدی، ساعت‌ها زمان صرفه‌جویی می‌کند.

پایش مستمر و پیشگیری

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

سطح اول: پایش انقضای دامنه

تاریخ انقضای دامنه را در تقویم یادداشت کنید و ۳۰ روز قبل، هشدار بگذارید. اکثر registrarها امکان auto-renewal دارند که باید فعال باشد.

سطح دوم: پایش دور از سرور

سرویس‌هایی مثل Uptime Robot یا Pingdom می‌توانند سایت شما را از نقاط جغرافیایی مختلف پایش کنند. اگر خطای DNS از یک منطقه خاص رخ می‌دهد، این سرویس‌ها هشدار می‌دهند.

سطح سوم: پایش پیکربندی DNS

هر ماه یک‌بار، رکوردهای DNS دامنه را با dig بررسی کنید و مطمئن شوید که با انتظار شما هماهنگ هستند. اگر رکورد غیرمنتظره‌ای دیدید، بلافاصله بررسی کنید.

سطح چهارم: پایش تهدیدهای امنیتی

اگر دامنه‌ی شما حساس است، از سرویس‌های پایش DNS Hijacking استفاده کنید. این سرویس‌ها تغییرات ناگهانی در رکوردها را تشخیص می‌دهند و هشدار می‌دهند.

مباحث مرتبط با امنیت DNS و عیب‌یابی آن در رفع مشکلات DNS باز شده است. همچنین برای بررسی سایر خطاهای مرتبط با سرور، مقالات رفع خطای 502 Bad Gateway و خطای SSL در سرور را مرور کنید.

پرسش‌های پرتکرار درباره خطای DNS سرور

تفاوت resolver و نام‌سرور چیست؟

resolver سروری است که درخواست کاربر را دریافت می‌کند و پاسخ را از نام‌سرورها می‌گیرد. نام‌سرور سروری است که پاسخ معتبر برای یک دامنه‌ی مشخص را ذخیره دارد. resolver لایه‌ی میانی است، نام‌سرور لایه‌ی نهایی.

چرا بعضی کاربران سایت را می‌بینند و بعضی نه؟

این الگو معمولاً نشانه‌ی propagation ناقص است. resolverهای مختلف بر اساس TTL رکوردها، کش خود را به‌روز می‌کنند و به همین دلیل بعضی کاربران پاسخ قدیمی و بعضی پاسخ جدید می‌گیرند. راه‌حل: صبر تا انقضای کش یا کاهش TTL برای انتشار سریع‌تر.

آیا خطای DNS می‌تواند ناشی از هک شدن سایت باشد؟

بله. در حمله‌ی DNS Hijacking، مهاجم رکوردهای DNS را تغییر می‌دهد و کاربران را به سرور خود هدایت می‌کند. نشانه‌ی این سناریو: دامنه به آی‌پی غیرمنتظره اشاره می‌کند، حتی وقتی zone داخلی شما سالم است. راه‌حل: بررسی فوری حساب registrar و تغییر رمزها. مباحث مرتبط در افزایش امنیت سرور باز شده است.

آیا خطای DNS روی سئو تأثیر می‌گذارد؟

بله. اگر خطای DNS مدت‌زمان زیادی ادامه داشته باشد، گوگل نمی‌تواند سایت شما را ایندکس کند و رتبه‌ها افت می‌کنند. حتی اگر خطا سریع رفع شود، ربات‌های گوگل ممکن است برای مدتی سایت را با تأخیر بررسی کنند. راه‌حل: بعد از رفع، در Google Search Console درخواست ایندکس مجدد دهید.

چطور بفهمم خطای DNS از سرور من است یا از CDN؟

سریع‌ترین تست، دور زدن CDN است. با دستور dig @8.8.8.8 yourdomain.com NS می‌توانید نام‌سرورهای معتبر را ببینید. اگر نام‌سرورهای CDN هستند، ریشه در پیکربندی CDN است. اگر نام‌سرورهای هاست شما هستند، ریشه در zone داخلی است.

TTL مناسب برای دامنه‌ی فعال چقدر است؟

مقدار پیشنهادی برای اکثر سایت‌ها، TTL بین ۳۶۰۰ تا ۱۴۴۰۰ ثانیه است. برای مواقع مهاجرت، به ۳۰۰ ثانیه کاهش دهید. برای سایت‌های پرترافیک با هزینه‌ی پهنای باند بالا، می‌توانید TTL بالاتر تنظیم کنید.

آیا می‌توانم از چند نام‌سرور استفاده کنم؟

بله و توصیه می‌شود. حداقل دو نام‌سرور در نقاط جغرافیایی مختلف داشته باشید تا اگر یکی از کار افتاد، دیگری پاسخ دهد. در تنظیمات registrar می‌توانید چند نام‌سرور را ثبت کنید.

بعد از مهاجرت سرور، چرا خطای DNS ظاهر می‌شود؟

سه دلیل رایج: نام‌سرورها در registrar به‌روز نشده‌اند، رکورد A به آی‌پی قدیمی اشاره می‌کند، یا propagation ناقص است. بررسی هر سه مورد پس از هر مهاجرت ضروری است.

آیا DNSSEC برای همه‌ی سایت‌ها لازم است؟

خیر. DNSSEC برای سایت‌هایی که حساسیت امنیتی بالا دارند (بانک، پرداخت، سازمان) توصیه می‌شود. برای سایت‌های معمولی، فعال‌سازی HTTPS کافی است. اگر DNSSEC را فعال می‌کنید، حتماً با ابزارهای تخصصی پیکربندی را تست کنید.

چطور از حمله DNS Hijacking جلوگیری کنم؟

سه اقدام: اول، فعال‌سازی 2FA روی حساب registrar. دوم، قفل کردن دامنه (Registrar Lock) که تغییرات غیرمجاز را مسدود می‌کند. سوم، فعال‌سازی DNSSEC برای اطمینان از صحت پاسخ‌ها. این سه لایه، سطح امنیت دامنه را به‌شدت بالا می‌برند.

نکته‌های میدانی از مدیریت بحران DNS

در پایان این مقاله، چند نکته‌ای را می‌گویم که در مستندات رسمی کم‌تر به آن‌ها اشاره می‌شود ولی در پروژه‌های واقعی بارها به کارم آمده:

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

دوم: قبل از هر تغییر در DNS، همیشه مقدار TTL را کاهش دهید و بعد از تغییر، دوباره مقدار عادی را برگردانید. این عادت کوچک، در مواقع بحران، تفاوت میان چند دقیقه و چند روز انتظار است.

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

در تجربه‌ی چندساله‌ام روی سرورهای تولیدی و پروژه‌های وردپرسی، الگویی که بارها تکرار شده این است که خطای DNS تقریباً همیشه در یکی از چهار لایه ریشه دارد: انقضا و ثبت دامنه، پیکربندی zone، کش و propagation، یا امنیت DNS. تشخیص سریع این لایه، از هر راه‌حل آماده مؤثرتر است. اگر ابزارهای تشخیصی را در اختیار داشته باشید و لایه‌ها را به ترتیب بررسی کنید، این خطا از یک بحران ترسناک به یک تمرین روتین تبدیل می‌شود.

اگر روی دامنه یا سرور خود با نوعی از خطای DNS مواجه شده‌اید که در این مقاله پوشش داده نشده، یا اگر راه‌حل متفاوتی پیدا کرده‌اید که به کارتان آمده، برای من جالب است آن را بشنوم. مشخصاً اگر خروجی dig یا تنظیمات registrar که ریشه‌ی واقعی را نشان داد، با خوانندگان دیگر به اشتراک بگذارید؛ این یادداشت‌های دقیق، برای مدیر سرور بعدی ساعت‌ها زمان صرفه‌جویی می‌کنند. 🌐