رکورد را عوض کرده‌اید، dig از سرور خودتان جواب جدید می‌دهد، ولی مشتری هنوز سایت قدیمی را می‌بیند. یا برعکس: TTL را روی ۳۰۰ گذاشته‌اید و بعد از هر تغییر، نیم ساعت درگیری دارید. هر دو حالت یک ریشه دارند: عددی که در ستون TTL نوشته‌اید با کاری که واقعاً می‌کنید هم‌خوان نیست. مقدار TTL یک عدد ساده نیست؛ قراردادی است بین شما و هر resolver روی اینترنت.
مقدار TTL دقیقاً به چه کسی دستور می‌دهد
TTL واحدش ثانیه است و به resolverهای میانی می‌گوید این پاسخ را چند ثانیه می‌توانند بدون پرسیدن دوباره، معتبر بدانند. توجه کنید که این عدد به مرورگر یا سیستم‌عامل کاربر دستور نمی‌دهد؛ آن‌ها کش خودشان را دارند و بعضی مرورگرها مستقل از TTL عمل می‌کنند. پس وقتی می‌گویید «TTL را کم کردم ولی هنوز کش است»، احتمالاً دارید به لایه‌ای نگاه می‌کنید که این عدد را نمی‌خواند.
نکته دوم که کمتر گفته می‌شود: TTL مؤثر همیشه عدد شما نیست. resolverها حق دارند مقدار کمتری اعمال کنند و برخی ISPها سقف داخلی خودشان را دارند. اگر TTL را ۳۰ بگذارید، تضمینی نیست همه جا ۳۰ ثانیه بماند؛ فقط سقف را تعیین کرده‌اید، نه کف را.
بازه منطقی برای هر نوع رکورد
یک عدد جهانی وجود ندارد. جدول زیر بازه‌ای است که در عمل جواب می‌دهد:
| نوع رکورد | TTL پیشنهادی | دلیل |
|---|---|---|
| A / AAAA سرور پایدار | ۳۶۰۰ تا ۸۶۴۰۰ | تغییر کم، کش طولانی بار resolver را کم می‌کند |
| CNAME سرویس ابری | ۳۰۰ تا ۱۸۰۰ | مقصد ممکن است بدون اطلاع شما عوض شود |
| MX | ۳۶۰۰ | سرورهای ایمیل به TTL حساس‌اند و کش طولانی جلوی از دست رفتن نامه را می‌گیرد |
| TXT (SPF، تأیید دامنه) | ۳۰۰ تا ۳۶۰۰ | تغییرات دوره‌ای، ولی نه لحظه‌ای |
| NS در ناحیه والد | ۸۶۴۰۰ | تغییر نادر؛ کاهش آن ریسک بی‌دلیل است |
| رکورد در حال مهاجرت | ۶۰ تا ۳۰۰ | فقط بهصورت موقت، پیش از تغییر |
برای رکورد A یک سرور ثابت، ۳۶۰۰ ثانیه نقطه شروع معقولی است. اگر ترافیک سایت بالاست و resolverهای زیادی درگیرند، ۸۶۴۰۰ هم منطقی است. اما اگر همین رکورد را روی ۶۰ بگذارید، هر بازدیدکننده تقریباً هر دقیقه یک پرسش تازه به authoritative شما می‌زند. روی یک سرور DNS ضعیف، این عدد کوچک بهصورت مستقیم در CPU و پهنای باند دیده می‌شود.
کاهش TTL قبل از تغییر، نه بعد از آن
این‌جا اشتباه می‌کنند: رکورد را عوض می‌کنند و بعد TTL را کم می‌کنند. ترتیب درست برعکس است. اگر TTL فعلی ۸۶۴۰۰ است و فردا می‌خواهید IP را عوض کنید، امروز آن را به ۳۰۰ برسانید و صبر کنید به اندازه TTL قبلی بگذرد. یعنی حدود یک روز. بعد تغییر را اعمال کنید. اگر این کار را نکنید، resolverهایی که پاسخ قدیمی را با TTL یک‌روزه کش کرده‌اند تا پایان همان بازه به شما جواب قدیمی می‌دهند و هیچ راهی برای باطل کردن اجباری آن کش ندارید.
علامتش هم این است: نصف کاربران سایت جدید را می‌بینند، نصف دیگر نه. بعضی‌ها از موبایل درست می‌بینند و از وای‌فای خانه نه. این پراکندگی نشانه TTL بلندِ باقی‌مانده است، نه مشکل سرور.
هزینه‌ای که کم‌کردن TTL دارد
وسوسه‌ای که باید در برابر آن مقاومت کرد این است که TTL را همیشه پایین نگه داریم تا «همیشه آماده تغییر باشیم». هزینه‌اش را resolverها و سرور DNS شما می‌پردازند. با TTL ۶۰ ثانیه روی دامنه‌ای با ترافیک متوسط، بار پرسش روی authoritative چند برابر می‌شود و اگر آن سرور روی همان ماشینی باشد که سایت را سرو می‌کند، در بدترین لحظه به خودتان حمله کرده‌اید.
پس انتخاب من روشن است: برای رکوردهای پایدار TTL بلند بگذارید و فقط در پنجره مهاجرت آن را کوتاه کنید. تنها موردی که پایین نگه‌داشتن دائمی را توجیه می‌کند، رکوردی است که واقعاً بهصورت خودکار و مکرر بازنویسی می‌شود؛ مثل رکورد A یک سرویس با IP پویا یا زیردامنه‌ای که با اسکریپت به‌روز می‌شود. اگر ساختار زیردامنه‌های پویا دارید، پیش از انتخاب عدد، رفتار رکورد wildcard را هم در نظر بگیرید؛ رکورد wildcard و مدیریت زیردامنه‌های پویا در DNS دقیقاً همین سناریو را پوشش می‌دهد.
چطور مقدار واقعی را ببینید، نه مقداری که فکر می‌کنید
پاسخ authoritative و پاسخ resolver را جدا بپرسید. این دو عدد اغلب یکی نیستند:
dig +noall +answer example.com A
dig @1.1.1.1 +noall +answer example.com A
dig @ns1.example.com +noall +answer example.com Aستون آخر خروجی همان TTL باقی‌مانده است. اگر از سرور authoritative عدد ۳۶۰۰ گرفتید و از resolver عدد ۲۴۰۰، یعنی آن resolver پاسخ را ۱۲۰۰ ثانیه پیش گرفته و ۲۴۰۰ ثانیه دیگر نگه می‌دارد. برای دیدن مسیر کامل و اینکه کدام سرور پاسخ می‌دهد، dig +trace example.com را اجرا کنید. اگر خروجی این دستورها برایتان گیج‌کننده است، بررسی رکوردهای DNS نقطه شروع سریع‌تری است.
یک نکته عملی: بعد از هر تغییر، مقدار TTL را در خروجی dig چک کنید. اگر عددی که می‌بینید با پنل نمی‌خواند، احتمالاً رکورد را در ناحیه اشتباه یا روی سرویس DNS دیگری ویرایش کرده‌اید. این حالت بیشتر از آنچه فکر می‌کنید پیش می‌آید، مخصوصاً وقتی دامنه از یک ثبت‌کننده خریده شده و ناحیه روی سرویس دیگری میزبانی می‌شود.
TTL و رکوردهای حساس به ایمیل
برای MX، عدد کوچک ریسک واقعی دارد. اگر TTL را روی ۶۰ بگذارید و سرور ایمیل شما برای چند دقیقه از دسترس خارج شود، فرستنده‌ها سریع‌تر متوجه تغییر می‌شوند و ممکن است نامه را به مسیر اشتباه بفرستند یا موقتاً رد کنند. ۳۶۰۰ برای MX انتخاب متعادلی است. برای رکوردهای TXT مربوط به SPF و DKIM هم ۳۰۰ تا ۳۶۰۰ کافی است؛ فقط یادتان باشد بعضی سرویس‌های ایمیل هنگام تأیید دامنه، مقدار کش‌شده قدیمی را می‌خوانند و چند ساعت طول می‌کشد تا تغییر را ببینند.
اگر دامنه‌تان .ir است، یک لایه اضافه هم دارید: تغییرات ناحیه ممکن است از مسیر ایرنیک عبور کند و زمان‌بندی آن مستقل از TTL شما باشد. جزئیات این مسیر در راهنمای کامل ثبت و مدیریت دامنه ir با شناسه ایرنیک آمده است.
خطاهایی که در لاگ سرور DNS دیده می‌شوند
وقتی TTL را خیلی کوتاه می‌کنید، معمولاً اولین نشانه در لاگ نیست؛ در بار سرور است. اما اگر ناحیه را دستی ویرایش می‌کنید، این خطاها را جدی بگیرید:
SERVFAILبعد از ویرایش ناحیه: تقریباً همیشه خطای نگارشی است، نه TTL. شماره سریال (SOA serial) را فراموش کرده‌اید یا نقطه آخر نام میزبان را جا انداخته‌اید.NXDOMAINبرای زیردامنه‌ای که وجود دارد: رکورد در ناحیه‌ای ثبت شده که سرور authoritative برای آن پاسخ نمی‌دهد.- پاسخ قدیمی با TTL بالا از یک resolver خاص: کش آن resolver هنوز منقضی نشده. صبر کنید یا از resolver دیگری تست بگیرید.
ترتیب درست بررسی این نشانه‌ها را در راهنمای عملی عیب‌یابی DNS: نشانه‌ها و ترتیب بررسی رکوردها نوشته‌ایم؛ در بیشتر موارد مشکل TTL نیست و رکورد اشتباه ثبت شده است.
عدد نهایی که پیشنهاد می‌کنم
برای یک دامنه معمولی با سایت روی سرور ثابت: A و AAAA روی ۳۶۰۰، MX روی ۳۶۰۰، CNAME روی ۱۸۰۰، TXT روی ۳۶۰۰، NS روی ۸۶۴۰۰. پیش از هر مهاجرت، رکورد مورد نظر را به ۳۰۰ برسانید، به اندازه TTL قبلی صبر کنید، تغییر را اعمال کنید و بعد از تثبیت، عدد را برگردانید. اگر سایت پرمخاطبی دارید و سرور DNS شما روی همان ماشین سایت است، TTL بلند نه فقط بهینه‌سازی، بلکه محافظت از خودتان است.
اگر دامنه را تازه ثبت می‌کنید یا ناحیه را از صفر می‌سازید، از همان ابتدا این اعداد را درست بگذارید؛ اصلاح بعدی همیشه گران‌تر از تنظیم اولیه است. برای دامنه‌های جدید می‌توانید از جستجو و ثبت دامنه شروع کنید و ناحیه را با همین پیش‌فرض‌ها بچینید.
پرسش‌های پرتکرار
حداقل مقدار TTL چقدر میتواند باشد؟
از نظر فنی صفر هم مجاز است، ولی در عمل هیچ resolverی هر پرسش را دوباره نمی‌پرسد و اکثرشان کف داخلی چند ثانیه‌ای دارند. مقدار زیر ۶۰ ثانیه تقریباً هیچ سود عملی ندارد و فقط بار سرور DNS را بالا می‌برد.
چرا بعد از تغییر TTL هنوز سایت قدیمی را می‌بینم؟
چون TTL قبلی هنوز در کش resolverها باقی است. کاهش TTL فقط روی پاسخ‌های بعدی اثر می‌گذارد و پاسخ‌های کش‌شده تا پایان عمر خودشان معتبر می‌مانند. باید به اندازه TTL قبلی صبر کنید.
آیا TTL روی رتبه سایت در گوگل اثر دارد؟
بهصورت مستقیم نه. اما TTL خیلی کوتاه میتواند زمان پاسخ DNS را کمی بالا ببرد و در شرایط بار سنگین، کندی محسوس ایجاد کند. اثر آن غیرمستقیم و در حد چند میلیثانیه است، نه یک عامل رتبهبندی مستقل.
برای مهاجرت سرور، TTL را چند ساعت قبل کم کنم؟
به اندازه TTL فعلی، نه یک عدد ثابت. اگر TTL روی ۸۶۴۰۰ است، حداقل ۲۴ ساعت قبل کم کنید. اگر روی ۳۶۰۰ است، یک ساعت کافی است. قاعده ساده: زمان انتظار برابر است با TTL قبلی، نه TTL جدید.