راهنمای کامل رکوردهای DNS: از A و AAAA تا MX، TXT و CAA

یکی از مهم‌ترین و درعین‌حال کم‌فهم‌ترین بخش‌های سامانه‌ی نام دامنه، مجموعه‌ای از داده‌های ساختاریافته به نام رکوردهای DNS است؛ رکوردهایی که تعیین می‌کنند نامِ یک دامنه به کدام آدرس، کدام سرورِ ایمیل، کدام سرویس و کدام گواهی متصل شود. اگر تا امروز تصور می‌کردید کارِ DNS تنها «تبدیلِ نام به آدرس» است، این راهنما نشان می‌دهد که پشتِ هر دامنه‌ی سالم، ده‌ها رکورد از نوع‌های گوناگون — از A و AAAA گرفته تا MX، TXT و CAA — در کنارِ هم و با نظمی دقیق کار می‌کنند.

در این مقاله‌ی مرجع، ابتدا ساختارِ یک فایلِ زون را خط‌به‌خط باز می‌کنیم و می‌بینیم که دستورهای $ORIGIN و $TTL و رکوردِ محوریِ SOA چه نقشی دارند. سپس به‌ترتیب سراغِ تک‌تکِ نوع‌های رکورد می‌رویم؛ توضیح می‌دهیم که رکورد A چرا برای مفید بودن به یک آدرسِ پایدار نیاز دارد، چرا رکورد CNAME را نمی‌توان روی ریشه‌ی دامنه گذاشت، رکورد MX با اولویت‌هایش چگونه مسیرِ نامه‌ها را می‌چیند و چگونه سه‌گانه‌ی SPF و DKIM و DMARC اعتبارِ ایمیلِ شما را تضمین می‌کنند. در انتها یک نمونه‌ی کاملِ فایلِ زون، استراتژیِ درستِ TTL هنگام مهاجرت، و رایج‌ترین خطاهای پیکربندی را مرور می‌کنیم.

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

#رکوردهای DNS در یک نگاه

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

سازمانِ IANA فهرستِ رسمیِ همه‌ی نوع‌های رکورد را نگه می‌دارد؛ فهرستی که ده‌ها نوعِ ثبت‌شده دارد اما در عملِ روزمره تنها حدودِ پانزده نوع از آن‌ها پرکاربردند. جدولِ زیر یک مرجعِ سریع از مهم‌ترین نوع‌های رکورد است. در ادامه‌ی مقاله هر کدام را جداگانه و مفصل بررسی می‌کنیم؛ اما داشتنِ این تصویرِ کلی از همان ابتدا کمک می‌کند بدانید هر رکورد در کجای زنجیره ایستاده است.

نوع رکورد	کاربرد	مثال (سمتِ راست = مقدار)	TTL پیشنهادی
A	نگاشتِ نام به آدرسِ IPv4	www → 93.184.216.34	3600
AAAA	نگاشتِ نام به آدرسِ IPv6	www → 2606:2800:220:1:248:1893:25c8:1946	3600
CNAME	نامِ مستعار برای یک نامِ دیگر	shop → www.example.com.	3600
MX	سرورِ گیرنده‌ی ایمیل	10 mail.example.com.	3600
TXT	متنِ آزاد (تأیید مالکیت، سیاست‌ها)	"v=spf1 -all"	3600
NS	واگذاریِ زون به نیم‌سرورها	ns1.example.com.	86400
SOA	اطلاعاتِ مرجعِ زون	یک رکورد در ریشه‌ی هر زون	86400
PTR	نگاشتِ معکوس؛ آدرس به نام	34 → www.example.com.	3600
SRV	مکان‌یابیِ سرویس (میزبان و پورت)	_sip._tcp → 10 5 5060 host	3600
CAA	مجوزِ صدورِ گواهیِ TLS	0 issue "letsencrypt.org"	3600
NAPTR	بازنویسیِ نام برای ENUM/SIP	قاعده‌های regex برای شماره‌ها	3600

نکته‌ی کلیدی: نوعِ رکورد، «شکلِ پاسخ» را تعیین می‌کند نه صرفاً محتوای آن را. یک نام می‌تواند هم‌زمان رکوردهای A، AAAA، MX و TXT داشته باشد؛ هر پرسش تنها رکوردهای هم‌نوعِ خودش را برمی‌گرداند و بقیه را نادیده می‌گیرد.

#آناتومیِ فایلِ زون: جایی که رکوردها زندگی می‌کنند

رکوردهای یک دامنه در ساختاری به نامِ فایلِ زون (Zone File) نگهداری می‌شوند. فایلِ زون یک فایلِ متنیِ ساده است که قالبِ استانداردِ آن در سندِ RFC 1035 تعریف شده است. هرچند امروزه بسیاری از افراد رکوردها را از طریقِ پنلِ گرافیکیِ ارائه‌دهنده‌ی خود مدیریت می‌کنند، اما آن پنل در پشتِ صحنه دقیقاً همین ساختارِ متنی را تولید می‌کند. آشنایی با فرمتِ خامِ فایلِ زون به شما اجازه می‌دهد پیام‌های خطا را بفهمید، رفتارِ رکوردها را دقیق پیش‌بینی کنید و مشکلات را سریع‌تر ریشه‌یابی کنید.

#ساختارِ یک خطِ رکورد

هر رکوردِ منبع (Resource Record یا به‌اختصار RR) از پنج بخش تشکیل می‌شود که به‌ترتیب از چپ به راست در فایل نوشته می‌شوند: نام، TTL، کلاس، نوع و داده. برای مثال خطِ زیر یک رکوردِ کامل است:

www.example.com.    3600    IN    A    93.184.216.34

در این خط، www.example.com. نام است (دقت کنید به نقطه‌ی انتهایی)، عددِ 3600 همان TTL بر حسبِ ثانیه است، IN کلاسِ رکورد (Internet) است که تقریباً همیشه همین مقدار را دارد، A نوعِ رکورد است و 93.184.216.34 داده‌ی رکورد. اگر نام و TTL و کلاس را ننویسید، از مقادیرِ پیش‌فرضِ بالای فایل یا از رکوردِ قبلی به‌ارث می‌رسند؛ به همین دلیل در فایل‌های واقعی اغلب فقط نوع و داده را می‌بینید.

#نامِ مطلق در برابرِ نامِ نسبی و نقشِ نقطه‌ی پایانی

ظریف‌ترین و پرخطاترین نکته‌ی فایلِ زون همین نقطه‌ی انتهایی است. نامی که به نقطه ختم می‌شود «مطلق» (Fully Qualified) در نظر گرفته می‌شود و همان‌طور که هست تفسیر می‌شود. اما نامی که نقطه‌ی پایانی ندارد «نسبی» است و مقدارِ $ORIGIN به انتهای آن اضافه می‌شود. اگر $ORIGIN برابرِ example.com. باشد، نوشتنِ www معادلِ www.example.com. است؛ اما اگر اشتباهاً www.example.com (بدونِ نقطه‌ی پایانی) بنویسید، سیستم آن را نسبی می‌پندارد و به www.example.com.example.com. تبدیل می‌کند — خطایی کلاسیک که باعثِ ناکار شدنِ نگاشت می‌شود.

