اولین باری که روی یک فروشگاه اینترنتی حساس، رکوردهای DNS (Domain Name System) را تغییر دادم، چند ساعت بعدش با یک تماس از طرف کارفرما مواجه شدم که می‌گفت نیمی از مشتریان در مازندران سایت را نمی‌بینند و نیم دیگرشان سایت قدیمی را می‌بینند. مشکل فنی پیچیده‌ای نبود؛ فقط TTL بالا و cache ISPها بود. آن تجربه به من یاد داد که تغییر DNS، در نگاه سطحی، شبیه تغییر یک تنظیم ساده در پنل به نظر می‌رسد، اما در واقع یک عملیات روی زیرساخت توزیع‌شده‌ی اینترنت است و اثرش می‌تواند تا چند روز ادامه داشته باشد. این مقاله دقیقاً همان اثر را می‌کاود: از دسترسی و سرعت گرفته تا سئو و ایمیل و SSL.

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

در لحظه‌ی تغییر DNS دقیقاً چه اتفاقی می‌افتد؟

وقتی شما یک رکورد DNS را در پنل ثبت‌کننده یا سرویس‌دهنده‌ی DNS خود تغییر می‌دهید، این تغییر فوراً در کل اینترنت اعمال نمی‌شود. مکانیزم این است: در سراسر اینترنت، هزاران سرور DNS وجود دارد که به آن‌ها Resolver می‌گویند — از جمله Resolverهای ISPها، Resolverهای عمومی مثل Google DNS و Cloudflare، و Resolverهای محلی در روترها و سیستم‌عامل‌ها. هرکدام از این Resolverها، پاسخ‌های DNS را برای مدتی در حافظه‌ی خود نگه می‌دارند تا کوئری‌های بعدی را سریع‌تر پاسخ دهند.

پس تغییر شما در ابتدا فقط در سرور Authoritative (سروری که شما آن را کنترل می‌کنید) اعمال می‌شود. Resolverها تا زمانی که مدت TTL کش‌شده‌شان منقضی نشده، همان پاسخ قدیمی را برمی‌گردانند. تنها بعد از انقضای TTL است که Resolver به سرور Authoritative برمی‌گردد و مقدار جدید را می‌گیرد.

DNS یک پایگاه‌داده‌ی متمرکز نیست؛ یک سیستم توزیع‌شده با حافظه‌های موقت است. هر تغییر، به تعداد Resolverهای اینترنت، تأخیر دارد.

TTL و پروپاگیشن: چرا سایت شما برای همه هم‌زمان تغییر نمی‌کند؟

TTL (Time To Live) مقداری است که در هر رکورد DNS تعیین می‌کنید و به Resolverها می‌گوید این پاسخ را چند ثانیه کش کنند. مقدار رایج برای سایت‌های پرمخاطب، ۳۶۰۰ ثانیه (یک ساعت) یا ۸۶۴۰۰ ثانیه (۲۴ ساعت) است. هرچه TTL بالاتر باشد، ترافیک کوئری به سرورهای Authoritative کمتر است، اما هر تغییری کندتر منتشر می‌شود.

مفهوم پروپاگیشن (Propagation) در واقع همان مدت زمانی است که طول می‌کشد همه‌ی Resolverهای اینترنت مقدار جدید را ببینند. در ادبیات دقیق‌تر، این «انتشار» نیست که رخ می‌دهد؛ بلکه هر Resolver بر اساس TTL خودش، در زمانی متفاوت کشش را دور می‌ریزد. به همین دلیل است که در ساعت‌های اول، برخی کاربران نسخه‌ی جدید را می‌بینند و برخی دیگر نسخه‌ی قدیمی را. برای درک دقیق‌تر این پدیده، پروپاگیشن DNS چیست و چقدر طول می‌کشد را ببینید.

استراتژی کاهش TTL پیش از تغییر

