چگونه سرعت DNS را بهبود دهیم؟ راهنمای عملی کاهش تأخیر نام‌دامنه

اولین بار که فهمیدم DNS (Domain Name System یا سیستم نام‌دامنه) می‌تواند سرعت سایت را این‌قدر تعیین کند، در یک پروژهٔ فروشگاهی بود؛ سرور سریع، کش فعال، تصاویر بهینه، اما کاربران از کندی در موبایل گلایه داشتند. بررسی که کردم، مقصر یک رزولور (DNS Resolver) کند روی زیرساخت بعضی ISPها بود. آن روز یاد گرفتم سرعت، فقط سرور و قالب و کش نیست؛ مسیر رسیدن کاربر به سرور هم نقش دارد. این نوشته، همان تصمیم‌های کوچک و بزرگی را باز می‌کند که در نهایت، تجربهٔ لود اول سایت را تعیین می‌کنند.

DNS چطور روی سرعت سایت اثر می‌گذارد؟

پیش از آن‌که مرورگر به سرور سایت شما وصل شود، باید نشانی دامنه (مثل example.com) را به یک نشانی IP تبدیل کند. این کار، وظیفهٔ DNS است. هر بار که مرورگر نمی‌داند این نگاشت چیست، باید از یک سری سرور، پاسخ را بپرسد؛ و هر پرسش، زمان می‌برد. اگر این زمان به‌درستی مدیریت نشود، بخش قابل‌توجهی از زمانِ لود اول سایت، پیش از تماس با سرور شما هدر می‌رود.

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

هر میلی‌ثانیه‌ای که در لایهٔ DNS هدر می‌رود، مستقیم به زمان LCP و به تجربهٔ موبایل کاربر اضافه می‌شود — و هیچ کش صفحه‌ای، آن را برنمی‌گرداند.

چهار مرحله‌ای که در آن‌ها تأخیر پنهان می‌شود

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

1. کش محلی مرورگر و سیستم‌عامل: اگر نشانی در کش مرورگر باشد، پرسش DNS اصلاً فرستاده نمی‌شود. این سریع‌ترین حالت است.
2. رزولور کاربر (Resolver): معمولاً رزولور ISP یا یکی از رزولورهای عمومی مثل 1.1.1.1 و 8.8.8.8. اگر رزولور در کش خود پاسخ را داشته باشد، در چند میلی‌ثانیه جواب می‌دهد.
3. سرورهای Authoritative: اگر رزولور پاسخ را نداشته باشد، به سرورهای مرجع دامنهٔ شما مراجعه می‌کند. سرعت پاسخ این سرورها، وابسته به زیرساخت ارائه‌دهندهٔ DNS شماست.
4. مراحل بازگشتی (Recursive Query): اگر رزولور مسیر کامل را طی کند (Root، TLD، سپس Authoritative)، این مسیر می‌تواند در بدترین حالت، چند صد میلی‌ثانیه طول بکشد.

نکتهٔ حیاتی این است: شما فقط روی مرحلهٔ سوم (انتخاب ارائه‌دهندهٔ DNS) کنترل مستقیم دارید. مراحل اول و دوم، به کاربر و زیرساخت اینترنت او بستگی دارد. با این حال، انتخاب درست در مرحلهٔ سوم، می‌تواند اثر غیرمستقیمی روی مراحل دیگر بگذارد. چطور؟ ارائه‌دهندهٔ DNS سریع، پاسخ‌ها را در رزولورهای پرکاربر کش می‌کند و احتمال برخورد با کش گرم را بالا می‌برد.

انتخاب رزولور سریع؛ اولین گام عملی

شما نمی‌توانید رزولور کاربر را تغییر دهید، اما می‌توانید رزولوری که خودتان در پروژه‌های توسعه استفاده می‌کنید، بهینه کنید. این تغییر، در سه جا به کار می‌آید: اول، تست‌هایی که خودتان می‌گیرید، دقیق‌تر می‌شوند؛ دوم، ابزارهای مانیتورینگ از بیرون، سریع‌تر به نتیجه می‌رسند؛ سوم، در برخی هاست‌ها تنظیمات داخلی DNS به رزولور انتخابی شما وابسته است. رزولورهای عمومی معروف از نظر سرعت و پایداری، تفاوت‌های معناداری دارند. جدول زیر سنجه‌های تجربی من است (میانگین در سه موقعیت شبکه‌ای متفاوت):