#دستورهای کنترلی: $ORIGIN و $TTL

دو دستورِ کنترلیِ مهم در بالای فایلِ زون می‌آیند. دستورِ $ORIGIN پایه‌ی نام‌های نسبی را مشخص می‌کند و دستورِ $TTL مقدارِ پیش‌فرضِ زمانِ زندگیِ رکوردهایی را تعیین می‌کند که TTLِ صریح ندارند. مقدارِ TTL تعیین می‌کند که یک پاسخ چند ثانیه در حافظه‌ی پنهانِ سرورهای بازگردانی (Resolver) باقی بماند پیش از آن‌که دوباره پرسیده شود. انتخابِ درستِ این عدد — که در بخشِ استراتژیِ مهاجرت مفصل به آن می‌پردازیم — یکی از مهارت‌های کلیدیِ مدیریتِ DNS است. جزئیاتِ رفتارِ TTL و اولویتِ مقادیر در RFC 2181 شفاف‌سازی شده است.

#رکورد SOA: شناسنامه‌ی هر زون

هر زون دقیقاً یک رکوردِ SOA (مخففِ Start of Authority) دارد و این رکورد همیشه اولین رکوردِ زون است. رکوردِ SOA در حکمِ شناسنامه‌ی زون عمل می‌کند: مشخص می‌کند مرجعِ اصلیِ این زون کدام نیم‌سرور است، مسئولیتِ آن با چه کسی است و — مهم‌تر از همه — سرورهای ثانویه هر چند وقت یک‌بار باید داده‌ها را از سرورِ اصلی به‌روزرسانی کنند. ساختارِ یک رکوردِ SOA چنین است:

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
                2026071001  ; serial
                7200        ; refresh
                3600        ; retry
                1209600     ; expire
                86400 )     ; minimum

دو مقدارِ اولِ داخلِ پرانتز نیستند: ns1.example.com. نامِ نیم‌سرورِ اصلیِ زون است و admin.example.com. نشانیِ ایمیلِ مسئولِ زون — با این ظرافت که نشانه‌ی @ با یک نقطه جایگزین می‌شود، پس این مقدار در واقع یعنی admin@example.com. پنج عددِ داخلِ پرانتز قلبِ رفتارِ همگام‌سازیِ زون هستند و در جدولِ زیر یک‌به‌یک توضیح داده شده‌اند.

فیلد	معنی	توضیح و مقدارِ متعارف
serial	شماره‌ی نسخه‌ی زون	هر بار که زون را تغییر می‌دهید باید بزرگ‌تر شود؛ قالبِ رایج YYYYMMDDnn است. سرورِ ثانویه با مقایسه‌ی این عدد می‌فهمد که آیا نسخه‌ی تازه‌تری وجود دارد یا نه.
refresh	بازه‌ی بررسیِ به‌روزرسانی	هر چند ثانیه سرورِ ثانویه سراغِ سرورِ اصلی برود تا serial را بررسی کند. مقدارِ متعارف بینِ 3600 تا 7200 ثانیه.
retry	بازه‌ی تلاشِ مجدد	اگر تلاشِ refresh شکست بخورد، چند ثانیه بعد دوباره تلاش شود. معمولاً کوچک‌تر از refresh؛ مثلاً 3600.
expire	مهلتِ اعتبارِ داده‌ی ثانویه	اگر سرورِ ثانویه این‌قدر ثانویه نتواند به سرورِ اصلی برسد، داده‌ی خود را منقضی اعلام می‌کند و دیگر پاسخ نمی‌دهد. مقدارِ متعارف یک تا دو هفته، مثلاً 1209600.
minimum	TTLِ پاسخِ منفی	امروز معنایش «TTLِ پاسخِ منفی» (Negative Caching) است؛ یعنی چقدر یک پاسخِ «چنین نامی وجود ندارد» در حافظه‌ی پنهان بماند. مثلاً 86400.

مهم‌ترین درسِ عملیِ رکوردِ SOA این است که فراموش کردنِ افزایشِ serial پس از هر تغییر یکی از شایع‌ترین دلایلِ «چرا تغییرم اعمال نشد؟» است. اگر serial را بالا نبرید، سرورهای ثانویه فکر می‌کنند هیچ‌چیز عوض نشده و نسخه‌ی قدیمی را نگه می‌دارند. بسیاری از ابزارهای مدیریتی این افزایش را خودکار انجام می‌دهند، اما اگر فایل را دستی ویرایش می‌کنید، این کار بر عهده‌ی شماست.

#رکورد NS و منطقِ واگذاری

رکوردِ NS (مخففِ Name Server) مشخص می‌کند که مرجعِ پاسخ‌گویی به یک زون کدام نیم‌سرورها هستند. این رکورد در دو جا ظاهر می‌شود و درکِ تفاوتِ این دو، کلیدِ فهمِ کلِ ساختارِ سلسله‌مراتبیِ DNS است. رکوردهای NS هم در خودِ زون (در کنارِ سایرِ رکوردها) نوشته می‌شوند و هم در زونِ والد، جایی که واگذاری (Delegation) رخ می‌دهد.

#واگذاری چگونه کار می‌کند

وقتی دامنه‌ی example.com را ثبت می‌کنید، رجیستری‌ای که مسئولِ .com است در زونِ خود یک مجموعه رکوردِ NS برای example.com قرار می‌دهد که می‌گوید: «برای هر پرسشی درباره‌ی این دامنه، به این نیم‌سرورها مراجعه کنید.» به این ترتیب مسئولیتِ زون از والد به شما «واگذار» می‌شود. سرورِ بازگردانی این زنجیره را از ریشه شروع می‌کند، به .com می‌رسد، از آن‌جا به نیم‌سرورهای شما هدایت می‌شود و سرانجام پاسخِ نهایی را می‌گیرد. این همان فرایندی است که در مقاله‌ی DNS چیست به‌تفصیل شرح داده‌ایم.

#رکوردهای Glue: حلِ یک بن‌بستِ منطقی

حالا یک تناقضِ ظریف پیش می‌آید. فرض کنید نیم‌سرورِ دامنه‌ی example.com خودش ns1.example.com باشد. برای رسیدن به این نیم‌سرور باید آدرسِ ns1.example.com را بدانیم؛ اما برای دانستنِ آن آدرس باید از همان نیم‌سرور بپرسیم که هنوز به آن نرسیده‌ایم! این یک بن‌بستِ مرغ‌وتخم‌مرغ است. راه‌حل، رکوردهای Glue است: زونِ والد (.com) در کنارِ رکوردهای NS، آدرسِ عددیِ (A/AAAA) آن نیم‌سرورها را هم مستقیماً ارائه می‌دهد تا زنجیره قفل نشود.

