DNS چیست و چگونه کار می کند؟ راهنمای رکوردها، تنظیمات و TTL سایت
DNS مسیر اتصال دامنه به سایت و سرویس های دیگر را مشخص می کند. در این راهنما عملکرد DNS، رکوردهای مهم، تنظیم TTL، تغییر هاست و عیب یابی خطاهای رایج را با مثال یاد می گیرید.
وقتی آدرس یک سایت را در مرورگر می نویسید، دستگاه شما باید بداند درخواست را به کدام سرور بفرستد. DNS این مسیر را پیدا می کند. برای مدیر سایت، آشنایی با DNS فقط یک بحث شبکه نیست؛ اشتباه در رکوردها می تواند سایت، ایمیل یا نسخه تازه دامنه را از دسترس خارج کند. در این راهنما از مفهوم پایه شروع می کنیم، رکوردهای مهم را با مثال می بینیم و بعد سراغ TTL، تغییر هاست، عیب یابی و ارتباط DNS با سئو می رویم.
DNS چیست و چه کاری برای سایت انجام می دهد؟
DNS مخفف Domain Name System و سامانه ای برای پیدا کردن اطلاعات مرتبط با نام دامنه است. رایج ترین کاربرد آن پیدا کردن نشانی IP سروری است که یک دامنه یا زیردامنه به آن اشاره می کند. برای مثال، مرورگر به جای حفظ کردن IP سرور، نامی مثل example.com را می شناسد و از DNS می پرسد برای اتصال به این نام باید به کجا برود.
DNS خود سایت را میزبانی نمی کند و محتوای صفحه را نیز تحویل نمی دهد. بلکه وظیفه اش پاسخ دادن به پرسش های مربوط به رکوردهای دامنه است. پس از دریافت پاسخ DNS، مرورگر اتصال لازم را با مقصد برقرار می کند و تازه مرحله دریافت صفحه شروع می شود.
DNS همچنین برای هدایت ایمیل، تایید مالکیت دامنه و برخی تنظیمات امنیتی به کار می رود.
وقتی دامنه را در مرورگر می زنیم، DNS چگونه کار می کند؟
در حالت ساده، دستگاه ابتدا پاسخ ذخیره شده را بررسی می کند. اگر پاسخ معتبر در کش پیدا نشود، پرسش به حل کننده DNS یا Resolver می رسد. Resolver ممکن است با سرورهای ریشه، سرور پسوند دامنه و در نهایت سرور معتبر دامنه ارتباط بگیرد. بسیاری از این مراحل به دلیل کش شدن پاسخ ها در مراجعه های بعدی تکرار نمی شوند.
Resolver و سرور معتبر چه فرقی دارند؟
Resolver از طرف کاربر دنبال پاسخ می گردد. این سرویس می تواند متعلق به ارائه دهنده اینترنت، سازمان یا یک سرویس DNS عمومی باشد. اگر رکورد مورد نیاز را در کش داشته باشد، همان پاسخ را برمی گرداند؛ در غیر این صورت، مسیر پرس و جو را ادامه می دهد.
سرور معتبر یا Authoritative Nameserver منبع پاسخ رکوردهای دامنه ای است که مدیریت آن به او سپرده شده است. سرور ریشه و سرور پسوند مانند تابلوهای راهنما، Resolver را به سمت سرور معتبر می برند. پس «DNS سرور» همیشه یک نقش واحد ندارد؛ دانستن نقش هرکدام هنگام عیب یابی ضروری است.
کش DNS چه زمانی به کار می آید؟
Resolver پاسخ دریافتی را برای مدتی نگه می دارد تا هر بار مجبور نباشد کل مسیر را طی کند. دستگاه کاربر نیز ممکن است پاسخ را به صورت محلی ذخیره کند. این کش می تواند زمان یافتن نشانی را کاهش دهد، اما همان سازوکار باعث می شود پس از تغییر رکورد، برخی کاربران هنوز مقصد قبلی را ببینند.
مدت پیشنهادی نگهداری یک پاسخ در رکورد DNS با TTL مشخص می شود. با این حال، رفتار کش محلی، Resolver و سرویس دهنده می تواند متفاوت باشد؛ بنابراین «انتشار تغییر DNS» یک زمان ثابت و یکسان برای همه کاربران ندارد. بخش TTL پایین تر نشان می دهد چطور پیش از جابه جایی سایت این زمان را مدیریت کنید.
دامنه، هاست، نیم سرور و DNS چه تفاوتی دارند؟
دامنه نامی است که کاربر وارد می کند؛ هاست یا سرور، فایل ها و برنامه سایت را در اختیار قرار می دهد. DNS اطلاعاتی را نگه می دارد که نام دامنه را به سرویس مناسب وصل می کند. نیم سرور یا Nameserver هم مشخص می کند پاسخ معتبر رکوردهای دامنه را باید از کدام ارائه دهنده DNS گرفت.
ممکن است دامنه را از یک شرکت بخرید، فایل های سایت روی هاست شرکت دیگری باشد و DNS را در پنل سومی مدیریت کنید. در این وضعیت، ویرایش رکورد در پنلی که سرور معتبر دامنه نیست، اثر مورد انتظار را ندارد.
پیش از هر تغییر، در پنل ثبت کننده دامنه بررسی کنید نیم سرورها به کجا اشاره می کنند و رکوردهای فعال در کدام سرویس مدیریت می شوند.
مهم ترین رکوردهای DNS کدام اند؟
هر رکورد، پرسش مشخصی را پاسخ می دهد. برای راه اندازی سایت بیشتر وقت ها به رکوردهای نشانی IP نیاز دارید و برای ایمیل یا تایید سرویس ها رکوردهای دیگری لازم می شود. نوع رکورد را بر اساس دستور سرویس میزبان انتخاب کنید؛ یک مقدار اشتباه ممکن است سایت را باز کند اما ایمیل را مختل کند.
| رکورد | کار اصلی | نمونه کاربرد |
|---|---|---|
| A | اتصال نام به IPv4 | example.com به IP سرور سایت |
| AAAA | اتصال نام به IPv6 | نسخه IPv6 سایت |
| CNAME | اشاره یک نام به نام دیگر | www به دامنه اصلی یا سرویس مقصد |
| MX | مشخص کردن سرور دریافت ایمیل | دریافت نامه های دامنه |
| TXT | نگهداری مقدار متنی برای تایید و سیاست ها | تایید سرچ کنسول، SPF یا DKIM |
| NS | معرفی سرورهای معتبر یک ناحیه | واگذاری مدیریت DNS دامنه یا زیردامنه |
| SOA | اطلاعات مدیریتی ناحیه DNS | مشخصات اصلی Zone |
| PTR | تبدیل معکوس IP به نام | Reverse DNS، به ویژه در تنظیمات ایمیل |
برای نمونه، اگر سایت روی یک IPv4 میزبانی می شود، رکورد A دامنه اصلی به همان IP اشاره می کند. برای www ممکن است A جداگانه یا CNAME مناسب تعریف شود. رکورد CNAME در بیشتر موارد نباید برای نامی که هم زمان رکوردهای ناسازگار دیگری دارد استفاده شود؛ محدودیت دقیق پنل و ارائه دهنده DNS را بررسی کنید. برای ایمیل نیز مقدار MX را از سرویس ایمیل بگیرید و رکوردهای تایید خواسته شده را دقیق وارد کنید.
TTL در DNS چیست و چرا هنگام تغییر هاست مهم می شود؟
TTL یا Time to Live در یک رکورد DNS، مدت زمانی است که پاسخ آن رکورد می تواند در کش Resolver باقی بماند؛ مقدار آن بر حسب ثانیه نمایش داده می شود. مثلا TTL برابر ۳۶۰۰ یعنی یک ساعت. اگر رکورد A را تغییر دهید، Resolverی که پاسخ قبلی را تازه ذخیره کرده است ممکن است تا پایان زمان باقی مانده از همان پاسخ استفاده کند.
این مفهوم را با مدت اعتبار بسته شبکه یا کش فایل های سایت یکی نگیرید. TTL کوتاه تر می تواند رسیدن تغییرات بعدی به کاربران را سریع تر کند، اما پرس و جوهای بیشتری به سمت DNS معتبر می فرستد.
TTL بلندتر شانس پاسخ از کش را بالا می برد، ولی هنگام جابه جایی سرور ممکن است کاربران بیشتری تا مدتی مقصد قبلی را ببینند. انتخاب عدد مناسب به پایداری رکورد، برنامه تغییرات و محدودیت ارائه دهنده بستگی دارد؛ یک عدد جادویی برای همه دامنه ها وجود ندارد.
برای تغییر هاست، TTL را چه زمانی و چقدر کم کنیم؟
پیش از تغییر IP، TTL رکوردهای مرتبط را در پنل DNS فعال کاهش دهید و دست کم به اندازه TTL قبلی فرصت بدهید تا کش های قدیمی منقضی شوند. اگر امروز TTL را از یک روز به چند دقیقه تغییر دهید، آن Resolver که دیروز پاسخ یک روزه گرفته است از عدد تازه باخبر نمی شود تا پاسخ قبلی اش منقضی شود.
به همین دلیل کاهش TTL باید پیش از زمان جابه جایی انجام شود، نه هم زمان با آن.
راهنمای مهاجرت هاست گوگل پیشنهاد می کند TTL را دست کم یک هفته قبل به مقداری محافظه کارانه، مثلا چند ساعت، کاهش دهید و پس از تغییر DNS، دسترسی کاربران و Googlebot به سرور تازه را کنترل کنید. سپس وقتی مطمئن شدید پاسخ ها پایدار است، می توانید TTL را به مقدار عادی برگردانید. مقدار دقیق را با ارائه دهنده DNS و نیاز عملی سایت هماهنگ کنید.
TTL رکورد DNS را کجا تغییر دهیم؟
اول ببینید DNS معتبر دامنه در کدام سرویس قرار دارد. اگر رکوردها در cPanel مدیریت می شوند، به Zone Editor بروید، دامنه را با Manage باز کنید، رکورد مورد نظر را Edit کنید و مقدار TTL را ذخیره کنید. این مسیر تنها وقتی مؤثر است که همان Zone برای دامنه فعال باشد؛ تغییر در cPanel یک هاست قدیمی که نیم سرور دامنه به آن اشاره نمی کند، اثری روی پاسخ عمومی DNS ندارد.
در سرویس هایی مثل Cloudflare، TTL را کنار هر رکورد DNS only می بینید. برای رکوردهای Proxied، مقدار TTL در Cloudflare به صورت خودکار مدیریت می شود و ممکن است قابل ویرایش نباشد. پیش از تغییر MX، TXT یا رکوردهای سایت، از تنظیمات فعلی نسخه بردارید تا اگر مشکلی پیش آمد بتوانید مقدار قبلی را برگردانید.
| موقعیت | رفتار پیشنهادی TTL | دلیل |
|---|---|---|
| رکورد پایدار و بدون برنامه تغییر | مقدار متناسب با سیاست ارائه دهنده | استفاده بیشتر از کش |
| چند روز پیش از تغییر IP یا هاست | کاهش موقت با فرصت برای انقضای TTL قبلی | کوتاه شدن دوره دیدن مقصد قدیمی |
| پس از اطمینان از مهاجرت | بازگرداندن مقدار عادی | پایداری و کاهش پرس و جوهای غیرضروری |
اگر پس از تغییر هنوز IP قبلی دیده می شود، این را نشانه ذخیره نشدن رکورد ندانید. ابتدا پاسخ سرور معتبر و سپس پاسخ Resolverهای مختلف را مقایسه کنید. ممکن است تغییر درست ثبت شده باشد اما یک کش هنوز معتبر باشد. همچنین بررسی کنید رکوردهای A و AAAA، دامنه اصلی و www همگی مطابق برنامه مهاجرت تنظیم شده اند.
آموزش تصویری تغییر TTL و رکورد A در cPanel
فرض کنید DNS معتبر دامنه در همان cPanel مدیریت می شود و می خواهید پیش از تغییر هاست، TTL رکورد A را کم کنید. از بخش Domains وارد Zone Editor شوید، کنار دامنه روی Manage بزنید، رکورد A دامنه اصلی را پیدا کنید و Edit را انتخاب کنید. نام دامنه، نوع رکورد و IP فعلی را پیش از هر ویرایش یادداشت کنید تا مسیر بازگشت داشته باشید.
در نمونه واقعی صفحه Manage Zone در cPanel، ستون های Name، TTL، Type و Record و دکمه Save Record را نشان می دهد. در این نمونه TTL برابر ۱۴۴۰۰ ثانیه، یعنی چهار ساعت است. ظاهر پنل و جای دکمه ها ممکن است بسته به نسخه cPanel یا تنظیمات شرکت میزبان کمی فرق کند.
برای کاهش TTL، عدد مناسب برنامه مهاجرت را در فیلد TTL همان رکورد وارد کنید و Save Record را بزنید؛ مثلا ۳۰۰ ثانیه، اگر سرویس DNS این مقدار را می پذیرد. کم کردن TTL امروز، کشی را که پیش تر پاسخ ۱۴۴۰۰ ثانیه ای گرفته کوتاه نمی کند؛ باید برای انقضای مقدار قبلی فرصت بگذارید و بعد IP رکورد A را تغییر دهید.
اگر نیم سرورهای دامنه به Cloudflare یا سرویس دیگری اشاره می کنند، همین تغییر را در پنل DNS فعال انجام دهید. تصویر از راهنمای Bluehost است و مراحل با مستندات رسمی cPanel تطبیق داده شده اند.
TTL در پینگ و CDN با TTL رکورد DNS چه فرقی دارد؟
واژه TTL در چند جای متفاوت استفاده می شود، اما سازوکارشان یکسان نیست. TTL بسته IPv4 در مسیر شبکه با عبور از هر روتر کم می شود و از گردش بی پایان بسته جلوگیری می کند. عددی که در خروجی ping می بینید به این بخش مربوط است؛ با تغییر TTL رکورد DNS در cPanel، TTL بسته های پینگ را عوض نمی کنید.
در IPv6 اصطلاح متناظر Hop Limit است. در CDN نیز ممکن است TTL به مدت نگهداری یک فایل یا پاسخ HTTP در کش لبه اشاره کند. این زمان را تنظیمات کش CDN یا هدرهای HTTP کنترل می کنند، نه TTL رکورد DNS.
اگر تصویر تازه سایت نمایش داده نمی شود، پاک سازی کش CDN یا بررسی Cache-Control شاید لازم باشد؛ تغییر DNS TTL به تنهایی آن فایل را تازه نمی کند.
چطور DNS یک سایت را راه اندازی یا تغییر دهیم؟
قبل از ورود به پنل، مقصد هر سرویس را مشخص کنید: سایت روی چه IP یا نامی قرار می گیرد، ایمیل از کدام سرویس استفاده می کند و آیا CDN یا پراکسی فعال است؟ راه اندازی DNS با حدس زدن رکوردها خطرناک است. مقادیر A، AAAA، CNAME، MX و TXT را از راهنمای ارائه دهنده همان سرویس بردارید و رکوردهای فعلی را برای بازگشت احتمالی ثبت کنید.
مرحله اول: محل مدیریت DNS و رکوردهای فعلی را پیدا کنید
در پنل ثبت کننده دامنه، نیم سرورهای فعال را ببینید. اگر نیم سرورها متعلق به ارائه دهنده دیگری هستند، تنظیمات اصلی را باید در پنل همان ارائه دهنده تغییر دهید. در صورت انتقال کامل مدیریت DNS به سرویس تازه، پیش از عوض کردن نیم سرورها همه رکوردهای لازم، به ویژه MX و TXT ایمیل، را در مقصد بازسازی کنید.
اگر فقط هاست سایت را تغییر می دهید، همیشه نیازی به تعویض نیم سرور نیست. ممکن است فقط رکورد A یا AAAA دامنه اصلی و رکورد www تغییر کنند. تفاوت این دو سناریو مهم است: تعویض نیم سرور مدیریت کل ناحیه را جابه جا می کند، اما ویرایش رکورد فقط پاسخ همان نام و نوع را تغییر می دهد.
مرحله دوم: رکورد درست را ثبت و تغییر را زمان بندی کنید
نام رکورد، نوع، مقدار و TTL را طبق دستور سرویس مقصد وارد کنید. مثلا برای اتصال دامنه به هاست دارای IPv4، IP ارائه شده را در رکورد A مناسب ثبت کنید. اگر مقصد یک سرویس مبتنی بر نام دامنه است، ممکن است CNAME لازم باشد.
برای ریشه دامنه، بعضی ارائه دهندگان ساز و کار مخصوصی برای اشاره به نام دیگر دارند؛ محدودیت CNAME در ریشه را با پنل خود بررسی کنید.
اگر مهاجرت برنامه ریزی شده دارید، TTL را از قبل کاهش دهید، سرور تازه را آزمایش کنید و بعد رکورد را تغییر دهید. سرور قدیمی را بلافاصله خاموش نکنید؛ تا زمانی که کش های قبلی ممکن است به آن اشاره کنند، باید بتواند پاسخ مناسب بدهد. پس از تغییر، HTTPS، صفحات مهم، فرم ها و ایمیل را در مقصد تازه امتحان کنید.
مرحله سوم: پاسخ DNS و دسترسی واقعی سایت را بررسی کنید
با دستورهایی مثل nslookup example.com در ویندوز یا dig example.com A در محیط هایی که dig نصب است، پاسخ رکورد را ببینید. سپس پاسخ چند Resolver را مقایسه کنید. مشاهده IP تازه در یک ابزار به تنهایی ثابت نمی کند همه کاربران پاسخ تازه را می بینند؛ کش ها می توانند در زمان های متفاوت منقضی شوند.
در کنار پاسخ DNS، باز شدن خود سایت، گواهی HTTPS و مسیرهای مهم را بررسی کنید. در سرچ کنسول هم URL Inspection و گزارش های Indexing را برای صفحه های کلیدی زیر نظر بگیرید. اگر DNS درست پاسخ می دهد ولی صفحه باز نمی شود، مشکل می تواند از سرور، فایروال، گواهی یا تنظیمات برنامه باشد؛ همه خطاها را به DNS نسبت ندهید.
خطاهای رایج DNS را چطور عیب یابی کنیم؟
عیب یابی را از علامت مشکل شروع کنید: آیا فقط سایت باز نمی شود، فقط ایمیل اختلال دارد یا تغییر تازه برای برخی کاربران دیده نمی شود؟ برای هر حالت، نام و نوع رکورد را از سرور معتبر بپرسید و آن را با تنظیمات مورد انتظار مقایسه کنید. این روش سریع تر از پاک کردن اتفاقی همه رکوردهاست.
سایت باز نمی شود یا فقط www کار نمی کند
ابتدا رکورد A و AAAA دامنه اصلی و تنظیم www را بررسی کنید. اگر AAAA به سروری اشاره کند که نسخه IPv6 سایت روی آن آماده نیست، برخی کاربران ممکن است با خطا روبه رو شوند، حتی اگر A درست باشد. بعد مطمئن شوید مقصد IP سایت را میزبانی می کند و گواهی HTTPS نام دامنه را پوشش می دهد.
اگر پاسخی از DNS دریافت نمی کنید، نیم سرورها، وضعیت دامنه و رکوردهای موجود در Zone معتبر را کنترل کنید. اگر پاسخ وجود دارد اما مرورگر خطای اتصال یا گواهی می دهد، سراغ هاست، وب سرور و HTTPS بروید. DNS تنها یکی از حلقه های مسیر دسترسی است.
ایمیل دامنه قطع شده است
رکورد MX را با راهنمای سرویس ایمیل مقایسه کنید و ببینید نام مقصد آن درست پاسخ می دهد یا نه. هنگام تعویض نیم سرور، جا افتادن MX از خطاهای رایج است. رکوردهای TXT مرتبط با SPF، DKIM و DMARC را نیز بررسی کنید؛ این موارد برای احراز هویت و تحویل پذیری ایمیل مهم اند، اما جای MX را نمی گیرند.
اگر سایت درست باز می شود ولی ایمیل نه، رکورد A سایت را بی دلیل تغییر ندهید. مسیر ایمیل می تواند مستقل باشد. همچنین بعضی ارائه دهندگان هاست تنظیم جداگانه ای برای محل دریافت ایمیل دارند؛ وضعیت آن را با سرویس ایمیل خود هماهنگ کنید.
تغییر رکورد ثبت شده اما هنوز پاسخ قدیمی دیده می شود
پاسخ سرور معتبر را با پاسخ Resolver عمومی و دستگاه خود مقایسه کنید. اگر سرور معتبر مقدار تازه را می دهد اما Resolver هنوز مقدار قبلی را نشان می دهد، به زمان باقی مانده کش و TTL قبلی توجه کنید. پاک کردن کش محلی فقط نتیجه دستگاه شما را عوض می کند و کش همه کاربران اینترنت را پاک نمی کند.
اگر خود سرور معتبر هنوز مقدار قدیمی را نشان می دهد، ممکن است رکورد را در پنل اشتباه ویرایش کرده باشید یا تغییر ذخیره نشده باشد. وضعیت نیم سرورهای فعال، نام دقیق رکورد و نوع آن را دوباره ببینید. در زمان مهاجرت، وجود دو رکورد متناقض یا باقی ماندن AAAA قدیمی نیز می تواند نتیجه را گیج کننده کند.
مثال عیب یابی: بعد از تغییر هاست هنوز سایت قدیمی دیده می شود
فرض کنید IP نمونه دامنه از 192.0.2.10 به 192.0.2.20 تغییر کرده، اما دو ساعت بعد بعضی کاربران هنوز نسخه قدیمی سایت را می بینند. این دو IP فقط برای آموزش هستند. اول نیم سرورهای فعال دامنه را بررسی کنید و مطمئن شوید رکورد A را در همان سرویس DNS معتبر تغییر داده اید.
سپس رکوردهای دامنه اصلی و www را جداگانه ببینید؛ وجود AAAA قدیمی هم می تواند نتیجه برخی کاربران را متفاوت کند. در ویندوز می توانید پاسخ دو Resolver عمومی را با دستورهای زیر مقایسه کنید. به جای yourdomain.com دامنه خودتان را بگذارید.
اگر پاسخ دو Resolver متفاوت است و سرور معتبر مقدار تازه را نشان می دهد، به احتمال زیاد کش پاسخ قدیمی هنوز منقضی نشده است. اگر خود سرور معتبر نیز IP قدیمی را می دهد، مشکل را در پنل فعال، نام رکورد یا ذخیره نشدن تغییر جستجو کنید.
nslookup -type=NS yourdomain.com 1.1.1.1
nslookup -type=A yourdomain.com 1.1.1.1
nslookup -type=A yourdomain.com 8.8.8.8اگر پاسخ DNS در همه جا تازه است اما مرورگر هنوز صفحه قدیمی را نشان می دهد، سراغ کش مرورگر یا CDN، تنظیمات هاست تازه، ریدایرکت ها و HTTPS بروید. در مهاجرت، سرور قبلی را تا پایان دوره انتقال پاسخگو نگه دارید و صفحه اصلی، چند صفحه مهم، فرم ها و ایمیل را جداگانه آزمایش کنید.
این ترتیب کمک می کند بین تاخیر کش DNS و خطای خود سایت فرق بگذارید؛ برای نمونه، راهنمای عیب یابی DNS کلادفلر نیز مقایسه پاسخ سرور معتبر و Resolver را توصیه می کند.
DNS چه اثری بر سئو و دسترسی گوگل دارد؟
وجود یک رکورد DNS خاص به خودی خود میانبر افزایش رتبه نیست. اثر مهم DNS در دسترسی است: اگر دامنه به سرور اشتباه برود، پاسخ ناپایدار باشد یا Googlebot نتواند به سایت برسد، خزیدن و مشاهده صفحات مختل می شود. هنگام تغییر هاست، کاهش برنامه ریزی شده TTL، نگه داشتن سرور قبلی تا پایان انتقال و کنترل پاسخ های سایت کمک می کند وقفه کمتر شود. اگر فقط هاست عوض می شود و URLها ثابت می مانند، نقشه کار با تغییر دامنه فرق دارد.
در مهاجرت هاست، علاوه بر DNS باید وضعیت HTTP، HTTPS، فایل ها، فرم ها و دسترسی ربات گوگل را بررسی کنید. اگر URLهای قابل مشاهده نیز تغییر می کنند، ریدایرکت های مرتبط و برنامه مهاجرت URL لازم است. برای تحلیل مشکلات پس از تغییر، گزارش های سرچ کنسول را با تاریخ جابه جایی مقایسه کنید، اما هر افتی را خودکار به TTL نسبت ندهید.
DNSSEC و حریم خصوصی DNS به چه معناست؟
DNSSEC با امضای رمزنگاری شده کمک می کند Resolver اعتبار پاسخ DNS را بررسی کند و پاسخ جعلی را به جای رکورد معتبر نپذیرد. راه اندازی آن فقط روشن کردن یک دکمه نیست؛ هنگام جابه جایی ارائه دهنده DNS باید وضعیت رکورد DS در ثبت کننده دامنه هم با کلیدهای سرویس تازه هماهنگ باشد، وگرنه ممکن است دامنه برای Resolverهای اعتبارسنج از دسترس خارج شود.
DNS over HTTPS یا DoH موضوع دیگری است: ارتباط پرس و جو میان دستگاه و Resolver را رمزگذاری می کند. DoH جای DNSSEC را نمی گیرد و هیچ کدام، جای HTTPS سایت را پر نمی کنند. برای مدیر سایت، اولویت عملی این است که رکوردها، نیم سرورها و گواهی سایت درست کار کنند و سپس تنظیمات امنیتی را با راهنمای ارائه دهنده DNS انجام دهد.
جمع بندی: DNS را ساده اما دقیق مدیریت کنید
DNS نام دامنه را به خدمات درست وصل می کند؛ رکوردهای A و AAAA برای نشانی سایت، MX برای ایمیل، TXT برای تاییدها و NS برای واگذاری مدیریت از پرکاربردترین بخش های آن هستند.
قبل از تغییر هاست، محل واقعی مدیریت DNS را پیدا کنید، رکوردهای فعلی را ثبت کنید، TTL را از قبل تنظیم کنید و پس از تغییر، هم پاسخ DNS و هم عملکرد واقعی سایت را بسنجید. TTL رکورد DNS را با TTL بسته در ping یا کش فایل در CDN اشتباه نگیرید. اگر این تفاوت ها روشن باشد، عیب یابی تغییر دامنه و هاست به جای حدس و آزمون تصادفی، به یک روند قابل کنترل تبدیل می شود.
منابع فنی برای بررسی بیشتر
برای جزئیات رفتار DNS، رکوردها و مهاجرت هاست، راهنمای سرویس های سازنده و مستندات رسمی را مبنا قرار دهید. تنظیمات دقیق هر پنل ممکن است با ارائه دهنده شما فرق داشته باشد.
سوالات متداول درباره DNS چیست
در ادامه به متداول ترین سوالات درباره DNS چیست پاسخ می دهیم:
DNS چیست و چه تفاوتی با هاست دارد؟
DNS اطلاعات لازم برای پیدا کردن مقصد دامنه را برمی گرداند، اما هاست فایل ها و برنامه سایت را نگه می دارد و صفحه را به کاربر تحویل می دهد.
نیم سرور چه تفاوتی با رکورد DNS دارد؟
نیم سرور مشخص می کند پاسخ معتبر رکوردهای دامنه را کدام سرویس ارائه می دهد. رکورد DNS اطلاعات مشخصی مثل IP سایت یا مقصد ایمیل را در همان سرویس ثبت می کند.
TTL در DNS چیست و مقدار ۳۶۰۰ یعنی چه؟
TTL مدت پیشنهادی نگهداری پاسخ یک رکورد در کش Resolver است. عدد ۳۶۰۰ به معنی یک ساعت است؛ پس از تغییر رکورد، کش قدیمی ممکن است تا پایان زمان باقی مانده همان پاسخ را بدهد.
آیا TTL در ping همان TTL رکورد DNS است؟
خیر. TTL در ping به مدت عمر بسته IPv4 در مسیر شبکه مربوط است، اما TTL رکورد DNS مدت نگهداری پاسخ دامنه در کش را مشخص می کند. تغییر یکی، دیگری را تغییر نمی دهد.
TTL دامنه را در cPanel چگونه تغییر دهیم؟
اگر DNS معتبر دامنه در همان cPanel مدیریت می شود، در Zone Editor دامنه را با Manage باز کنید، رکورد مورد نظر را Edit کنید و مقدار TTL را ذخیره کنید. اگر نیم سرورها به سرویس دیگری اشاره می کنند، تغییر را در پنل همان سرویس انجام دهید.
آیا تغییر DNS به تنهایی رتبه سایت را بهتر می کند؟
خیر. رکورد DNS خاصی تضمین کننده رشد رتبه نیست. تنظیم نادرست DNS می تواند دسترسی کاربران یا Googlebot را مختل کند؛ در مهاجرت هاست باید پاسخ DNS و دسترسی واقعی صفحات را بررسی کرد.
0 دیدگاه ثبت شده است.
در بحث و گفتگوی مربوط به این مطلب شرکت کنید!