نکته‌ای که در تست‌ها بارها دیدم: انتخاب رزولور عمومی روی کاغذ «سریع‌تر» است، اما در شبکهٔ محلی، رزولور ISP می‌تواند سریع‌تر باشد چون فاصلهٔ شبکه‌ای کوتاه‌تری طی می‌کند. بهترین رویکرد، تست این دو در شبکهٔ واقعی و انتخاب بر اساس داده است، نه توصیه‌های عمومی. ابزارهای معتبر برای این تست را در ابزارهای تست سرعت سایت کدامند؟ فهرست کرده‌ام؛ اگر نمی‌خواهید درگیر ابزارهای اضافه شوید، دستور dig یا nslookup با پارامتر زمان، در ترمینال، شروع خوبی است.

Anycast DNS و تفاوت آن با DNS معمولی

سرعت DNS، مستقیماً به فاصلهٔ شبکه‌ای بین رزولور کاربر و سرور Authoritative وابسته است. یکی از مؤثرترین راهکارهای کاهش این فاصله، استفاده از Anycast DNS است. در این مدل، یک نشانی IP واحد از چندین نقطهٔ جغرافیایی جهان، به‌طور هم‌زمان سرو می‌شود و کاربر به نزدیک‌ترین نقطه، وصل می‌شود. نتیجه: تأخیر کمتر، مقاومت بیشتر در برابر حمله‌های DDoS (Distributed Denial of Service) روی سرویس DNS، و پایداری بالاتر در زمان اختلالات منطقه‌ای.

پروایدرهای DNS حرفه‌ای، تقریباً همه از Anycast استفاده می‌کنند. تفاوت بیشتر در تعداد نقاط حضور و کیفیت مسیرهاست. اگر مخاطب سایت شما عمدتاً ایرانی است، بررسی این‌که ارائه‌دهنده، در منطقهٔ خاورمیانه یا ترکیه/امارات نقطهٔ حضور دارد یا نه، تفاوت معناداری در تأخیر ایجاد می‌کند. اگر دربارهٔ تفاوت Anycast با رزولور معمولی سؤال دارید، توصیه می‌کنم این تفاوت را به‌عنوان بخشی از بحث معماری در نظر بگیرید، نه یک تصمیم تاکتیکی.

انتخاب ارائه‌دهندهٔ DNS مثل انتخاب محل شعبه است: نزدیک‌ترین شعبه به مشتری، همیشه سریع‌ترین خدمت را می‌دهد.

تنظیم TTL؛ تعادل میان کش و انعطاف

TTL (Time to Live یا زمان زنده‌ماندن) عددی است که به رزولورها می‌گوید پاسخ را چند ثانیه در کش نگه دارند. این عدد، یک تعادل ظریف است:

• TTL بالا (چند ساعت): رزولورها پاسخ را طولانی‌تر کش می‌کنند و بار روی سرور Authoritative کمتر می‌شود. خوب است وقتی IP شما ثابت است.
• TTL پایین (چند دقیقه): هنگام مهاجرت یا تغییر IP، سرعت انتشار بالا می‌رود. اما بار روی سرور Authoritative بیشتر می‌شود و هر پرسش، تازه‌سازی می‌خواهد.

قاعدهٔ عملی من: در حالت عادی روی ۳۶۰۰ ثانیه (یک ساعت) نگه دارید؛ قبل از هر مهاجرت، آن را به ۳۰۰ ثانیه کاهش دهید؛ بعد از تثبیت مهاجرت، دوباره به مقدار اولیه برگردانید. این ساده‌ترین راه برای بهره‌گیری از هر دو دنیا است. اگر TTL و نقش آن در کش را کامل‌تر می‌خواهید، مقالهٔ اختصاصی‌اش در نوشته‌های دیگر این مجموعه آمده است. یک هشدار تجربی: تغییر TTL را در بازهٔ پرترافیک انجام ندهید؛ همین تغییر کوچک، در پروژه‌ای که حواسم نبود، یک بازهٔ کوتاه کندی سایت را رقم زد.

کش DNS محلی و سمت سرور

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

