آموزش گام‌به‌گام تنظیمات DNS سایت؛ از رکوردها تا انتشار

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

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

تنظیمات DNS سایت را از کجا شروع کنیم؟

شروع درست از سه پرسش است، نه از پنل‌بازی. پرسش اول: رکوردهای دامنهٔ من کجا نگهداری می‌شوند؟ پاسخ را نِیم‌سرورها می‌دهند؛ هر جا که نِیم‌سرور نشان می‌دهد، همان پنل محل ویرایش است — گاهی ثبت‌کنندهٔ دامنه و گاهی هاست. پرسش دوم: امروز چه رکوردهایی دارم و هرکدام به کجا اشاره می‌کنند؟ فهرست‌برداری قبل از هر تغییری است. پرسش سوم: تغییر بعدی من چیست — اتصال به هاست جدید، زیردامنه، ایمیل سازمانی یا تأیید یک ابزار؟ هر تغییر، مسیر رکورد متفاوتی دارد.

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

رکوردهای پایه؛ A و CNAME و MX چه می‌کنند؟

رکورد A جادهٔ اصلی وب است: دامنه را به آدرس IP سرور می‌بندد. اگر سایت با «دامنهٔ بدون www» باز نمی‌شود یا به هاست قدیمی می‌رود، اولین مظنون همین رکورد است؛ مقدار آن باید IP فعلی هاست باشد و هر جا هاست عوض شد، عوض‌شدنش اولین کار است.

رکورد CNAME نام‌به‌نام است: زیردامنه‌ای مثل www یا آدرس‌های سرویس‌های بیرونی را به نام دیگری اشاره می‌کند، نه به IP خام؛ وقتی مقصد عوض شود فقط یک نام به‌روز می‌شود. کاربرد رایج دوم، اتصال زیردامنه یا مسیر محتوا به شبکهٔ تحویل محتواست؛ اینکه برای بازار ایران کدام CDN منطقی‌تر است، مقایسهٔ جداگانه‌ای دارد که در مقایسهٔ CDN ایرانی یا جهانی برای وردپرس با سنجه‌ها باز شده است. قاعدهٔ مهم: رکورد A و CNAME برای یک نام هم‌زمان تعریف نکنید؛ یکی باید حاکم باشد.

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

TTL؛ چرا پیش از هر تغییر باید کوتاه شود؟

TTL مدت اعتبار پاسخ DNS در حافظهٔ موقت است؛ یعنی تغییر شما چقدر بعد «دیده شدن» طول می‌کشد. TTL بلند یعنی تغییر کند اعمال می‌شود و برگشتِ اشتباه هم کندتر است؛ TTL کوتاه یعنی تغییر سریع دیده می‌شود به‌بهای پرس‌وجوی بیشتر. پنل‌ها اغلب مقداری در حد یک ساعت پیش‌فرض می‌گذارند، اما رکوردهای دست‌نخوردهٔ قدیمی گاهی TTL چندروزه دارند و صاحب سایت بی‌خبر است.

قاعدهٔ امن ما ساده است: بیست‌وچهار ساعت قبل از هر تغییر برنامه‌ریزی‌شده — مهاجرت هاست، جابه‌جایی سرویس ایمیل، اتصال CDN — TTL رکوردهای درگیر را به حداقل معقول کوتاه کنید، تغییر را اعمال کنید و بعد از پایداری، دوباره به مقدار متعادل برگردانید. کوتاهِ دائمی لازم نیست؛ کوتاهِ برنامه‌ریزی‌شده است که انعطاف می‌دهد. ترتیب دقیق همین کار در سناریوی مهاجرت، در رویهٔ انتقال هاست بدون قطعی و تنزل TTL قدم‌به‌قدم آمده است.

یک ظرافت که در پروژه‌ها می‌بینیم: TTL هر رکورد مستقل است؛ کوتاه‌کردن رکورد A رکورد MX را کوتاه نمی‌کند. برگهٔ تغییر شما باید TTL «همهٔ رکوردهای درگیر» را لیست کند، نه فقط رکورد اصلی؛ همین است که «چرا هنوز اعمال نشده؟» را توضیح می‌دهد.

گام‌به‌گام؛ از پیدا کردن پنل DNS تا انتشار رکورد

