دی ان اس (DNS) چیست
DNS دفترچه نشانی اینترنت است: نام دامنه ای مثل rgb.ir را می گیرد و نشانی عددی سروری را برمی گرداند که مرورگر باید به آن وصل شود. کاری که دفترچه نشانی معمولی نمی کند این است که جواب را همه جای مسیر ذخیره می کند، و همین ذخیره کردن دلیل اصلی این است که تغییر رکورد فوری نیست.
- درس ۴ از ۱۲
- مقدماتی
- رایگان، بدون ثبت نام
مسیر یک استعلام، وقتی جواب ذخیره نشده باشد
-
۱
حافظه
مرورگر، سیستم عامل و روتر، هر کدام کپی خودشان را دارند
-
۲
سرور استعلام
کسی که به جای شما می پرسد و جواب را نگه می دارد
-
۳
سرور ریشه
نمی داند دامنه شما کجاست، فقط می داند پسوند را از که بپرسد
-
۴
سرور پسوند
برای ir، سرورهایی که می گویند جواب این دامنه دست کیست
-
۵
سرور معتبر
خود رکورد و مهلتش را همین جا می دهد
در عمل بیشتر استعلام ها به ایستگاه دوم نمی رسند، چون جواب از قبل ذخیره شده است. این مسیر کامل، حالت بار اول است.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
DNS دقیقا چه کاری می کند؟
DNS نام را به نشانی ترجمه می کند. شما rgb.ir را می نویسید، مرورگر نشانی عددی می خواهد، و DNS همان را می دهد. اگر این ترجمه نبود باید نشانی عددی هر سایتی را حفظ می کردید، و نکته مهم تر: صاحب سایت هرگز نمی توانست سرورش را عوض کند بدون اینکه همه بازدیدکننده ها گم شوند.
تشبیه دفترچه نشانی درست است ولی نیمی از ماجرا را می پوشاند. دفترچه نشانی یک دفتر واحد نیست؛ یک ساختار درختی است که از ریشه شروع می شود، به پسوند می رسد و از آنجا به سرورهایی که جواب دامنه شما را دارند. هیچ جایی یک فایل کامل از همه نام های دنیا نگه نمی دارد.
و نیم دیگر ماجرا، همان چیزی است که تشبیه اصلا نمی گوید: هر کسی در این مسیر جواب را برای مدت مشخصی نگه می دارد. مرورگر شما، سیستم عامل، روتر خانه و سرور استعلام اپراتور، همه کپی دارند. به همین دلیل جواب سوالی که همه می پرسند، «چرا تغییر DNS من هنوز اعمال نشده»، هیچ ربطی به درست بودن رکورد ندارد.
یک تصور غلط رایج را هم همین جا کنار بگذاریم: DNS فقط راهنمایی می کند و خودش هیچ داده ای را جابه جا نمی کند. بعد از اینکه نشانی را گرفتید، اتصال شما مستقیم با سرور مقصد است و DNS دیگر در مسیر نیست.
یک نام چطور به نشانی تبدیل می شود؟
در چهار پرسش، و اگر جواب از قبل ذخیره شده باشد در صفر پرسش. اول سرور استعلام حافظه خودش را نگاه می کند. اگر نداشت از یکی از سرورهای ریشه می پرسد کدام سرورها پسوند ir را می شناسند، بعد از آنها می پرسد چه کسی جواب rgb.ir را دارد، و آخر سر از همان سرور، خود رکورد را می گیرد.
خوبی این کار اندازه گیری پذیر بودنش است. امروز از همین سرور، یک نام کاملا تازه زیر دامنه خودمان را از یک سرور استعلام عمومی پرسیدیم: بار اول ۶۶ میلی ثانیه طول کشید و بار دوم و سوم ۷ میلی ثانیه. تفاوت، همان کاری است که ذخیره سازی می کند.
و یک جزئیات که مسیر را بهتر از هر توضیحی نشان می دهد: چند لحظه بعد یک نام تازه دیگر زیر همان دامنه پرسیدیم و بار اولش ۱۱ میلی ثانیه شد، نه ۶۶. یعنی سرور استعلام دیگر لازم نداشت از ریشه شروع کند؛ فقط یادش نبود جواب این نام خاص چیست. حافظه در هر پله این درخت جداگانه پر می شود.
نتیجه ای که به درد می خورد: کندی اولین باز شدن یک سایت خارجی، همیشه مال سرور مقصد نیست. گاهی همین چند رفت و برگشت است، و چون فقط یک بار اتفاق می افتد، در تست دوم دیگر دیده نمی شود. اگر سرعت را اندازه می گیرید و بار دوم نتیجه بهتری گرفتید، احتمالا همین را دیده اید.
TTL چیست و چرا تغییر رکورد فوری نیست؟
TTL عددی است که همراه هر رکورد فرستاده می شود و می گوید این جواب چند ثانیه معتبر است. هر سرور استعلامی که جواب را گرفته، تا پایان همان مدت دوباره نمی پرسد. پس وقتی رکورد را عوض می کنید، دنیا به اندازه TTL قدیمی عقب تر از شماست، نه به اندازه ای که پنل نشان می دهد.
عددها را از زون خود همین سایت می شود دید و امروز این ها بودند: رکورد A مهلت ۳۰۰ ثانیه دارد، یعنی پنج دقیقه. رکورد MX هم ۳۰۰. رکوردهای NS روی سرور معتبر ۸۶۴۰۰ ثانیه اند، یعنی یک روز، در حالی که همان دامنه در سطح بالاتر با مهلت ۹۰۰ ثانیه معرفی شده. سرورهای ریشه هم پسوند ir را با مهلت ۱۷۲۸۰۰ ثانیه، یعنی دو روز، معرفی می کنند.
یک نتیجه عملی از این ناهماهنگی دربیاورید: عوض کردن رکورد A سریع است و عوض کردن سرورهای نام کند. اگر فقط سرور را جابه جا می کنید، پنج دقیقه؛ اگر کل دامنه را به ارائه دهنده دیگری می برید، حساب کنید ساعت ها.
و تله ای که خیلی ها را گرفتار می کند، حافظه منفی است. اگر نامی وجود نداشته باشد، همان «وجود ندارد» هم ذخیره می شود. مهلتش را رکورد SOA تعیین می کند و برای دامنه ما ۱۸۰۰ ثانیه است، یعنی نیم ساعت. یعنی اگر زیردامنه ای را قبل از ساختنش امتحان کنید، بعد از ساختن هم تا نیم ساعت پیدا نمی شود، و این رفتار دقیقا همان چیزی است که RFC 2308 تعریفش کرده. پس قاعده ساده است: قبل از ساختن رکورد، امتحانش نکنید.
نردبان مهلت ها روی دامنه خود ما
-
۱
رکورد A: ۳۰۰ ثانیه
پنج دقیقه. جابه جا کردن سرور، تغییر سریع همین جاست.
-
۲
رکورد MX: ۳۰۰ ثانیه
مقصد ایمیل، با همان مهلت پنج دقیقه ای.
-
۳
جواب منفی: ۱۸۰۰ ثانیه
نیم ساعت. اگر زیردامنه را قبل از ساختن امتحان کنید، همین قدر منتظر می مانید.
-
۴
رکوردهای NS: ۸۶۴۰۰ ثانیه
یک روز، روی سرور معتبر. در سطح بالاتر همین دامنه با ۹۰۰ ثانیه معرفی شده.
-
۵
پسوند ir در ریشه: ۱۷۲۸۰۰ ثانیه
دو روز. بالاترین پله، کندترین پله، و آن که هیچ وقت دست شما نیست.
این پنج عدد مال زون rgb.ir در ۷ سپتامبر ۲۰۲۶ اند و مقدار پیش فرض هیچ جایی نیستند. دامنه شما اعداد دیگری دارد؛ همان ها را نگاه کنید.
چرا ایمیل شما هم به DNS وابسته است؟
چون تصمیم اینکه ایمیل شما به صندوق ورودی برود یا به هرزنامه، عملا داخل همین رکوردها گرفته می شود. سه رکورد متنی این کار را می کنند و هر سه در DNS دامنه می نشینند: SPF می گوید کدام سرورها اجازه دارند به نام شما ایمیل بفرستند، DKIM امضای رمزنگاری شده را نگه می دارد، و DMARC می گوید با ایمیلی که این دو را رد کند چه کنند.
روی همین دامنه، رکورد SPF ما v=spf1 +mx +a ~all است، کلید DKIM زیر نام default._domainkey منتشر شده و سیاست DMARC ما روی قرنطینه تنظیم است. این ها را هر کسی می تواند از بیرون ببیند، چون رکورد DNS عمومی است؛ همان چیزی که سرور گیرنده هم می بیند.
جایی که مدل ذهنی آدم ها اشتباه است: تصور می شود ایمیل نرفتن یعنی مشکل سرور ایمیل. اغلب مشکل رکورد است. و یک محدودیت هست که تقریبا هیچ آموزشی نمی گوید و بعدا گران تمام می شود: SPF سقف ده استعلام DNS دارد، و اگر با اضافه کردن سرویس ها از آن رد شوید کل رکورد نامعتبر می شود. این سقف را RFC 7208 تعیین کرده، نه ارائه دهنده شما.
پس قبل از اینکه سرویس ایمیل تازه ای اضافه کنید، رکورد فعلی را بشمارید. یک بار شکستن این سقف، ایمیل هایی را که تا دیروز درست می رسیدند به هرزنامه می برد و هیچ خطایی هم در پنل شما نشان داده نمی شود.
سه رکورد متنی که سرنوشت ایمیل را تعیین می کنند
باید باشند
- SPF: فهرست سرورهایی که اجازه دارند به نام دامنه شما بفرستند.
- DKIM: کلید عمومی امضا، که گیرنده با آن اصالت پیام را می سنجد.
- DMARC: سیاست برخورد با ایمیلی که آن دو را رد کند.
همین جا خراب می شود
- رد شدن از سقف ده استعلام SPF، که کل رکورد را بی اعتبار می کند.
- دو رکورد SPF جدا به جای یکی، که خودش خطاست.
- اضافه کردن سرویس تازه بدون به روز کردن رکورد، و بعد تعجب از هرزنامه.
داشتن هر سه رکورد تحویل به صندوق ورودی را تضمین نمی کند. محتوای ایمیل، سابقه نشانی فرستنده و سیاست هر گیرنده هم اثر دارند.
چطور خودتان رکوردهای یک دامنه را ببینید؟
ساده ترین راه بدون نصب هیچ چیزی، ابزار رایگان بررسی DNS خودمان است. رکوردهای A، AAAA، CNAME، NS، MX، TXT و SOA را همان لحظه از سرور ما استعلام می کند و سلامت SPF و DMARC را هم جداگانه می گوید. استعلام واقعی است و از جایی کپی نمی شود؛ سقف روزانه اش هم برای همین است که یک اسکریپت سرور ما را ابزار رایگان خودش نکند.
اگر ترمینال در دسترس دارید، dig در لینوکس و مک همین کار را دقیق تر می کند و nslookup در ویندوز نسخه ساده ترش را دارد. یک عادت که تفاوت آماتور و حرفه ای است: از سرور معتبر خود دامنه بپرسید، نه از سرور استعلام محلی. سرور محلی جواب ذخیره شده و مهلت باقی مانده را می دهد؛ سرور معتبر مقدار واقعی رکورد را.
همین تفاوت را امروز روی دامنه خودمان دیدیم: سرور محلی رکوردهای NS را با مهلت ۲۱۶۰۰ ثانیه برگرداند و سرور معتبر همان رکوردها را با ۸۶۴۰۰. هیچ کدام غلط نیستند؛ اولی باقی مانده یک شمارش معکوس است و دومی عدد اصلی.
و یک چیز که بعد از هر تغییر ارزش دیدن دارد: از بیش از یک جا بپرسید. جواب یکسان نبودن، لزوما خرابی نیست؛ ممکن است هنوز حافظه ها خالی نشده باشند، یا حتی سرویس مقصد عمدا به هر پرسنده نشانی نزدیک تری بدهد. برای اینکه بدانید دامنه از اول چیست و چه کسی ثبتش کرده، مقاله دامنه چیست همان لایه را باز می کند.
مسیر سریع با هوش مصنوعی
جابه جا کردن یک سایت بدون قطعی، کاری بود که آدم ها یاد می گرفتند با یک بار خراب کردنش. حالا می شود کل نقشه را از روی زون واقعی خودتان در چند دقیقه درآورد، به این شرط که خروجی واقعی را بدهید و از مدل نخواهید مقدارها را حدس بزند.
- کل زون را در یک خط بگیرید: for t in A AAAA MX NS TXT SOA CAA; do dig +noall +answer $t example.com; done و به جای نمونه، دامنه خودتان را بگذارید.
- همان خروجی را دست نخورده بچسبانید و بگویید چه تغییری می خواهید بدهید: فقط سرور، یا کل سرورهای نام. کلاس مدل سریع و ارزان اینجا کافی است؛ کار، حساب کردن روی داده ای است که خودتان آورده اید.
- زمان بندی بخواهید، نه توصیه کلی: مهلت هر رکوردی که قرار است عوض شود، چند دقیقه قبل باید کم شود و چقدر باید صبر کرد.
- قبل از اجرا، دو مقدار را خودتان با چشم چک کنید: مهلت فعلی رکورد A و مهلت رکوردهای NS. اگر مدل عددی نوشت که در خروجی شما نیست، همان جا کل جواب را دور بیندازید.
نسخه آماده کپی
نقش تو مدیر DNS است. متن زیر خروجی خام رکوردهای یک دامنه است، دست نخورده.
{خروجی dig را اینجا بچسبانید}
تغییری که می خواهم بدهم: {فقط رکورد A، یا سرورهای نام، یا هر دو}
زمان دلخواه اجرا: {ساعت و روز}
فقط این ها را بنویس:
۱. مهلت فعلی هر رکوردی که قرار است عوض شود، عینا از همین متن.
۲. چند دقیقه یا ساعت قبل از اجرا باید مهلت را کم کنم و به چه مقدار.
۳. بعد از تغییر چقدر باید صبر کنم تا مطمئن شوم همه سرورهای استعلام جواب تازه را دارند، بر اساس همین مقدارها.
۴. یک فهرست کوتاه از چیزهایی که بعد از تغییر باید چک شوند، از جمله رکوردهای ایمیل.
قاعده: هیچ عددی ننویس که در متن بالا نیست. اگر مقداری در متن نیست بنویس در خروجی نبود. توصیه عمومی نده؛ فقط جدول زمانی همین دامنه.قبل از اعتماد به خروجی: این نقشه فقط تا جایی درست است که خروجی شما تازه باشد و از سرور معتبر گرفته شده باشد؛ خروجی سرور محلی مهلت باقی مانده را نشان می دهد و برنامه ریزی با آن، شما را زودتر از موعد مطمئن می کند. اجرای تغییر هم دست خودتان بماند: نه رکورد ایمیل را در همان روزی عوض کنید که سرور را جابه جا می کنید، و نه هیچ کدام را ساعتی که ترافیک سایت بالاست.
هوش مصنوعی در این کار
رکورد DNS متن است و متن، همان چیزی است که مدل زبانی در آن خوب است. خروجی dig را بچسبانید و بپرسید کدام رکورد نیست، چرا SPF قبول نمی شود، یا این مقدار SOA یعنی چه؛ جواب ها معمولا خوب اند. موضع ما اما در سمت مقابل روشن است: نگذارید مدل رکورد بنویسد و شما بدون فهمیدن آن را بگذارید. یک رکورد اشتباه در DNS، به اندازه مهلت همان رکورد اشتباه می ماند، و ایمیل تنها چیزی است که وقتی خراب می شود بی صدا خراب می شود.
ابزارهایی که واقعا کمک می کنند
- Claude برای خواندن خروجی dig و مقایسه دو زون با هم خوب کار می کند، مثلا وقتی می خواهید بدانید بین دامنه ای که ایمیلش می رسد و آن که نمی رسد چه فرقی هست. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست، پس مسیر رسمی ثبت نام و پرداخت وجود ندارد.
- Gemini برای توضیح فارسی اصطلاح ها و پیام های خطای DNS خوب است. صفحه خود گوگل می نویسد اپ جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
- Gemini Notebook کار درستش اینجا این است: صفحه راهنمای خود ارائه دهنده DNS تان را به آن بدهید و سوال را از داخل همان سند بپرسید، چون نام فیلدها و محدودیت ها در هر پنل فرق دارد. روی همان حساب گوگل کار می کند و ایران در فهرست مناطق در دسترس نیست.
کجا نتیجه معکوس می دهد
خطر مشخص اینجا رکوردی است که خوش قیافه است و غلط. مدل نحو SPF و DKIM و DMARC را می شناسد و به همان لحن مطمئن رکوردی می سازد که ممکن است از سقف ده استعلام رد شود، سرویسی را که واقعا ایمیل می فرستد جا بیندازد، یا سیاست DMARC را یک پله سفت تر از آنچه آماده اید بگذارد. آن سقف را RFC 7208 تعیین کرده و مدل موقع ساختن رکورد آن را نمی شمارد. خود انتروپیک هم این ساختن با اطمینان را در مستنداتش توهم می نامد و راه های کم کردنش را می نویسد. قاعده ما: رکورد پیشنهادی را قبل از گذاشتن با ابزار استعلام بسنجید و بعد از گذاشتن، یک ایمیل واقعی بفرستید و سرش را نگاه کنید. و چیزی که هرگز نباید در چت بچسبانید کلید API ارائه دهنده DNS یا کلید خصوصی DKIM است؛ راهنمای خود گوگل هم صریحا می گوید اطلاعات محرمانه را وارد نکنید. برای اینکه ببینید پرداخت هر کدام از این ابزارها از ایران چه شکلی دارد، راهنمای خرید را ببینید.
منبع ها: RFC 7208: SPF, the ten lookup limit Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available
حد این توصیه
هر مقداری که در این درس آمده مال زون خود ما در یک روز مشخص است و مقدار پیش فرض هیچ جایی نیست؛ دامنه شما ممکن است رکورد A با مهلت یک ساعت داشته باشد و آن وقت همه حساب های اینجا برای شما دو برابر می شود. زمان های استعلام هم از این سرور و از یک سرور استعلام عمومی گرفته شده اند: از داخل ایران و از روی شبکه های موبایل عددها فرق می کنند و ما آن را از اینجا نمی توانیم اندازه بگیریم. و مهم تر از همه، این درس درباره پیدا کردن نشانی است و نه درباره رسیدن به آن؛ نامی که به درستی به نشانی می رسد باز هم ممکن است باز نشود، و آن مشکل جای دیگری در مسیر است.
از تجربه خود ما
همه عددهای این درس را همان روز از همین سرور گرفتیم و خروجی خامشان در گزارش این جلسه هست، ولی جالب ترین چیزی که دیدیم عدد نبود. وقتی رکورد A دامنه خودمان را یک بار از سرور استعلام محلی و یک بار از سرور معتبر خودمان پرسیدیم، دو مجموعه نشانی متفاوت گرفتیم. هیچ کدام هم خراب نبود: سرویسی که جلوی سایت ما نشسته عمدا به هر پرسنده نشانی ای می دهد که به او نزدیک تر است. درسی که این برای کار روزمره دارد این است که «رکورد را چک کردم، درست بود» تا وقتی نگویید از کجا پرسیدید جمله کاملی نیست، و همین یک ابهام باعث می شود دو نفر سر یک تغییر DNS ساعت ها با هم بحث کنند در حالی که هر دو راست می گویند.
سوال هایی که واقعا پرسیده می شوند
چرا سایت بعد از تغییر DNS برای من باز می شود و برای همکارم نه؟
چون شما و او از دو سرور استعلام مختلف می پرسید و حافظه آن دو در یک لحظه خالی نمی شود. مهلت رکورد قدیمی برای هر کدام از یک زمان دیگری شروع شده. کاری هم لازم نیست بکنید جز صبر کردن به اندازه مهلت رکورد قبلی؛ خالی کردن حافظه دستگاه خودتان مشکل او را حل نمی کند.
عوض کردن DNS دستگاهم به یک سرور عمومی، اینترنت را سریع تر می کند؟
فقط همان بخش کوچک را سریع تر می کند و نه بقیه را. تفاوتی که اندازه گرفتیم بین یک استعلام تازه و یک استعلام ذخیره شده ۵۹ میلی ثانیه بود، و آن هم یک بار برای هر نام. بعد از گرفتن نشانی، بقیه سرعت سایت به مسیر و سرور مقصد بستگی دارد که با عوض کردن سرور استعلام تغییری نمی کنند.
رکورد را ساختم ولی هنوز پیدا نمی شود، اشتباه کجاست؟
اگر قبل از ساختن رکورد یک بار امتحانش کرده اید، احتمالا اشتباهی در کار نیست و فقط حافظه منفی است: جواب «وجود ندارد» ذخیره شده و تا پایان مهلتش باقی می ماند، که برای دامنه ما نیم ساعت است. برای مطمئن شدن، همان نام را مستقیم از سرور معتبر دامنه بپرسید؛ اگر آنجا جواب می دهد، رکورد درست است و فقط باید صبر کنید.