کش سمت کاربر: مرورگر و سیستم‌عامل، هر پاسخ را برای مدتی نگه می‌دارند. این کش را نمی‌توانید مستقیم کنترل کنید، اما می‌توانید روی به‌روزرسانی آن اثر بگذارید. اگر می‌خواهید ببینید چه زمان، کش‌های محلی شکسته می‌شوند، بخش انتشار (Propagation) در مقالات مربوط به تغییر DNS، توضیح دقیق دارد. مدت انتظار معمول بین ۱ تا ۲۴ ساعت است، هرچند در اکثر موارد، کش‌ها در چند ساعت به‌روز می‌شوند.

کش سمت سرور: اگر سرور خودتان (نه هاست اشتراکی) مدیریت می‌کنید، می‌توانید یک کش رزولور محلی (مثل systemd-resolved یا unbound) راه‌اندازی کنید. این کار، درخواست‌های تکراری از داخل سرور به مقصد دامنه‌های خارجی را در چند میلی‌ثانیه پاسخ می‌دهد و بار روی رزولورهای عمومی را کم می‌کند. روی هاست‌های اشتراکی معمولاً این دسترسی وجود ندارد؛ روی VPS (Virtual Private Server) یا سرور اختصاصی، ارزشش را دارد.

نقش CDN در سرعت DNS و لود اول

CDN (Content Delivery Network یا شبکهٔ تحویل محتوا) از دو زاویه به سرعت DNS کمک می‌کند. اول، فایل‌های استاتیک را از سرورهای نزدیک به کاربر سرو می‌کند و بخشی از فشار روی دامنهٔ اصلی را جابه‌جا می‌کند. دوم، خودِ DNS را از طریق شبکهٔ Anycast خود مدیریت می‌کند که در پروایدرهای حرفه‌ای، سریع‌تر از DNS معمولی هاست است. اگر سایت شما به مخاطب جغرافیایی پراکنده سرو می‌دهد، این ترکیب می‌تواند تفاوت معناداری در زمان لود اول بسازد. روش راه‌اندازی و تنظیمات CDN، خودش یک مقالهٔ جداگانه است که در همین مجموعه به‌طور کامل پوشش داده شده؛ اما در نگاه کلی، CDN را نه به‌عنوان «آپشن لوکس»، که به‌عنوان «لایهٔ جدی سرعت» ببینید.

اگر می‌خواهید بدانید چطور سرعت کل سایت را در سطح معماری بهبود دهید (نه فقط لایهٔ DNS)، مقالهٔ چگونه سرعت سایت وردپرسی را افزایش دهیم؟ نقشهٔ کامل شش‌لایه‌ای را دارد. لایهٔ هاست و سرور هم، به‌عنوان پایهٔ همه این تصمیم‌ها، در تأثیر هاست بر سرعت سایت چقدر است؟ تحلیل شده است.

جدول مقایسه: تکنیک در برابر اثر روی تأخیر

خواندن این جدول به‌تنهایی کافی نیست؛ مهم این است که بدانید کدام ردیف برای موقعیت شما بیشترین اثر را دارد. سایت‌های با مخاطب محلی، بیشتر از رزولور و TTL سود می‌برند؛ سایت‌های با مخاطب پراکنده، از Anycast و CDN. برای پیدا کردن نقطهٔ شروع، بخش بعد (سنجش) پاسخ دقیقی می‌دهد.

اشتباهات رایج در بهینه‌سازی DNS

پنج اشتباه که در بازبینی سایت‌ها بیشتر از همه دیده‌ام:

• استفاده از DNS هاست به‌صورت پیش‌فرض بدون بررسی سرعت و کیفیت آن؛ بسیاری از هاست‌ها، این سرویس را به‌عنوان یک قابلیت جانبی و نه تخصصی ارائه می‌دهند.
• تنظیم TTL بسیار کوتاه برای همه چیز به بهانهٔ انعطاف؛ بار اضافی روی سرور Authoritative و پرسش‌های پیوسته، نتیجهٔ این تصمیم است.
• نگه‌داشتن زنجیره‌های بلند CNAME که هر کدام، یک پرسش تازه اضافه می‌کنند. اگر می‌توانید، به رکوردهای مستقیم (A/AAAA) مهاجرت کنید.
• نادیده‌گرفتن DNSSEC در سایت‌هایی که نیاز به امنیت بیشتر دارند؛ با این حال، فعال‌سازی نادرست DNSSEC می‌تواند سایت را از دسترس خارج کند، پس با احتیاط و همراه با متخصص انجام دهید.
• عدم مستندسازی تنظیمات DNS؛ اگر فردا سرور عوض شود یا تیم جدیدی مسئول شود، نبود مستندات، زمان بازیابی را چند برابر می‌کند.

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