حالا ترتیب اجرا. گام اول: از نِیم‌سرورها محل نگهداری رکوردها را پیدا کنید و وارد پنل درست شوید؛ اگر نِیم‌سرور به هاست اشاره می‌کند، پنل DNS ثبت‌کننده فقط پردهٔ بعدی است. گام دوم: فهرست فعلی رکوردها را با نوع، مقدار و TTL در برگهٔ تغییر کپی کنید — همین نسخه، نقشهٔ برگشت است. گام سوم: رکورد A دامنهٔ اصلی را به IP هاست مقصد ثبت کنید. گام چهارم: CNAME را برای www و زیردامنه‌های فعال تنظیم کنید و مطمئن شوید هیچ نامی دوتا رکورد متناقض ندارد. گام پنجم: MX و TXT را در صورت نیاز به تغییر، با برنامهٔ ایمیل جداگانه اعمال کنید و بعد از انتشار، راستی‌آزمایی را شروع کنید.

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

رکوردهای تأیید و ایمیل؛ TXT و SPF و سرچ‌کنسول

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

نقش دوم TXT، سیاست‌های ضدجعل ایمیل است: رکوردهایی که اعلام می‌کنند کدام سرویس‌ها اجازهٔ ارسال ایمیل به‌نام دامنهٔ شما را دارند. بدون این رکوردها، ایمیل‌های قانونی شما هم احتمال رفتن به پوشهٔ اسپم مخاطب را بالا می‌برند؛ با آن‌ها، ارسال از سرویس درست مهر تأیید می‌گیرد. تنظیم دقیق‌شان فنی است و به سرویس ایمیل شما بستگی دارد؛ هر وقت ایمیل‌ها ناگهان به اسپم رفت، اولین سؤال به‌روز بودن همین رکوردهاست.

نکتهٔ نگهداری: این لایه دیر فرسوده می‌شود و به همین دلیل در تغییرها فراموش می‌شود. هر بار که سرویس ارسال ایمیل یا ابزار تأیید عوض می‌کنید، رکوردهای TXT قدیمی را در همان جلسه بازبینی کنید و مقدار رکورد سرویس فعال را با مستندات همان سرویس هم‌خوان نگه دارید.

چهار خطای رایج و تشخیص انتشار با ابزار

چهار خطای پرتکرار را می‌شود با چهار نشانه تشخیص داد. خطای اول، رها شدن www: دامنهٔ اصلی باز می‌شود و www به خطای گواهی یا صفحهٔ پیش‌فرض می‌رسد؛ علت، نبود یا متناقض بودن CNAME است. خطای دوم، دو رکورد A هم‌زمان با رفتار متفاوت در باز شدن‌ها؛ یکی را نگه دارید و بقیه را حذف کنید. خطای سوم، ایمیلِ ساکت: سایت سالم اما صندوق گم؛ رکورد MX را با فهرست قبلی مقایسه کنید. خطای چهارم، تغییرِ «اعمال‌نشده»: شما اصلاح کرده‌اید اما دنیا نسخهٔ قدیمی می‌بیند؛ حافظهٔ موقت و TTL بلند مظنون اصلی است.

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

جمع‌بندی؛ برگهٔ چک و ترتیب امن تغییر

جمع‌بندی اجرایی، همان سه سطر است که از اول قولش را دادیم: فهرست رکوردها قبل از تغییر، کوتاه‌سازی TTL قبل از تغییر برنامه‌ریزی‌شده، و راستی‌آزمایی ابزاری بعد از انتشار — با ترتیب وب، زیردامنه، ایمیل. این برگه را برای دامنهٔ خودتان یک بار آماده کنید و در هر تغییر به‌روز کنید؛ به تجربهٔ ما همین سند یک‌صفحه‌ای، فاصلهٔ بین «تغییر آرام» و «قطعی نیم‌روزی» است و برای تیم‌های کوچک جایگزین تجربهٔ سال‌ها کار می‌شود.

دو مسیر بعدی هم روشن است: اگر تغییر بعدی‌تان مهاجرت هاست است، رویهٔ کامل در رویهٔ انتقال هاست بدون قطعی و تنزل TTL آمده و اگر زیرساخت فنی‌تان نیاز به نگاه سراسری دارد، ممیزی رایگان دامنه وضعیت فعلی دامنه را نشان می‌دهد. و چون این مقاله آموزشی است و اجرایش بر عهدهٔ تیم خودتان، از درون پنل هم می‌توانید کارهای تکراری انتشار را به لایهٔ اجرا بسپارید؛ پلن‌ها و کارهای قابل واگذاری در قیمت‌های شفاف پلن‌های سوئیت با عدد شفاف آمده است — تصمیم‌اش را بعد از ممیزی بگیرید، نه قبل از آن.

رصد ما، رشد شما.