یک تکنیک عملی که در پروژه‌های حساس همیشه استفاده می‌کنم: ۲۴ تا ۴۸ ساعت قبل از تغییر اصلی، TTL رکورد را به ۳۰۰ ثانیه یا کمتر کاهش دهید. این کاهش، بی‌خطر است و در طول دوره‌ی تغییر، سریع‌تر منتشر می‌شود. پس از تثبیت تغییر، می‌توانید TTL را به مقدار قبلی برگردانید. هزینه‌ی این کار، افزایش موقت کوئری‌های DNS است که در سرویس‌های DNS مدرن تقریباً هیچ معنی ندارد.

اثر بر دسترسی و Uptime سایت

در لحظه‌ی تغییر DNS، دو سناریو داریم:

  • تغییر A Record به یک IP جدید در همان سرور: تقریباً بی‌خطر. اگر IP جدید آماده باشد و سرور درست کار کند، کاربران بدون وقفه‌ی محسوس به سایت جدید منتقل می‌شوند.
  • تغییر Nameserver (انتقال DNS به سرویس جدید): پرخطرتر. اگر سرویس DNS جدید رکوردها را کامل منتقل نکرده باشد، در بازه‌ی پروپاگیشن ممکن است برخی کاربران به نسخه‌ی قدیمی و برخی به نسخه‌ی ناقص برسند یا حتی پاسخ NXDOMAIN بگیرند.

در پروژه‌ها، بیشترین outageهایی که دیده‌ام، ناشی از همین تغییر Nameserver بوده است. راه‌حل: پیش از تغییر Nameserver، تمام رکوردها را در سرویس جدید کامل ثبت کنید و با ابزارهایی مثل dig یا nslookup روی سرویس جدید تست بگیرید. اصول تشخیص را در چگونه DNS را عیب‌یابی کنیم آورده‌ام.

اثر بر سرعت و زمان پاسخ (RTT)

DNS در سرعت بارگذاری صفحه، دو نقش دارد: زمان resolve اولیه و انتخاب بهترین IP. اگر سرویس DNS شما کند پاسخ دهد، TTFB (Time To First Byte) تحت تأثیر قرار می‌گیرد و همه‌ی بارگذاری‌های بعدی کمی به تأخیر می‌افتند. به همین دلیل، انتخاب یک ارائه‌دهنده‌ی DNS سریع، یکی از ارزان‌ترین بهینه‌سازی‌های سرعت است.

علاوه بر زمان پاسخ، مکانیزم‌هایی مثل Anycast، Route53 Latency-based Routing و GeoDNS می‌توانند کاربر را به نزدیک‌ترین سرور بفرستند. اگر DNS شما این قابلیت‌ها را دارد، تغییر DNS می‌تواند سرعت سایت را برای کاربران دورافتاده به‌طور محسوس بهبود بخشد. برای اصول این بهینه‌سازی، چگونه سرعت DNS را بهبود دهیم را ببینید. برای درک کلی‌تر اثر سرعت بر تجربه، تاثیر هاست بر سرعت سایت چقدر است هم مفید است.

اثر تغییر DNS بر سئو و رتبه Google

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

با این حال، سه پیامد جانبی می‌تواند رتبه را تهدید کند:

  1. Downtime طولانی: اگر سایت در بازه‌ی پروپاگیشن به‌طور مکرر در دسترس نباشد، Googlebot ممکن است دچار مشکل شود و بودجه‌ی خزش (Crawl Budget) را کاهش دهد. برای جزئیات، سئو تکنیکال: از خزش تا ایندکس را بخوانید.
  2. کاهش سرعت موقت: اگر DNS جدید کند باشد، Core Web Vitals تحت تأثیر قرار می‌گیرد و روی رتبه اثر می‌گذارد. برای اصول، Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد را ببینید.
  3. مشکل SSL و HTTPS: اگر گواهی SSL در سرور جدید آماده نباشد، مرورگرها هشدار می‌دهند و گوگل نسخه‌ی HTTPS را از دست می‌دهد. رابطه‌ی HTTPS و سئو را در HTTPS چه تاثیری بر سئو و رتبه Google دارد باز کرده‌ام.