رکوردهای Glue تنها زمانی لازم‌اند که نیم‌سرورِ یک دامنه، زیرِدامنه‌ای از خودِ همان دامنه باشد. اگر نیم‌سرورهای شما روی دامنه‌ی دیگری میزبانی شوند (مثلاً ns1.provider.net)، آدرسشان از زونِ آن دامنه‌ی دیگر گرفته می‌شود و نیازی به Glue نیست.

#رکورد A و AAAA: قلبِ نگاشتِ نام به آدرس

پرکاربردترین رکوردِ DNS بی‌شک رکوردِ A است. کارِ این رکورد بسیار ساده اما بنیادی است: یک نام را به یک آدرسِ IPv4 نگاشت می‌کند. وقتی می‌نویسید www.example.com. IN A 93.184.216.34، به تمامِ جهان اعلام می‌کنید که برای رسیدن به این نام باید به این آدرسِ عددی وصل شوند. رکوردِ AAAA (که «کوآد-اِی» خوانده می‌شود) دقیقاً همان کار را برای نسلِ جدیدِ آدرس‌ها یعنی IPv6 انجام می‌دهد و داده‌اش یک آدرسِ ۱۲۸ بیتیِ شش‌رقمیِ هگزادسیمال است.

#چرا یک رکورد A بدونِ آدرسِ پایدار بی‌فایده است

اینجا به مهم‌ترین نکته‌ی عملیِ این دو رکورد می‌رسیم. یک رکوردِ A دقیقاً به‌اندازه‌ی آدرسی که به آن اشاره می‌کند ارزش دارد. اگر آن آدرس مدام عوض شود، رکوردِ A شما پیوسته کهنه می‌شود و کاربران به سرورِ اشتباه یا به هیچ‌جا هدایت می‌شوند. به همین دلیل است که برای هر سرویسی که باید از بیرون در دسترس باشد — یک وب‌سایت، یک سرورِ ایمیل، یک سرویسِ راه دور یا یک دوربینِ تحتِ شبکه — به یک آی‌پی ثابت نیاز دارید. آدرسِ ثابت یعنی رکوردِ A یک بار تنظیم می‌شود و تا وقتی خودتان نخواهید، درست می‌ماند.

تفاوتِ این موضوع با آدرس‌های متغیر را در مقاله‌ی تفاوت آی‌پی ثابت و آی‌پی داینامیک به‌طورِ کامل شرح داده‌ایم؛ اما خلاصه‌اش این است: بیشترِ اتصالاتِ خانگی و اینترنتِ همراه، آدرسِ متغیر (Dynamic) دریافت می‌کنند که هر چند ساعت یا هر بار قطع‌ووصل عوض می‌شود. چنین آدرسی برای میزبانیِ پایدارِ یک نام به‌کارِ رکوردِ A نمی‌آید. راهکارهایی مانندِ آی‌پی ثابت خانگی دقیقاً برای همین نیاز طراحی شده‌اند: یک آدرسِ عددیِ ماندگار به شما می‌دهند تا بتوانید با خیالِ راحت رکوردِ A یا AAAA را رویش تنظیم کنید و سرویسِ خود را به دنیای بیرون معرفی کنید. سرویسِ آی‌پی ثابت و DNS اختصاصیِ dnsplus نیز بر همین اصل استوار است.

#چند رکورد A برای یک نام: توزیعِ بار و افزونگی

یک نام می‌تواند بیش از یک رکوردِ A داشته باشد. در این حالت سرورِ DNS معمولاً همه‌ی آدرس‌ها را برمی‌گرداند اما ترتیبشان را در هر پاسخ می‌چرخاند (تکنیکی به نامِ Round-Robin). این روش نوعی توزیعِ سبکِ بار و افزونگیِ ابتدایی فراهم می‌کند: اگر یک آدرس در دسترس نباشد، کلاینت می‌تواند سراغِ آدرسِ بعدی برود. با این حال Round-Robin جای‌گزینِ یک متعادل‌کننده‌ی بارِ واقعی نیست، چون DNS از سلامتِ سرورها بی‌خبر است و ممکن است کاربر را به آدرسی از کار افتاده بفرستد.

#رکورد CNAME: نامِ مستعار و محدودیت‌های آن

رکوردِ CNAME (مخففِ Canonical Name) یک نام را به نامِ دیگری «مستعار» می‌کند. وقتی می‌نویسید shop.example.com. IN CNAME www.example.com.، در واقع می‌گویید: «هر پاسخی که برای www.example.com وجود دارد، همان پاسخِ shop هم هست.» سرورِ بازگردانی با دیدنِ CNAME پرسشِ خود را به نامِ هدف هدایت می‌کند و آدرسِ نهایی را از آن‌جا می‌گیرد. این رکورد برای وقتی عالی است که می‌خواهید چند نام همیشه به یک مقصدِ واحد اشاره کنند و نخواهید هر بار آدرسِ عددی را در چند جا تکرار و نگه‌داری کنید.

#چرا CNAME را نمی‌توان روی ریشه‌ی دامنه گذاشت

مهم‌ترین محدودیتِ CNAME این است که یک نام اگر رکوردِ CNAME داشته باشد، نمی‌تواند هیچ رکوردِ دیگری داشته باشد. این قاعده از دلِ استانداردِ RFC 1035 می‌آید و منطقش روشن است: اگر نامی مستعارِ نامِ دیگری باشد، همه‌ی داده‌هایش باید از آن نامِ دیگر بیایند و نمی‌تواند هم‌زمان داده‌ی مستقلِ خودش را هم داشته باشد. حالا مشکل این‌جاست که ریشه‌ی دامنه (که به آن Apex یا Naked Domain می‌گویند، یعنی example.com بدونِ هیچ زیرِدامنه‌ای) به‌اجبار باید رکوردهای SOA و NS داشته باشد. بنابراین گذاشتنِ CNAME روی ریشه با این رکوردهای اجباری در تضاد می‌افتد و مجاز نیست.

#راهکارها: رکورد ALIAS و ANAME

برای حلِ همین محدودیت، برخی ارائه‌دهندگانِ DNS نوعی رکوردِ غیراستاندارد به نامِ ALIAS یا ANAME معرفی کرده‌اند. این رکوردها از دیدِ کاربر مثلِ CNAME رفتار می‌کنند اما در پشتِ صحنه توسطِ خودِ سرورِ DNS به رکوردهای A/AAAA ترجمه می‌شوند؛ یعنی سرورِ مرجع نامِ هدف را خودش پیشاپیش حل می‌کند و پاسخِ نهایی را به‌شکلِ یک رکوردِ A معمولی به دنیا می‌دهد. به این ترتیب می‌توانید عملاً روی ریشه‌ی دامنه رفتاری شبیهِ CNAME داشته باشید بدونِ آن‌که قاعده‌ی استاندارد را بشکنید. توجه کنید که ALIAS/ANAME بخشی از استانداردِ رسمیِ DNS نیستند و پشتیبانی از آن‌ها به ارائه‌دهنده بستگی دارد.

