تغییر DNS؛ چرا سایت برای بعضی کاربران باز نمی‌شود؟
تأخیر در دیده شدن تغییر با تنظیم اشتباه فرق دارد. این راهنما کمک میکند بفهمید چه زمانی صبر لازم است و چه زمانی باید رکوردها یا اعتبارسنجی را اصلاح کرد.
تغییر DNS را انجام داده‌اید، اما سایت برای شما باز میشود و برای همکارتان نه. پشتیبانی می‌گوید صبر کنید، درحالی‌که معلوم نیست با تأخیر عادی روبه‌رو هستید یا تنظیم اشتباه. همین ابهام باعث میشود بعضی مدیران چند بار رکوردها را عوض کنند و پیگیری را سخت‌تر کنند.
ذخیره شدن پاسخ قدیمی و اشتباه بودن پاسخ جدید، دو مشکل متفاوت‌اند. صبر کردن می‌تواند برای اولی لازم باشد، اما دومی را اصلاح نمی‌کند. هدف این راهنما، تشخیص مسیر بررسی است؛ نه وعده یک زمان ثابت برای همه دامنه‌ها و شبکه‌ها.
DNS چه کاری انجام می‌دهد؟
DNS نامی مانند دامنه سایت را به اطلاعات لازم برای پیدا کردن مقصد مرتبط میکند. دستگاه شما معمولاً برای هر بار باز کردن صفحه از ابتدا تمام مسیر را طی نمی‌کند؛ پاسخ‌ها در جاهای مختلف برای مدتی نگهداری می‌شوند. همین ذخیره موقت، سرعت را بهتر میکند اما تغییر را برای همه هم‌زمان نشان نمی‌دهد.
TTL مدت اعتبار پاسخ ذخیرهشده را مشخص میکند. پایین آوردن آن می‌تواند برای تغییرهای آینده مفید باشد، ولی نسخه‌ای را که قبلاً با زمان طولانی ذخیره شده فوراً پاک نمی‌کند. باید زمان‌بندی را پیش از جابهجایی در نظر گرفت.
تغییر رکورد با تغییر نیم‌سرور یکی نیست
رکورد A معمولاً مقصد IPv4 را معرفی میکند و AAAA برای IPv6 است. رکورد MX به دریافت ایمیل مربوط است. نیمسرورها مشخص می‌کنند پاسخهای اصلی دامنه از کدام سرویس گرفته شوند. تغییر یکی از این‌ها، همه موارد دیگر را خودکار اصلاح نمی‌کند.
| تغییری که انجام شده | چیزی که باید بررسی شود |
|---|---|
| تغییر A | مقصد وب‌سایت در مسیر IPv4 |
| تغییر AAAA | مقصد وب‌سایت در مسیر IPv6 |
| تغییر MX | سرویس دریافت ایمیل |
| تغییر نیم‌سرور | رکوردهای کامل در سرویس جدید و واگذاری درست |
| تغییر تنظیمات DNSSEC | هماهنگی اطلاعات اعتبارسنجی دامنه |
اگر فقط A را عوض کنید و AAAA به سرور قدیمی اشاره کند، بعضی مراجعه‌ها میتوانند مسیر متفاوتی داشته باشند. این مشکل را نباید صرفاً به دیر به‌روز شدن اینترنت نسبت داد. مسئول فنی باید هر دو مسیر موجود را بررسی کند.
چهار پرسش قبل از هر تغییر دوباره
- اکنون کدام نیمسرورها برای دامنه تعیین شده‌اند؟
- پاسخ سرویس اصلی DNS برای رکورد مورد نظر چیست؟
- پاسخ شبکه کاربر با آن چه تفاوتی دارد؟
- آیا مشکل از پیدا کردن مقصد است یا از پاسخ خود سرور؟
ممکن است نام درست به مقصد برسد، اما سایت خطای برنامه یا گواهی بدهد. در این حالت، ویرایش DNS لزوماً کمکی نمی‌کند. متن دقیق خطا و زمان آن را ثبت کنید؛ عبارت «بالا نمی‌آید» چند نوع ایراد را پنهان میکند.
چرا پاک کردن کش مرورگر همیشه جواب نمی‌دهد؟
مرورگر فقط یکی از محل‌های ذخیره موقت است. سیستم‌عامل، سرویس حل نام شبکه و حتی لایه‌های میانی میتوانند در نتیجه نقش داشته باشند. علاوه بر آن، آنچه قدیمی دیده میشود شاید محتوای کش‌شده صفحه باشد، نه پاسخ DNS.
باز کردن سایت در حالت خصوصی یا اینترنت دیگر می‌تواند سرنخ بدهد، ولی تشخیص قطعی نیست. اگر با اینترنت دوم مشکل رفع شد، هنوز باید مشخص شود تفاوت از کدام بخش آمده است. از نتیجه یک آزمون، حکم کلی درباره سالم یا خراب بودن هاست ندهید.
DNSSEC چرا بعد از جابهجایی دردسر می‌سازد؟
DNSSEC سازوکاری برای اعتبارسنجی پاسخ DNS است. اگر ارائه‌دهنده عوض شود ولی اطلاعات مرتبط با کلیدهای قبلی باقی بماند، بعضی اعتبارسنج‌ها ممکن است پاسخ را نپذیرند. در این وضعیت، رکورد درست هم برای همه قابل استفاده نخواهد بود.
راه‌حل، هماهنگ کردن فرایند انتقال با مستندات ارائه‌دهندگان است. خاموش کردن بی‌برنامه حفاظت یا کپی کردن رکوردی از دامنه دیگر توصیه مناسبی نیست. این بخش را به مسئول فنی بسپارید و از او بخواهید وضعیت قبل و بعد را تأیید کند.
نکته: اگر نیم‌سرور را تغییر می‌دهید، فقط رکورد سایت را کپی نکنید؛ ایمیل، زیردامنه‌ها و رکوردهای تأیید سرویس‌ها نیز ممکن است لازم باشند.
چگونه درخواست پشتیبانی مفید بنویسیم؟
نام کامل دامنه، نوع رکورد تغییرکرده، زمان تغییر و شبکه‌ای را که مشکل در آن دیده میشود اعلام کنید. اگر مقصد قدیمی و جدید را می‌دانید، در کانال پشتیبانی معتبر ثبت کنید. تصویر خطا مفید است، ولی نمایش رمز یا اطلاعات حساس ضرورتی ندارد.
بپرسید «پاسخ اصلی اکنون درست است یا نه؟» اگر پاسخ درست است، بررسی کش و مسیر کاربر معنا پیدا میکند. اگر غلط است، ابتدا باید همان تنظیم اصلاح شود. این ترتیب جلوی انتظار بی‌فایده را می‌گیرد
یک مثال عملی برای تصمیم‌گیری
یک فروشگاه فرضی به هاست جدید رفته و بعضی مشتریان هنوز نسخه قبلی را می‌بینند. در این مثال، مسئله‌ای که باید حل شود این است: تفاوت مقصد بین دو شبکه پس از جابهجایی قرار نیست از روی یک نشانه، نتیجه قطعی بگیریم. بهتر است ابتدا معلوم کنیم چه چیزی قابل مشاهده است و چه چیزی فقط حدس ماست. این تفکیک جلوی خرید عجولانه یا تغییر تنظیماتی را می‌گیرد که به مشکل ارتباطی ندارند.
اولین مدرک مفید در این سناریو، مقایسه پاسخ رکوردهای A و AAAA و پاسخ نیم‌سرور اصلی است. اگر این اطلاعات در دسترس نیست، قدم بعدی تهیه همان مدرک است؛ نه انتخاب گران‌ترین گزینه. گاهی یک گزارش کوتاه نشان می‌دهد مسئله در کدام بخش قرار دارد و گاهی لازم است بررسی دقیق‌تری انجام شود. در هر دو حالت، ثبت وضعیت اولیه کمک میکند نتیجه اقدام را با چیزی واقعی مقایسه کنید.
اقدام پیشنهادی نخست این است: از مسئول فنی بخواهید مشخص کند هر شبکه به کدام مقصد می‌رسد. این اقدام باید با وضعیت سرویس و اختیار شما سازگار باشد. اگر دسترسی لازم را ندارید، از فرد مسئول بخواهید نتیجه را همراه با توضیح کوتاه ارائه کند. نیازی نیست صاحب کسب‌وکار همه جزئیات فنی را خودش اجرا کند؛ اما باید بداند چه کاری انجام شده و قرار است چه اثری داشته باشد.
اشتباه وسوسه‌کننده در این مثال، تعویض مکرر نیمسرورها بدون ثبت وضعیت قبلی است. ممکن است چنین کاری ظاهراً سریع‌تر باشد، اما اگر علت را برطرف نکند، هزینه یا ابهام تازه‌ای به وجود می‌آورد. راه بهتر این است که برای هر تغییر، یک دلیل مشخص داشته باشید و پس از آن همان نشانه اولیه را دوباره بررسی کنید. هم‌زمان عوض کردن چند عامل، تشخیص اثر هرکدام را دشوار میکند.
پیش از اقدام، معیار نتیجه را مشخص کنید
برای موضوع تغییر DNS، نتیجه مورد انتظار در این سناریو چنین است: پاسخ درست DNS و دسترسی به نسخه مورد انتظار سایت از مسیرهای بررسی‌شده. این جمله را در درخواست خود بنویسید تا معیار تحویل برای دو طرف یکسان باشد. عبارت‌هایی مثل «بررسی شد» یا «انجام شد» به‌تنهایی نشان نمی‌دهند نیاز شما برطرف شده است. باید نتیجه‌ای وجود داشته باشد که بتوان آن را مشاهده یا تأیید کرد.
مسئول مناسب پیگیری، مدیر DNS با همکاری پشتیبانی هاست است. اگر افراد مختلفی درگیرند، یک نفر هماهنگی را بر عهده بگیرد و پاسخ‌ها را کنار هم قرار دهد. مسئول مالی، طراح و پشتیبانی ممکن است هرکدام بخشی از اطلاعات را داشته باشند؛ تصمیم خوب از ترکیب این اطلاعات به دست می‌آید. نبودن مسئول مشخص، حتی یک کار ساده را طولانی میکند.
این پرسش را مطرح کنید: «آیا پاسخ اصلی اشتباه است یا فقط پاسخ قدیمی در مسیر کاربر باقی مانده است؟» پاسخ خوب باید محدودیت‌ها و اقدام بعدی را روشن کند. اگر جواب فقط یک عبارت تبلیغاتی یا توصیه کلی بود، جزئیات مربوط به وضعیت خودتان را بخواهید. هدف گرفتن قول ناممکن نیست؛ باید بتوانید بفهمید چه چیزی در تعهد ارائه‌دهنده است و کدام بخش به تنظیمات یا تصمیم شما وابسته است.
چک‌لیست پیگیری و تحویل
- شرح کوتاهی از نیاز و شرایط فعلی بنویسید؛ نام سرویس، دامنه مرتبط و زمان مشاهده مسئله را در صورت نیاز ثبت کنید.
- مدرک مربوط را جمع کنید و اطلاعات محرمانه مثل رمز، کلید یا داده مشتری را از نسخه ارسالی عمومی حذف کنید.
- اقدام پیشنهادی را به یک نتیجه قابل بررسی وصل کنید و مشخص کنید چه کسی آن را انجام می‌دهد.
- اگر تغییر بر سرویس فعال اثر دارد، زمان انجام و روش حفظ وضعیت قبلی را پیشاپیش هماهنگ کنید.
- پس از اقدام، بررسی اصلی را انجام دهید: سایت و ایمیل از مسیر درست کار کنند و رکوردهای ضروری حذف نشده باشند.
- نتیجه و موارد باقی‌مانده را ثبت کنید؛ پایان یک درخواست پشتیبانی لزوماً به معنی پایان همه بررسی‌های لازم نیست.
در مورد برگشت از تغییر، اگر مقصد قبلی هنوز لازم است، اطلاعات آن را حفظ کنید؛ اما برگشت رکورد بدون بررسی داده‌های جدید سایت می‌تواند مسئله دیگری بسازد. پیش از اقدام درباره همین موضوع توافق کنید. داشتن راه بازگشت فقط به معنی نگه داشتن یک تصویر از پنل نیست؛ لازم است مشخص باشد چه اطلاعات یا اختیاراتی برای برگشت لازم است. اگر اقدام برگشت‌پذیر نیست، تصمیم باید با آگاهی از همین محدودیت گرفته شود.
در زمان انتقال فروشگاه، رسیدن بعضی کاربران به مبدأ می‌تواند روی سفارش‌ها اثر بگذارد. مسئول سایت باید بداند ثبت اطلاعات تازه در کدام نسخه مجاز است. حل DNS به‌تنهایی داده‌های دو نسخه فروشگاه را با هم یکی نمی‌کند.
پاسخ قدیمی را از صفحه قدیمی جدا کنید
گاهی کاربر به سرور جدید رسیده، اما افزونه یا مرورگر هنوز نسخه قبلی صفحه را نشان می‌دهد. مسئول فنی می‌تواند با یک نشانه کنترل‌شده یا گزارش سرور مقصد واقعی را تشخیص دهد. تغییر دوباره IP در چنین حالتی علت نمایش محتوا را رفع نمی‌کند.
بعد از اصلاح، رکوردهای غیرمرتبط را نیز مرور کنید تا چیزی ناخواسته حذف نشده باشد. دریافت ایمیل و زیردامنه‌های مهم را آزمایش کنید. پایان موفق کار زمانی است که مقصد درست و خدمات لازم هر دو تأیید شده باشند، نه صرفاً اینکه یک ابزار عمومی رنگ سبز نشان دهد.
برای مطالعه بیشتر
مطالب مرتبط را در راهنمای دامنه و صفحه سوالات متداول دنبال کنید.
مراجع فنی این مقاله: TTL در Cloudflare و عیب‌یابی تنظیم کامل DNS.
سوالات متداول
تغییر DNS دقیقاً چقدر طول می‌کشد؟
زمان به رکورد، TTL قبلی و مسیر ذخیره پاسخ بستگی دارد. ابتدا درست بودن تنظیمات اصلی را تأیید کنید.
آیا باید چند بار نیمسرورها را عوض کنم؟
خیر؛ بدون تشخیص علت، این کار پیگیری را پیچیده میکند. وضعیت فعلی و پاسخ اصلی را بررسی کنید.
چرا با اینترنت دیگر سایت باز میشود؟
ممکن است پاسخ ذخیرهشده یا مسیر شبکه متفاوت باشد. این نتیجه فقط یک سرنخ است، نه تشخیص نهایی.
آیا تغییر DNS ایمیل را هم جابهجا میکند؟
فقط تغییرهای مرتبط بر مسیر ایمیل اثر دارند. جابهجایی پیامهای قدیمی کار جداگانهای است.
آیا پایین آوردن TTL فوراً مشکل را حل میکند؟
خیر؛ پاسخهای قدیمی میتوانند تا پایان اعتبار قبلی باقی بمانند.