DNS خودش روی رتبه اثری ندارد؛ اما زیرساخت سرعت، دسترسی و امنیت را می‌سازد — و این سه، روی رتبه اثر دارند. یعنی اثر DNS، غیرمستقیم اما واقعی است.

اثر بر ایمیل و رکوردهای MX، SPF، DKIM

یکی از پرتکرارترین فاجعه‌هایی که در تغییر DNS می‌بینم، فراموش‌کردن رکوردهای ایمیل است. اگر هنگام تغییر Nameserver، رکوردهای MX (Mail Exchange)، SPF (Sender Policy Framework)، DKIM (DomainKeys Identified Mail) و DMARC (Domain-based Message Authentication, Reporting and Conformance) به سرویس جدید منتقل نشوند، تمام ایمیل‌های سازمانی از کار می‌افتند یا در اسپم گیر می‌کنند.

پیش از هر تغییری، فهرست کامل رکوردهای فعلی را از سرویس DNS قدیمی export کنید. حتی اگر تصور می‌کنید همه‌ی رکوردها را می‌شناسید، رکوردهایی وجود دارند که مدتی است به آن‌ها فکر نکرده‌اید: رکوردهای تأیید دامنه برای سرویس‌های شخص ثالث، رکوردهای CNAME برای سرویس‌های SaaS و رکوردهای TXT برای ابزارهای مختلف. هر رکوردی که فراموش کنید، ممکن است یک سرویس را قطع کند.

برای درک بهتر نقش هر رکورد، رکوردهای DNS کدامند و برای ایمیل تخصصی، مقالات مربوط به SPF و DMARC را در سایت دنبال کنید.

اثر بر SSL، HTTPS و اعتماد مرورگر

بسیاری از گواهی‌های SSL به نام دامنه صادر می‌شوند و مستقل از DNS هستند. اما اگر سرور جدیدی که DNS به آن اشاره می‌کند، گواهی درست نصب نکرده باشد، مرورگرها هشدار امنیتی می‌دهند. در بازه‌ی پروپاگیشن، ممکن است برخی کاربران به سرور قدیم (با گواهی درست) و برخی به سرور جدید (بدون گواهی) برسند و تجربه‌ی ناهمگونی داشته باشند.

قاعده‌ی ساده: پیش از تغییر DNS، مطمئن شوید سرور جدید گواهی SSL معتبر دارد، زنجیره‌ی گواهی کامل است، و ریدایرکت HTTP به HTTPS درست تنظیم شده. برای بررسی، چگونه اعتبار SSL را بررسی کنیم چک‌لیست دقیقی دارد. اگر از Wildcard SSL استفاده می‌کنید، SSL Wildcard چیست و چه زمانی به آن نیاز داریم را هم ببینید.

انواع تغییر DNS و اثر خاص هر کدام

هر تغییر DNS، اثر خاص خودش را دارد. جدول زیر، مقایسه‌ی سریعی از سناریوهای رایج است:

نوع تغییرسطح ریسکاثر اصلی
تغییر A Record به IP جدیدپایینپروپاگیشن با TTL، ریسک محدود
تغییر CNAME ساب‌دامینپایینمشابه A Record، اما وابسته به مقصد
تغییر Nameserverبالاریسک از دست رفتن رکوردها، outage طولانی
تغییر MXمتوسطقطع یا تأخیر در ایمیل
افزودن/حذف TXT (SPF/DKIM)پاییناثر فقط روی Deliverability ایمیل
افزودن رکورد جدید (مثل زیرساخت سرویس)پایینبدون اثر مخرب، فقط گسترش

اگر در حال تغییر Nameserver هستید، حتماً تفاوت DNS و Nameserver چیست را بخوانید تا تفاوت این دو عملیات را دقیق درک کنید. در مواردی که DNS از یک ثبت‌کننده به ثبت‌کننده‌ی دیگر منتقل می‌شود، فرآیند مشابه است و در انتقال دامنه چگونه انجام می‌شود توضیح داده‌ام.

پرسش‌های پرتکرار درباره تغییر DNS