قاعده‌ی طلایی: هرگز روی ریشه‌ی دامنه CNAME نگذارید. اگر می‌خواهید ریشه به یک نامِ دیگر اشاره کند، یا از ALIAS/ANAME استفاده کنید یا مستقیماً رکوردِ A با یک آی‌پی ثابت بگذارید.

#رکورد MX: مسیریابیِ ایمیل با اولویت

رکوردِ MX (مخففِ Mail Exchanger) مشخص می‌کند که نامه‌های الکترونیکیِ یک دامنه باید به کدام سرور تحویل داده شوند. ویژگیِ متمایزِ این رکورد داشتنِ یک عددِ اولویت (Priority) است که پیش از نامِ سرور می‌آید. سرورِ فرستنده همیشه ابتدا سراغِ رکوردِ MX با کم‌ترین عدد می‌رود؛ یعنی عددِ کوچک‌تر یعنی اولویتِ بالاتر. اگر آن سرور در دسترس نباشد، به‌ترتیب سراغِ اولویت‌های بعدی می‌رود. جدولِ زیر یک نمونه‌ی متعارف را نشان می‌دهد:

نام	اولویت	سرورِ گیرنده	رفتار
example.com.	10	mail1.example.com.	گیرنده‌ی اصلی؛ اول امتحان می‌شود
example.com.	20	mail2.example.com.	پشتیبان؛ اگر اصلی در دسترس نباشد
example.com.	30	mail3.provider.net.	پشتیبانِ دوم روی سرویسِ دیگر

دو نکته‌ی کلیدی درباره‌ی MX وجود دارد. نخست این‌که مقصدِ رکوردِ MX باید یک نام باشد که خودش رکوردِ A/AAAA دارد، نه یک آدرسِ عددیِ مستقیم و نه یک CNAME؛ اشاره‌ی MX به یک CNAME نقضِ استاندارد است و بسیاری از سرورها آن را رد می‌کنند. دوم این‌که اگر دو رکوردِ MX اولویتِ برابر داشته باشند، بارِ ورودی میانشان به‌شکلِ تصادفی پخش می‌شود که می‌تواند برای توزیعِ بار مفید باشد. برای دریافتِ پایدارِ ایمیل، سروری که MX به آن اشاره می‌کند نیز باید روی یک آی‌پی ثابت نشسته باشد تا هم قابلِ اعتماد بماند و هم — همان‌طور که در بخشِ PTR خواهیم دید — بتواند نگاشتِ معکوسِ درست داشته باشد.

#رکورد TXT: متنِ آزاد با کاربردهای جدی

رکوردِ TXT در نگاهِ اول ساده‌ترین رکورد است: صرفاً یک رشته‌ی متنیِ آزاد را به یک نام می‌چسباند. اما همین سادگی آن را به انعطاف‌پذیرترین رکوردِ DNS تبدیل کرده است. امروز بخشِ بزرگی از زیرساختِ اعتماد و امنیتِ ایمیل و نیز فرایندِ «اثباتِ مالکیتِ دامنه» روی رکوردهای TXT بنا شده است. وقتی سرویسی از شما می‌خواهد برای اثباتِ مالکیتِ دامنه یک رشته‌ی خاص را به‌شکلِ رکوردِ TXT اضافه کنید، در واقع دارد بررسی می‌کند که آیا شما واقعاً به تنظیماتِ DNSِ آن دامنه دسترسی دارید یا نه.

یک نکته‌ی فنیِ مهم: هر رشته‌ی متنیِ داخلِ رکوردِ TXT حداکثر ۲۵۵ کاراکتر است. برای متن‌های بلندتر (مثلِ کلیدهای عمومیِ DKIM) باید متن را به چند رشته‌ی داخلِ گیومه تقسیم کرد که سرور آن‌ها را پشتِ‌سرِ‌هم به هم می‌چسباند. سه کاربردِ مهمِ رکوردِ TXT — یعنی SPF، DKIM و DMARC — آن‌قدر مهم‌اند که هر کدام را جداگانه بررسی می‌کنیم.

#SPF: تعیینِ فرستنده‌های مجازِ ایمیل

سیاستِ فرستنده (Sender Policy Framework یا SPF) که در RFC 7208 تعریف شده است، یک رکوردِ TXT روی ریشه‌ی دامنه است که فهرست می‌کند کدام سرورها مجازند از طرفِ این دامنه ایمیل بفرستند. وقتی سرورِ گیرنده نامه‌ای دریافت می‌کند، آدرسِ سرورِ فرستنده را با فهرستِ SPFِ دامنه مقایسه می‌کند؛ اگر فرستنده در فهرست نباشد، نامه مشکوک تلقی می‌شود. یک رکوردِ SPFِ ساده چنین است:

example.com.   3600   IN   TXT   "v=spf1 ip4:93.184.216.34 include:_spf.provider.net -all"

اجزای این رشته را بشکافیم: v=spf1 نسخه را مشخص می‌کند؛ ip4:93.184.216.34 یک آدرسِ مجاز را اعلام می‌کند (به همین دلیل داشتنِ یک آی‌پی ثابت برای سرورِ ایمیل ضروری است — نمی‌توان آدرسی را در SPF مجاز کرد که هر روز عوض می‌شود)؛ include:_spf.provider.net فهرستِ سرورهای یک ارائه‌دهنده‌ی دیگر را هم به سیاست اضافه می‌کند؛ و -all که به آن «Hard Fail» می‌گویند اعلام می‌کند هر فرستنده‌ی دیگری که در فهرست نیست باید رد شود. جای‌گزینِ نرم‌ترِ آن ~all (Soft Fail) است که نامه را رد نمی‌کند بلکه فقط علامت‌گذاری می‌کند.

یک دامنه باید تنها یک رکوردِ SPF داشته باشد. داشتنِ دو رکوردِ v=spf1 روی یک نام، طبقِ استاندارد نتیجه‌ی نامعتبر می‌دهد و اعتبارِ ایمیلِ شما را خراب می‌کند. همچنین تعدادِ کلِ عملیاتِ جست‌وجوی DNS در یک SPF نباید از ۱۰ بگذرد.

#DKIM: امضای رمزنگاریِ نامه‌ها

در حالی که SPF می‌گوید «چه کسی مجاز به فرستادن است»، امضای دیجیتالیِ نامه (DomainKeys Identified Mail یا DKIM) که در RFC 6376 تعریف شده، یک لایه‌ی قوی‌ترِ اعتماد اضافه می‌کند: هر نامه با یک کلیدِ خصوصی امضای رمزنگاری می‌شود و کلیدِ عمومیِ متناظرش در یک رکوردِ TXT منتشر می‌شود. سرورِ گیرنده امضا را با کلیدِ عمومی راستی‌آزمایی می‌کند و مطمئن می‌شود که نامه در راه دستکاری نشده و واقعاً از دامنه‌ی ادعاشده آمده است. رکوردِ کلیدِ عمومیِ DKIM زیرِ یک نامِ خاص با ساختارِ selector._domainkey.example.com قرار می‌گیرد:

mail2026._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7..." )

بخشِ mail2026 در این‌جا همان «Selector» است؛ یک برچسبِ دلخواه که به شما اجازه می‌دهد چند کلیدِ هم‌زمان داشته باشید و کلیدها را دوره‌ای بچرخانید بدونِ آن‌که جریانِ ایمیل قطع شود. k=rsa نوعِ الگوریتم و p=... خودِ کلیدِ عمومی است. چون کلیدها بلندند، معمولاً متن به چند رشته‌ی داخلِ گیومه تقسیم می‌شود. نکته‌ی امنیتیِ کلیدی این است که کلیدِ خصوصی هرگز در DNS قرار نمی‌گیرد و فقط روی سرورِ امضاکننده می‌ماند.

#DMARC: سیاستِ نهایی و گزارش‌گیری

سومین ضلعِ این مثلث، احرازِ هویت و گزارشِ مبتنی بر دامنه (Domain-based Message Authentication یا DMARC) است که در RFC 7489 تعریف شده است. DMARC روی SPF و DKIM سوار می‌شود و دو کارِ مهم انجام می‌دهد: نخست به سرورِ گیرنده می‌گوید اگر نامه‌ای هم SPF و هم DKIM را رد کرد، چه کند (رد کند، به قرنطینه بفرستد یا فقط رصد کند)؛ و دوم، سازوکاری برای دریافتِ گزارش فراهم می‌کند تا مالکِ دامنه ببیند چه کسانی دارند از طرفِ دامنه‌اش ایمیل می‌فرستند. رکوردِ DMARC زیرِ نامِ ویژه‌ی _dmarc قرار می‌گیرد:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

در این رشته، p=quarantine سیاست را روی «قرنطینه» می‌گذارد (گزینه‌های دیگر none برای فقط رصد و reject برای ردِ کامل هستند)؛ rua=mailto:... نشانیِ دریافتِ گزارش‌های تجمیعی است؛ adkim=s و aspf=s هم‌ترازیِ سخت‌گیرانه را فعال می‌کنند؛ و pct=100 یعنی سیاست روی صددرصدِ نامه‌ها اعمال شود. توصیه‌ی عملی این است که از p=none شروع کنید، چند هفته گزارش‌ها را بخوانید تا مطمئن شوید همه‌ی فرستنده‌های قانونی درست پیکربندی شده‌اند، و سپس به‌تدریج سیاست را به quarantine و در نهایت reject سخت‌گیرتر کنید.

سه‌گانه‌ی SPF، DKIM و DMARC امروز یک ضرورتِ عملی است، نه یک تجمل. بسیاری از سرویس‌دهنده‌های بزرگِ ایمیل نامه‌های دامنه‌هایی را که این سه را درست تنظیم نکرده‌اند یا مستقیم رد می‌کنند یا به پوشه‌ی هرزنامه می‌فرستند.

#رکورد PTR و زون‌های معکوس

تا این‌جا همه‌ی رکوردها نام را به آدرس نگاشت می‌کردند؛ اما گاهی به عکسِ این نیاز داریم: از یک آدرسِ عددی به نامِ متناظرش برسیم. این کارِ رکوردِ PTR (مخففِ Pointer) است و به آن «DNS معکوس» (Reverse DNS) می‌گویند. نگاشتِ معکوس در یک فضای نامِ ویژه انجام می‌شود: برای IPv4 دامنه‌ی in-addr.arpa و برای IPv6 دامنه‌ی ip6.arpa. نکته‌ی ظریف این است که آدرس در این فضا وارونه نوشته می‌شود. برای مثال، نگاشتِ معکوسِ آدرسِ 93.184.216.34 زیرِ نامِ 34.216.184.93.in-addr.arpa قرار می‌گیرد:

34.216.184.93.in-addr.arpa.   3600   IN   PTR   www.example.com.

دلیلِ این وارونگی، منطقِ سلسله‌مراتبیِ DNS است. در نام‌های معمولی، بخشِ عام‌تر (مثلِ com) سمتِ راست است و هرچه به چپ می‌رویم خاص‌تر می‌شود. در آدرس‌های IP برعکس است: بخشِ عام‌تر (شبکه) سمتِ چپ و بخشِ خاص‌تر (میزبان) سمتِ راست است. برای هماهنگ کردنِ این دو منطق، آدرس را وارونه می‌کنند تا واگذاریِ زون‌های معکوس هم مثلِ زون‌های معمولی از راست به چپ کار کند.

#چرا سرورهای ایمیل به نگاشتِ معکوسِ درست نیاز دارند

مهم‌ترین کاربردِ عملیِ PTR در دنیای ایمیل است. تقریباً همه‌ی سرورهای گیرنده‌ی ایمیل، پیش از پذیرشِ نامه، یک بررسیِ ساده اما سخت‌گیرانه انجام می‌دهند: آدرسِ سرورِ فرستنده را می‌گیرند، رکوردِ PTR آن را می‌پرسند تا به یک نام برسند، و سپس رکوردِ A آن نام را می‌پرسند تا ببینند آیا دوباره به همان آدرسِ اولیه بازمی‌گردد یا نه. اگر این چرخه‌ی رفت‌وبرگشت (Forward-Confirmed reverse DNS) بسته نشود، نامه با احتمالِ بالا هرزنامه تلقی می‌شود. به بیانِ ساده، سرورِ ایمیلِ شما باید هم رکوردِ A رو به جلو داشته باشد و هم رکوردِ PTR معکوس، و این دو باید کاملاً با هم بخوانند.

و اینجا دوباره اهمیتِ آدرسِ پایدار خود را نشان می‌دهد: رکوردِ PTR معمولاً در اختیارِ صاحبِ بلوکِ آدرس (ارائه‌دهنده‌ی شبکه) است، نه صاحبِ دامنه. برای آن‌که بتوانید یک PTR اختصاصیِ منطبق با نامِ دامنه‌تان داشته باشید، به آدرسی نیاز دارید که واقعاً به شما اختصاص یافته و ثابت باشد. سرویس‌های آی‌پی ثابت ابری و آی‌پی ثابت چندمنطقه‌ای دقیقاً همین امکان را فراهم می‌کنند و اجازه می‌دهند نگاشتِ معکوس را مطابقِ نیازتان تنظیم کنید — چیزی که با آدرس‌های اشتراکی و متغیر ممکن نیست. اگر با مشکلاتِ نگاشتِ معکوس یا ناسازگاریِ رکوردها روبه‌رو شدید، راهنمای عیب‌یابی مشکلات DNS و آی‌پی ثابت گام‌به‌گام کمکتان می‌کند.

#رکورد SRV: مکان‌یابیِ سرویس‌ها