چطور سرعت DNS را بسنجیم؟

سه روش عملی که در پروژه‌ها استفاده می‌کنم:

1. دستور dig با پارامتر +stats: می‌توانید زمان پاسخ هر رزولور را مستقیم ببینید. سه بار از سه رزولور متفاوت اجرا کنید و میانگین بگیرید. یک نمونه دستور ساده:

dig example.com @1.1.1.1 +stats
dig example.com @8.8.8.8 +stats

2. ابزارهای آنلاین DNS Speed Test: سرویس‌هایی که سرعت رزولوشن دامنه شما را از چند موقعیت جغرافیایی می‌سنجند. برای سایت‌های با مخاطب بین‌المللی، این روش تصویر دقیق‌تری می‌دهد.
3. در DevTools مرورگر: تب Network، ستون Timing؛ مقدار DNS Lookup به شما می‌گوید چقدر از زمان لود، در این لایه بوده است. اگر این عدد بالای ۱۰۰ میلی‌ثانیه است، جای کار دارد.

معیار من برای قضاوت: اگر مجموع زمان DNS Lookup در هر صفحه، زیر ۵۰ میلی‌ثانیه است، لایهٔ DNS در وضعیت خوبی است و نباید بیشتر روی آن سرمایه‌گذاری کنید. اگر بالای ۲۰۰ میلی‌ثانیه است، اول ارائه‌دهندهٔ DNS و TTL را بررسی کنید. این روش سنجش، همان روحیهٔ «سنجش پیش از تغییر» است که در Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد؟ هم روی آن تأکید کرده‌ام؛ بدون داده، بهینه‌سازی حدس می‌شود.

نگاه زیرپوستی: چرا لایه‌بندی DNS جواب می‌دهد

برای مهندسانی که به دنبال درک مکانیزم هستند، مسئلهٔ سرعت DNS را می‌توان در قالب یک زنجیرهٔ احتمالاتی باز کرد. هر پرسش DNS، یک احتمال کش‌شدن (Cache Hit Ratio) دارد. این احتمال به سه عامل بستگی دارد: میزان پراکندگی رزولورها، طول TTL، و میزان تطابق کاربران به یک نقطهٔ جغرافیایی. هرچه این سه را بیشتر به نفع «کش گرم» بچرخانید، بار روی سرور Authoritative و زمان انتظار کاربر کاهش می‌یابد.

دو تصمیم مهندسی که در تیم‌ها اجرا کرده‌ام: اول، مستندسازی وضعیت DNS در قالب یک جدول زنده که هر نسخه از تغییرات در آن ثبت می‌شود (کدام رکورد، با چه TTL، به کدام IP، چه تاریخ). دوم، پایش خودکار زمان پاسخ Authoritative با یک اسکریپت سبک که هفتگی اجرا می‌شود و نتایج را در یک سری زمانی ذخیره می‌کند. تجربه‌ام می‌گوید مشکل‌های DNS، بیشتر از آن‌که ناگهانی ظاهر شوند، به‌صورت یک کاهش تدریجی در کیفیت پاسخ بروز می‌کنند — و سری زمانی، تنها راه دیدن این روند پیش از آن است که کاربر شکایت کند.

یک یادآوری معماری: DNS خوب، مکمل هاست خوب است، نه جانشینش. اگر سرور شما کند است، DNS سریع فقط شما را سریع‌تر به یک مقصد کند می‌رساند. این ترتیب را در ذهن داشته باشید: بستر (هاست و سرور) → مسیر (DNS و CDN) → محتوا (قالب و افزونه). هر لایه، پیش‌نیاز لایهٔ بعدی است.

خط پایانی

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

اگر روی سایت خودتان این لایه را بهینه کرده‌اید، برای من جالب است بدانم کدام تکنیک بیشترین اثر را داشت — رزولور، Anycast، TTL یا CDN. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر در شبکهٔ محلی نتایج متفاوتی از پیش‌فرض‌ها گرفته‌اید. همان یک عدد، می‌تواند خواننده بعدی را در انتخاب درست، یک ساعت جلو بیندازد. ⚡