چقدر طول می‌کشد تا تغییر DNS روی همه اثر بگذارد؟ به TTL بستگی دارد. با TTL ۳۰۰ ثانیه، تغییر در یک ساعت روی اکثر کاربران اعمال می‌شود. با TTL ۸۶۴۰۰ ثانیه، ممکن است تا ۴۸ ساعت طول بکشد. برای کاهش این زمان، پیش از تغییر، TTL را کاهش دهید. جزئیات بیشتر در پروپاگیشن DNS چیست و چقدر طول می‌کشد.

آیا تغییر DNS باعث افتی در رتبه گوگل می‌شود؟ به‌طور مستقیم نه. اما اگر همراه با downtime، کاهش سرعت یا مشکل SSL باشد، رتبه به‌طور غیرمستقیم آسیب می‌بیند. تغییر را در ساعات کم‌ترافیک انجام دهید و سایت را در روزهای بعد پایش کنید.

آیا باید قبل از تغییر DNS بکاپ بگیرم؟ بله، و نه فقط بکاپ فایل‌ها. از پیکربندی DNS فعلی هم بکاپ بگیرید. بکاپ DNS یعنی عکس‌برداری از همه‌ی رکوردها؛ اگر تغییر اشتباه باشد، بازگشت سریع ممکن می‌شود. در پنل‌های DNS مدرن مثل Cloudflare، این گزینه به‌صورت Export Zone File وجود دارد.

آیا می‌توانم DNS را فقط برای برخی کاربران تغییر دهم؟ نه به‌طور دقیق. اما با استفاده از GeoDNS یا Split-Horizon DNS می‌توانید پاسخ‌های متفاوتی برای مناطق مختلف تنظیم کنید. این تکنیک در تست‌های بزرگ و مهاجرت‌های تدریجی کاربرد دارد.

اگر بعد از تغییر DNS سایت کار نکرد، چه کنم؟ اول با dig یا nslookup بررسی کنید که رکوردهای جدید درست منتشر شده‌اند. اگر رکوردها درست هستند اما سایت کار نمی‌کند، مسئله در سرور مقصد است، نه DNS. مراحل کامل عیب‌یابی در چگونه DNS را عیب‌یابی کنیم.

آیا Cloudflare یا سرویس‌های DNS ابری، این ریسک‌ها را کمتر می‌کنند؟ بله، به چند دلیل. اول، تغییر در سرویس‌های ابری معمولاً با رابط کاربری روشن و پشتیبانی از Import کامل Zone انجام می‌شود. دوم، چون این سرویس‌ها از هر نقطه‌ی جهان پاسخ می‌دهند، پروپاگیشن سریع‌تر است. مفهوم DNS ابری را در DNS ابری چیست و چه تفاوتی با DNS سنتی دارد باز کرده‌ام.

چطور بفهمم DNS امن‌تر است؟ سه نشانه: پشتیبانی از DNSSEC، استفاده از Anycast، و داشتن رابط API برای اتوماسیون. برای اصول امنیت DNS، DNS امن چیست و چه مزایایی دارد را ببینید.

چک‌لیست پیش و پس از تغییر DNS

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

پیش از تغییر:

  1. Export کامل Zone File از سرویس فعلی.
  2. کاهش TTL به ۳۰۰ ثانیه، حداقل ۲۴ ساعت پیش از تغییر.
  3. آماده‌سازی سرور یا سرویس مقصد و تست کامل آن با IP مستقیم.
  4. اطمینان از معتبر بودن SSL در سرور جدید.
  5. اطمینان از انتقال کامل رکوردهای MX، SPF، DKIM و DMARC.
  6. اطمینان از انتقال رکوردهای TXT تأیید سرویس‌های جانبی.

پس از تغییر:

  1. بررسی انتشار با ابزارهای Multiple DNS Check.
  2. پایش TTFB و Core Web Vitals در ۴۸ ساعت اول.
  3. بررسی inbox ایمیل سازمانی و ارسال تستی.
  4. پایش Google Search Console در هفته‌ی اول برای خطاهای خزش.
  5. بازگرداندن TTL به مقدار قبلی پس از تثبیت.

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

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