رکوردِ SRV (مخففِ Service) که در RFC 2782 تعریف شده، از رکوردِ A یک قدم فراتر می‌رود: نه‌تنها می‌گوید یک سرویس روی کدام میزبان است، بلکه می‌گوید روی کدام پورت هم هست و با چه اولویت و وزنی. این رکورد برای پروتکل‌هایی مثلِ ارتباطاتِ صوتیِ SIP، پیام‌رسانِ XMPP و سرویس‌های دایرکتوریِ سازمانی کاربردِ فراوان دارد. ساختارِ نامِ SRV ویژه است و با دو برچسبِ زیرخط‌دار شروع می‌شود: نامِ سرویس و پروتکل. برای مثال:

_sip._tcp.example.com.   3600   IN   SRV   10 60 5060 sipserver.example.com.

چهار مقدارِ داده به‌ترتیب یعنی: 10 اولویت (مثلِ MX، کوچک‌تر مقدم‌تر)، 60 وزن (برای توزیعِ بار میانِ رکوردهای هم‌اولویت)، 5060 شماره‌ی پورت، و sipserver.example.com. نامِ میزبانِ هدف. بدینسان یک کلاینت می‌تواند تنها با دانستنِ نامِ دامنه و نوعِ سرویس، بفهمد دقیقاً به کدام میزبان و کدام پورت وصل شود — بدونِ آن‌که پورت‌ها در برنامه هارد کد شده باشند.

#رکورد CAA: کنترلِ صدورِ گواهیِ امنیتی

رکوردِ CAA (مخففِ Certification Authority Authorization) که در RFC 8659 تعریف شده، یک لایه‌ی امنیتیِ ارزشمند است که مشخص می‌کند کدام مراجعِ صدورِ گواهی (Certificate Authority) مجازند برای دامنه‌ی شما گواهیِ TLS صادر کنند. پیش از این رکورد، هر مرجعِ صدور می‌توانست برای هر دامنه‌ای گواهی بدهد که یک ریسکِ امنیتی بود. با CAA شما صریحاً فهرستِ مراجعِ مجاز را اعلام می‌کنید و مراجع موظف‌اند پیش از صدور، این رکورد را بررسی کنند. نمونه:

example.com.   3600   IN   CAA   0 issue "letsencrypt.org"
example.com.   3600   IN   CAA   0 iodef "mailto:security@example.com"

در خطِ نخست، برچسبِ issue اعلام می‌کند تنها مرجعِ letsencrypt.org مجازِ صدور است. برچسبِ issuewild همین کار را برای گواهی‌های Wildcard انجام می‌دهد و برچسبِ iodef نشانیِ گزارشِ تخلف را مشخص می‌کند. عددِ 0 ابتدای هر خط «پرچمِ» رکورد است. توجه کنید که CAA جای‌گزینِ سایرِ لایه‌های امنیتی نیست؛ فقط یک سدِ اضافه در برابرِ صدورِ گواهیِ غیرمجاز است.

#رکورد NAPTR و رکوردهای Wildcard

#رکورد NAPTR

رکوردِ NAPTR (مخففِ Naming Authority Pointer) یکی از پیچیده‌ترین و کم‌کاربردترین رکوردهاست و بیشتر در سامانه‌های تلفنیِ مبتنی بر اینترنت و نگاشتِ شماره‌های تلفن به نشانی‌های اینترنتی (استانداردی به نامِ ENUM) به کار می‌رود. این رکورد قواعدی از جنسِ عبارتِ باقاعده (Regular Expression) را نگه می‌دارد که نشان می‌دهد چگونه یک نام باید بازنویسی و به رکوردِ دیگری هدایت شود. به‌دلیلِ پیچیدگی و کاربردِ تخصصی، در بیشترِ دامنه‌های معمولی هرگز با NAPTR سروکار نخواهید داشت؛ اما دانستنِ وجودِ آن به فهمِ گستره‌ی کاملِ توانمندیِ DNS کمک می‌کند. فهرستِ کاملِ نوع‌های رکورد را می‌توانید در این مرجعِ جامع ببینید.

#رکوردهای Wildcard

گاهی می‌خواهید همه‌ی زیرِدامنه‌هایی که صریحاً تعریف نشده‌اند به یک مقصدِ واحد بروند. برای این کار از یک رکوردِ Wildcard استفاده می‌شود که با ستاره (*) نوشته می‌شود:

*.example.com.   3600   IN   A   93.184.216.34

این رکورد می‌گوید هر نامی مثلِ foo.example.com یا bar.example.com که رکوردِ صریحِ خودش را نداشته باشد، به این آدرس برود. اما Wildcard چند دامِ مهم دارد. نخست این‌که فقط برای نام‌هایی فعال می‌شود که هیچ رکوردی ندارند؛ اگر foo.example.com حتی یک رکوردِ TXT داشته باشد، دیگر Wildcardِ A شاملش نمی‌شود. دوم این‌که Wildcard تنها یک سطح را پوشش می‌دهد و به‌شکلِ بازگشتی روی زیرِدامنه‌های چندلایه اعمال نمی‌شود. رفتارِ دقیقِ Wildcard از منابعِ رایجِ سوءتفاهم است و بهتر است تنها زمانی از آن استفاده کنید که واقعاً به آن نیاز دارید.

#یک نمونه‌ی کاملِ فایلِ زون

حال که با تک‌تکِ رکوردها آشنا شدیم، بیایید همه را در قالبِ یک فایلِ زونِ واقعی و منسجم کنارِ هم بگذاریم. مثالِ زیر یک زونِ کاملِ متعارف برای دامنه‌ی example.com است که وب، ایمیل، احرازِ هویتِ فرستنده و کنترلِ گواهی را پوشش می‌دهد. این نمونه را به‌عنوانِ یک الگوی مرجع نگه دارید:

$ORIGIN example.com.
$TTL 3600

@       IN  SOA  ns1.example.com. admin.example.com. (
                2026071001  ; serial
                7200        ; refresh
                3600        ; retry
                1209600     ; expire
                86400 )     ; minimum

; --- Name servers ---
@           IN  NS      ns1.example.com.
@           IN  NS      ns2.example.com.
ns1         IN  A       93.184.216.34
ns2         IN  A       93.184.216.35

; --- Web (apex + www) ---
@           IN  A       93.184.216.34
@           IN  AAAA    2606:2800:220:1:248:1893:25c8:1946
www         IN  CNAME   example.com.
shop        IN  CNAME   www.example.com.

; --- Mail routing ---
@           IN  MX      10 mail1.example.com.
@           IN  MX      20 mail2.example.com.
mail1       IN  A       93.184.216.40
mail2       IN  A       93.184.216.41

; --- Email authentication ---
@           IN  TXT     "v=spf1 ip4:93.184.216.40 ip4:93.184.216.41 -all"
mail2026._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
_dmarc      IN  TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; --- Certificate authorization ---
@           IN  CAA     0 issue "letsencrypt.org"

; --- Service discovery ---
_sip._tcp   IN  SRV     10 60 5060 sipserver.example.com.
sipserver   IN  A       93.184.216.50

چند نکته را در این فایل مرور کنید: نشانه‌ی @ معادلِ خودِ $ORIGIN یعنی ریشه‌ی دامنه است؛ نام‌های نسبی مثلِ www و mail1 نقطه‌ی پایانی ندارند چون قرار است $ORIGIN به آن‌ها بچسبد؛ اما نام‌های مقصد مثلِ example.com. نقطه‌ی پایانی دارند چون مطلق‌اند. همچنین دقت کنید که ریشه (@) رکوردِ A دارد نه CNAME — دقیقاً به همان دلیلی که پیش‌تر گفتیم — و www است که به‌شکلِ CNAME به ریشه اشاره می‌کند.

#خواندنِ رکوردها با dig: از تئوری تا عمل

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

$ dig example.com A +short
93.184.216.34

$ dig example.com MX +short
10 mail1.example.com.
20 mail2.example.com.

$ dig example.com TXT +short
"v=spf1 ip4:93.184.216.40 ip4:93.184.216.41 -all"

$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

$ dig -x 93.184.216.34 +short
www.example.com.

سوییچِ +short فقط داده‌ی نهایی را نشان می‌دهد؛ اگر آن را بردارید، پاسخِ کامل شاملِ بخشِ ANSWER، مقدارِ TTLِ باقی‌مانده و وضعیتِ پاسخ را می‌بینید که برای عیب‌یابی بسیار مفید است. دستورِ dig -x هم میان‌بری برای پرسشِ معکوس (PTR) است که خودش آدرس را وارونه و به in-addr.arpa تبدیل می‌کند. عادت به کار با dig یکی از مفیدترین مهارت‌هایی است که در مدیریتِ DNS می‌توانید کسب کنید.

#استراتژیِ TTL هنگام مهاجرت و تغییرِ رکوردها

مقدارِ TTL هر رکورد یک بده‌بستان است. مقدارِ بالا یعنی سرورهای بازگردانی پاسخ را طولانی‌تر در حافظه‌ی پنهان نگه می‌دارند؛ این کار بار را کم و سرعت را زیاد می‌کند اما هر تغییری را کُند می‌سازد. مقدارِ پایین یعنی تغییرات سریع اعمال می‌شوند اما بارِ پرسش بیشتر می‌شود. برای عملیاتِ روزمره، مقادیرِ متوسط (مثلِ 3600 ثانیه) تعادلِ خوبی‌اند. اما هنگامِ مهاجرت — مثلاً وقتی می‌خواهید آدرسِ سرور را عوض کنید — یک تکنیکِ استاندارد وجود دارد:

گام	زمان	اقدام	هدف
۱	حداقل یک TTL قبل	TTL رکوردِ هدف را به مقدارِ کم (مثلاً 300) کاهش دهید	تا حافظه‌های پنهان کوتاه‌عمر شوند
۲	لحظه‌ی مهاجرت	مقدارِ رکورد را به آدرسِ جدید تغییر دهید	تغییر با کم‌ترین تأخیرِ ممکن پخش می‌شود
۳	پس از پایدار شدن	هر دو مقصدِ قدیم و جدید را موقتاً فعال نگه دارید	تا کاربرانِ با کشِ قدیمی هم سرویس بگیرند
۴	پس از اطمینان	TTL را دوباره به مقدارِ عادی (3600) بالا ببرید	بازگشت به کارایی و بارِ کم

نکته‌ی کلیدی این است که کاهشِ TTL باید پیش از مهاجرت انجام شود و دستِ‌کم به‌اندازه‌ی مقدارِ TTLِ قدیمی زودتر؛ چون خودِ آن کاهش هم باید صبر کند تا کشِ قبلی منقضی شود. اگر لحظه‌ی آخر TTL را پایین بیاورید، فایده‌ای ندارد چون سرورها هنوز مقدارِ بالای قبلی را در کش دارند.

#افسانه‌ی «انتشار» DNS

یکی از رایج‌ترین سوءتفاهم‌ها این جمله است: «صبر کنید تا DNS منتشر (Propagate) شود؛ ممکن است ۲۴ تا ۴۸ ساعت طول بکشد.» واقعیت این است که چیزی به نامِ انتشار وجود ندارد. وقتی شما رکوردی را روی نیم‌سرورِ مرجعِ خود تغییر می‌دهید، آن تغییر بی‌درنگ روی همان سرور اعمال می‌شود. آنچه واقعاً زمان می‌برد، فقط انقضای حافظه‌ی پنهان در سرورهای بازگردانیِ سراسرِ جهان است. هر سرورِ بازگردانی پاسخِ قبلی را دقیقاً به‌اندازه‌ی TTLِ آن نگه می‌دارد و تا آن مدت سراغِ سرورِ شما نمی‌آید تا مقدارِ تازه را بگیرد.

پس «۴۸ ساعت» نه یک قانونِ جادویی، بلکه صرفاً بازتابِ TTLهای بالایی است که در گذشته مرسوم بود. اگر TTLِ رکوردتان 300 ثانیه باشد، حداکثر پنج دقیقه بعد همه‌ی کش‌ها تازه شده‌اند. این دقیقاً همان دلیلی است که تکنیکِ کاهشِ TTL پیش از مهاجرت این‌قدر کارساز است. اصطلاح‌شناسیِ دقیقِ این مفاهیم در RFC 8499 که به واژگانِ استانداردِ DNS اختصاص دارد، آمده است.

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

#خطاهای رایج در پیکربندیِ رکوردها

بسیاری از خرابی‌های DNS از چند اشتباهِ تکراری سرچشمه می‌گیرند. جدولِ زیر شایع‌ترین آن‌ها را کنارِ راه‌حلشان می‌آورد تا فهرستی برای وارسی داشته باشید:

خطا	نشانه	راه‌حل
فراموشیِ نقطه‌ی پایانی در نامِ مطلق	نام به‌شکلِ عجیب دوبرابر می‌شود	همه‌ی نام‌های مطلق را با نقطه پایان دهید
افزایش‌ندادنِ serial در SOA	تغییرات روی سرورهای ثانویه اعمال نمی‌شود	پس از هر ویرایش serial را بالا ببرید
گذاشتنِ CNAME روی ریشه‌ی دامنه	خطای اعتبارسنجی یا از کار افتادنِ ایمیل	از A با آی‌پی ثابت یا ALIAS استفاده کنید
اشاره‌ی MX به یک CNAME	ردِ نامه توسطِ برخی سرورها	مقصدِ MX باید نامی با رکوردِ A باشد
دو رکوردِ SPF روی یک نام	SPF کلاً نامعتبر می‌شود	همه‌ی قواعد را در یک رکوردِ v=spf1 ادغام کنید
نبودِ رکوردِ PTR منطبق برای سرورِ ایمیل	نامه‌ها هرزنامه تلقی می‌شوند	روی آی‌پی ثابت، PTR منطبق با A تنظیم کنید
TTLِ بیش‌ازحد بالا هنگامِ تغییرِ برنامه‌ریزی‌شده	تغییرات ساعت‌ها معلق می‌مانند	پیش از مهاجرت TTL را کاهش دهید

#جمع‌بندی

رکوردهای DNS ستون‌های نامرئیِ هر سرویسِ اینترنتی هستند. از رکوردِ A که نام را به آدرس می‌رساند تا SOA که زون را مدیریت می‌کند، از سه‌گانه‌ی SPF و DKIM و DMARC که اعتبارِ ایمیل را تضمین می‌کنند تا PTR که پلِ بازگشت از آدرس به نام است — هر رکورد وظیفه‌ای دقیق و جای‌گاهی مشخص دارد. درکِ درستِ این ساختار به شما اجازه می‌دهد سرویس‌هایتان را پایدار، امن و قابلِ‌اعتماد نگه دارید و هنگامِ بروزِ مشکل، به‌جای حدس‌زدن، ریشه‌ی خطا را دقیق پیدا کنید.

یک نخِ مشترک در سرتاسرِ این راهنما تکرار شد: تقریباً هر رکوردِ مهمی که یک سرویسِ در دسترس را به دنیا معرفی می‌کند — چه A، چه MX و چه PTR — برای مفید بودن به یک آی‌پی ثابت نیاز دارد. اگر می‌خواهید سرویس‌هایتان را روی یک آدرسِ پایدار و یک DNS اختصاصی بنا کنید، تیمِ dnsplus آماده‌ی کمک است؛ می‌توانید از صفحه‌ی درباره‌ی ما با رویکردِ ما بیشتر آشنا شوید یا از راهِ صفحه‌ی تماس با ما پرسش‌هایتان را با ما در میان بگذارید.

#پرسش‌های پرتکرار

#تفاوتِ رکوردِ A و AAAA در چیست؟

هر دو رکورد یک نام را به یک آدرسِ عددی نگاشت می‌کنند، اما رکوردِ A برای آدرس‌های نسلِ چهارم (IPv4) مثلِ 93.184.216.34 است و رکوردِ AAAA برای آدرس‌های نسلِ ششم (IPv6) که بسیار بلندتر و به‌شکلِ هگزادسیمال نوشته می‌شوند. یک نام می‌تواند هم‌زمان هر دو را داشته باشد؛ در این حالت کلاینت بسته به پشتیبانیِ شبکه‌اش یکی را انتخاب می‌کند.

#چرا نمی‌توانم روی ریشه‌ی دامنه‌ام رکوردِ CNAME بگذارم؟

چون طبقِ استاندارد، نامی که رکوردِ CNAME دارد نمی‌تواند هیچ رکوردِ دیگری داشته باشد، اما ریشه‌ی دامنه به‌اجبار باید رکوردهای SOA و NS داشته باشد. این دو با هم در تضادند. راه‌حل استفاده از رکوردِ غیراستانداردِ ALIAS/ANAME یا گذاشتنِ رکوردِ A با یک آی‌پی ثابت است.

#چرا برای رکوردِ A به آی‌پی ثابت نیاز دارم؟

چون رکوردِ A یک نگاشتِ ماندگار است که تا وقتی خودتان تغییرش ندهید ثابت می‌ماند. اگر آدرسی که رکورد به آن اشاره می‌کند مدام عوض شود (مثلِ آدرس‌های متغیرِ خانگی)، رکوردِ شما پیوسته کهنه می‌شود و کاربران به مقصدِ اشتباه می‌روند. یک آدرسِ ثابت این مشکل را ریشه‌ای حل می‌کند.

#«انتشارِ DNS» واقعاً چقدر طول می‌کشد؟

چیزی به نامِ انتشار وجود ندارد؛ تغییرِ شما روی نیم‌سرورِ مرجع بی‌درنگ اعمال می‌شود. آنچه زمان می‌برد فقط انقضای حافظه‌ی پنهانِ سرورهای بازگردانی است که دقیقاً به‌اندازه‌ی مقدارِ TTLِ رکورد طول می‌کشد. اگر TTL را از قبل به 300 ثانیه کاهش دهید، تغییر ظرفِ چند دقیقه همه‌جا دیده می‌شود.

#SPF، DKIM و DMARC چه تفاوتی با هم دارند؟

هر سه برای اعتبارِ ایمیل‌اند اما نقش‌های مکمل دارند: SPF فهرست می‌کند چه سرورهایی مجازِ فرستادن از طرفِ دامنه‌اند؛ DKIM هر نامه را با امضای رمزنگاری مُهر می‌کند تا دستکاری‌نشدنش اثبات شود؛ و DMARC سیاستِ نهایی را تعیین می‌کند که با نامه‌های مردود چه شود و گزارش‌ها به کجا بروند. برای بهترین نتیجه هر سه را با هم تنظیم کنید.

#چرا سرورهای ایمیل به رکوردِ PTR اهمیت می‌دهند؟

سرورهای گیرنده برای مقابله با هرزنامه بررسی می‌کنند که آیا آدرسِ فرستنده یک نگاشتِ معکوسِ (PTR) درست دارد که با رکوردِ A رو به جلو هم‌خوان باشد یا نه. اگر این چرخه بسته نشود، نامه مشکوک تلقی می‌شود. برای داشتنِ PTR اختصاصی و منطبق، به یک آی‌پی ثابت که واقعاً به شما اختصاص یافته نیاز دارید.

#مقدارِ TTL را چقدر باید بگذارم؟

برای رکوردهای پایدار، مقداری متوسط مثلِ 3600 ثانیه تعادلِ خوبی میانِ سرعت و به‌روزرسانی است. اگر می‌دانید به‌زودی رکوردی را تغییر می‌دهید، از چند ساعت قبل TTLِ آن را به مقداری کم مثلِ 300 برسانید و پس از پایدار شدنِ تغییر، دوباره بالایش ببرید.

#رکوردِ SOA دقیقاً چه کاری می‌کند و چند تا از آن لازم است؟

هر زون دقیقاً یک رکوردِ SOA دارد که در حکمِ شناسنامه‌ی زون است: نیم‌سرورِ اصلی، ایمیلِ مسئول و پنج مقدارِ زمانی (serial، refresh، retry، expire و minimum) را نگه می‌دارد که رفتارِ همگام‌سازیِ سرورهای ثانویه و مدتِ کشِ پاسخ‌های منفی را کنترل می‌کنند. مهم‌ترین نکته‌ی عملی، افزایشِ serial پس از هر تغییر است.

#رکوردِ CAA چه فایده‌ای دارد و آیا اجباری است؟

رکوردِ CAA مشخص می‌کند کدام مراجعِ صدورِ گواهی مجازند برای دامنه‌ی شما گواهیِ TLS صادر کنند و یک سدِ اضافه در برابرِ صدورِ گواهیِ غیرمجاز است. اجباری نیست، اما توصیه می‌شود؛ نبودش خطری فوری ایجاد نمی‌کند ولی داشتنش سطحِ حمله‌ی مربوط به گواهی‌ها را به‌طورِ محسوسی کاهش می‌دهد.