DNS چیست؟

با توجه به درخواست بالای کاربران و سئوالات زیاد شما عزیزان پیرامون موارد مربوط به dns ، تصمیم گرفتیم زمان بذاریم و جامع ترین محتوای ممکن و کاملا کاربردی و تخصصی رو پیرامون موضوعات dns برای استفاده شما آماده کنیم، امیدواریم که به کار شما بیاد و استفاده درست کنید.

DNS چیست؟ راهنمای جامع و کامل سیستم نام دامنه

مقدمه

هر روز میلیون‌ها بار از اینترنت استفاده می‌کنیم: مرورگر را باز می‌کنیم، آدرس یک سایت مثل google.com را تایپ می‌کنیم و در کسری از ثانیه به صفحه موردنظر می رسیم. اما پشت این پرده ساده، یکی از مهم‌ترین و پیچیده ترین فناوری های اینترنت به نام DNS یا Domain Name System در حال کار است. بدون DNS، اینترنت مدرن به شکلی که می شناسیم وجود نداشت.

در این مقاله قصد داریم به صورت کاملاً عمیق و موشکافانه بررسی کنیم که DNS چیست، چگونه کار می کند، انواع رکوردهای DNS کدامند، امنیت DNS چگونه تأمین می شود و چه آینده‌ای در انتظار آن است.

DNS چیست؟ (تعریف ساده و فنی)

تعریف ساده DNS

DNS مخفف Domain Name System (سیستم نام دامنه) است. اگر اینترنت را یک دفترچه تلفن غول پیکر در نظر بگیریم، DNS آن دفترچه تلفن است. وظیفه اصلی DNS ترجمه نام‌های دامنه قابل فهم برای انسان (مثل google.com) به آدرس های IP عددی (مثل 142.250.185.78) است که کامپیوترها با یکدیگر ارتباط برقرار کنند.

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

تعریف فنی DNS

از منظر فنی، DNS یک پایگاه داده توزیع‌شده و سلسله‌مراتبی (Hierarchical & Distributed Database) است که وظیفه تفکیک نام دامنه به آدرس IP و بالعکس را بر عهده دارد. این سیستم از پروتکل UDP (عمدتاً روی پورت 53) و در موارد خاص TCP استفاده می‌کند.

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

سلسله‌مراتبی (Hierarchical): ساختار DNS شبیه به یک درخت است که از بالا به پایین، نام‌ها را به بخش‌های کوچک‌تر تقسیم می‌کند. این ساختار به مدیریت پیچیده و سازماندهی نام‌ها کمک می‌کند.

پروتکل UDP/TCP: اکثر پرس و جوهای DNS با استفاده از پروتکل UDP (User Datagram Protocol) بر روی پورت 53 انجام می‌شوند. UDP سریع‌تر است زیرا نیازی به برقراری ارتباط تأیید شده ندارد. با این حال، برای انتقال حجم بالای داده مانند Zone Transfer، از پروتکل TCP (Transmission Control Protocol) استفاده می‌شود که اتصال قابل اطمینان‌تری را فراهم می‌کند.

چرا DNS اختراع شد؟ (تاریخچه DNS)

دوران قبل از DNS

در سال‌های اولیه اینترنت (دوران ARPANET)، ارتباط بین کامپیوترها از طریق فایلی به نام HOSTS.TXT انجام می‌شد. این فایل توسط SRI International (Stanford Research Institute) مدیریت می‌شد و شامل نگاشت دستی (Manual Mapping) نام کامپیوترها به آدرس‌های IP بود. هر بار که یک کامپیوتر جدید به شبکه اضافه می‌شد یا آدرس IP آن تغییر می‌کرد، این فایل باید به‌روزرسانی می‌شد و سپس این فایل به‌روز شده به تمام کامپیوترهای شبکه توزیع می‌گردید.

با رشد ARPANET، مشکلات متعددی پدیدار شد که استفاده از فایل HOSTS.TXT را غیرممکن ساخت:

مقیاس‌پذیری (Scalability): با افزایش تعداد کامپیوترها و میزبان ها در شبکه، فایل HOSTS.TXT به‌شدت بزرگ و حجیم می‌شد. مدیریت، جستجو و به‌روزرسانی چنین فایل بزرگی بسیار دشوار بود.

ترافیک شبکه (Network Traffic): با هر تغییر کوچک در فایل، کل فایل باید مجدداً منتشر و دریافت می‌شد. این عمل بار سنگینی بر روی ترافیک شبکه وارد می‌کرد، به خصوص در شبکه‌های بزرگ.

تضاد نام (Name Collisions): با افزایش تعداد سازمان‌ها و کاربران، احتمال انتخاب نام‌های مشابه برای کامپیوترها یا سرویس‌ها افزایش می‌یافت. این فایل مرکزی قادر به مدیریت و جلوگیری از این تضادها نبود.

تأخیر در انتشار (Propagation Delay): انتشار تغییرات در فایل HOSTS.TXT به تمام کامپیوترهای شبکه زمان‌بر بود. این بدان معنا بود که تا زمانی که یک کامپیوتر فایل به‌روز شده را دریافت نکرده بود، ممکن بود به منابع شبکه با آدرس‌های IP قدیمی دسترسی پیدا کند یا اصلاً نتواند ارتباط برقرار کند.

محدودیت مدیریت متمرکز: مدیریت متمرکز یک فایل برای شبکه‌ای با گستردگی و رشد سریع اینترنت، عملاً ناکارآمد بود.

تولد DNS (1983)

برای غلبه بر مشکلات روش مبتنی بر فایل HOSTS.TXT، نیاز به یک سیستم جدید و کارآمدتر احساس شد. در سال 1983، پل موکاپتریس (Paul Mockapetris)، که در دانشگاه کالیفرنیای جنوبی فعالیت میکرد، پیشنهاد RFC 882 و RFC 883 را ارائه داد. این دو سند، پایه‌گذار DNS مدرن شدند. طرح او به جای یک فایل مرکزی و ثابت، یک سیستم توزیع‌شده و سلسله مراتبی را پیشنهاد می‌کرد که قادر به مدیریت مقیاس‌پذیری، انعطاف‌پذیری و سرعت مورد نیاز اینترنت در حال رشد بود.

تکامل DNS

از زمان معرفی در دهه 1980، DNS تکامل قابل توجهی داشته است:

1987: RFC 1034 و RFC 1035 منتشر شدند که استانداردهای فعلی و جزئیات فنی DNS را تعریف کردند. این RFCها چارچوب پایدار و جامعی را برای سیستم نام دامنه فراهم کردند.

دهه 1990: با رشد انفجاری اینترنت تجاری و افزایش ثبت دامنه‌های جدید (به ویژه پسوند .com)، DNS نقش حیاتی تری در هدایت ترافیک اینترنت ایفا کرد.

1999: برای مقابله با ضعف‌های امنیتی DNS، پروژه DNSSEC (DNS Security Extensions) معرفی شد. DNSSEC با استفاده از امضای دیجیتال، امکان تأیید صحت داده‌های DNS را فراهم می‌کند و از حملاتی مانند DNS Spoofing جلوگیری می‌کند.

دهه 2010: با افزایش نگرانی‌ها در مورد حریم خصوصی کاربران و شنود ترافیک DNS توسط ISPها، تکنیک‌های جدیدی مانند DNS over HTTPS (DoH) و DNS over TLS (DoT) توسعه یافتند. این پروتکل‌ها درخواست‌های DNS را رمزنگاری کرده و حریم خصوصی کاربران را بهبود می‌بخشند.

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

معماری و ساختار DNS

DNS از دو بخش اصلی تشکیل شده است که با همکاری یکدیگر، کارایی و ساختار این سیستم را تضمین می‌کنند:

فضای نام سلسله‌مراتبی (Hierarchical Namespace)

سرورهای نام (Name Servers)

ساختار سلسله‌مراتبی DNS

ساختار DNS به شکل یک درخت معکوس (Inverted Tree) طراحی شده است. در این ساختار، ریشه درخت در بالاترین سطح قرار دارد و شاخه‌ها به سمت پایین منشعب می‌شوند. این ساختار امکان سازماندهی منطقی و کارآمد نام های دامنه را فراهم میکند.

ریشه (Root)

نقطه شروع درخت DNS است که با یک نقطه (.) نمایش داده می‌شود. این نقطه نشان‌دهنده بالاترین سطح در سلسله‌مراتب DNS است و به صورت ضمنی در انتهای تمام نام های دامنه کامل (Fully Qualified Domain Name – FQDN) قرار دارد، هرچند اغلب دیده نمی‌شود. مدیریت و پاسخ دهی به این سطح بر عهده 13 خوشه سرور ریشه (Root Server) در سراسر جهان است. این 13 خوشه، به معنای 13 سرور فیزیکی نیستند، بلکه نشان دهنده 13 مجموعه منطقی از سرورها هستند که هر کدام شامل صدها سرور فیزیکی توزیع شده در نقاط مختلف جهان می‌باشند. سرورهای ریشه مسئول هدایت درخواست‌ها به سرورهای سطح بالاتر (TLD) مناسب هستند.

دامنه های سطح بالا (TLD – Top-Level Domains)

پس از ریشه، دومین سطح از سلسله‌مراتب DNS، دامنه‌های سطح بالا (TLD) هستند. این دامنه‌ها نشان‌دهنده دسته‌بندی اصلی وب‌سایت‌ها یا مناطق جغرافیایی هستند. انواع TLDها عبارتند از:

gTLD (Generic TLD): دامنه‌های عمومی که برای اهداف مختلف استفاده می‌شوند. مثال‌ها شامل: .com (تجاری)، .org (سازمان‌های غیرانتفاعی)، .net (شبکه)، .info (اطلاعات)، .biz (تجارت).

ccTLD (Country Code TLD): دامنه‌های کد کشور که به یک کشور خاص اختصاص دارند. مثال‌ها شامل: .ir (ایران)، .uk (بریتانیا)، .de (آلمان)، .ca (کانادا).

sTLD (Sponsored TLD): دامنه‌هایی که توسط یک سازمان خاص حمایت و اداره می‌شوند و معمولاً برای اهداف خاصی مانند بخش‌های دولتی یا آموزشی به کار می‌روند. مثال‌ها شامل: .gov (دولتی)، .edu (آموزشی)، .mil (نظامی).

new gTLD: تعداد زیادی دامنه سطح بالای جدید که از سال 2012 به بعد معرفی شده‌اند و طیف گسترده‌تری از موضوعات را پوشش می‌دهند. بیش از 1200 دامنه جدید مانند .blog, .app, .shop, .online.

دامنه سطح دوم (SLD – Second-Level Domain)

این سطح، بخشی از نام دامنه است که کاربران معمولاً برای وب‌سایت یا سرویس خود ثبت می‌کنند. این بخش در سمت چپ TLD قرار می‌گیرد. به عنوان مثال، در دامنه google.com، google دامنه سطح دوم (SLD) است. در example.org، example SLD است. این نام توسط کاربر انتخاب و از طریق یک Registrar (شرکت ثبت دامنه) خریداری می‌شود.

زیردامنه (Subdomain)

زیردامنه ها بخش های اضافی در سمت چپ دامنه اصلی هستند که برای سازماندهی بیشتر وب سایت یا سرویس ها استفاده می شوند. هر دامنه اصلی میتواند زیرشاخه های متعددی داشته باشد. مثال ها شامل: blog.example.com، mail.google.com، support.yourcompany.net. این زیرشاخه ها به شما اجازه می دهند تا بخش های مختلف وب سایت خود را (مانند بلاگ، فروشگاه، پشتیبانی) از هم جدا کنید و برای هر کدام تنظیمات DNS متفاوتی داشته باشید.

سرورهای DNS (DNS Servers)

سرورهای DNS اجزای سخت افزاری و نرم افزاری هستند که اطلاعات پایگاه داده DNS را نگهداری و به درخواست‌ها پاسخ می‌دهند. انواع اصلی سرورهای DNS عبارتند از:

1. سرور ریشه (Root Name Server)

همانطور که گفته شد، 13 خوشه سرور ریشه (با نام‌های A تا M) وظیفه مدیریت بالاترین سطح سلسله‌مراتب DNS را بر عهده دارند. وظیفه اصلی آنها این است که در پاسخ به یک پرس‌وجو، آدرس سرور TLD مربوط به دامنه درخواستی را ارائه دهند. به عنوان مثال، اگر کسی آدرس www.example.com را پرس‌وجو کند، سرور ریشه نمی‌داند که آدرس IP آن چیست، اما می‌داند که دامنه .com توسط کدام سرور TLD مدیریت می‌شود و آن سرور را معرفی می‌کند. این سرورها به صورت Anycast مستقر شده‌اند، به این معنی که یک آدرس IP واحد توسط چندین سرور در مکان‌های مختلف مورد استفاده قرار می‌گیرد و درخواست‌ها به نزدیک‌ترین سرور هدایت می‌شوند.

2. سرور TLD (Top-Level Domain Name Server)

این سرورها مسئول مدیریت دامنه‌های سطح بالا (TLD) هستند؛ به عنوان مثال، سروری که مسئول مدیریت تمام دامنه‌های .com، سرور دیگری برای .org و غیره. وقتی یک Resolver (در ادامه توضیح داده می‌شود) از سرور ریشه آدرس سرور TLD را دریافت کرد، به آن سرور مراجعه می‌کند. سرور TLD هم نام دامنه سطح دوم (SLD) را نمی‌شناسد، اما نام سرور معتبر (Authoritative Name Server) که مسئول آن دامنه است را می‌داند و آن را معرفی می‌کند.

3. سرور معتبر (Authoritative Name Server)

این سرور، آخرین مرجع پاسخ‌دهی برای یک دامنه خاص است. این سرور، رکوردهای DNS نهایی و صحیح برای دامنه مورد نظر را نگهداری می‌کند. وقتی Resolver به سرور معتبر مراجعه می‌کند، سرور معتبر پاسخ قطعی (Authoritative Answer) را به پرس‌وجوی Resolver ارائه می‌دهد (مثلاً آدرس IP مربوط به www.example.com). معمولاً این سرورها توسط ارائه‌دهنده هاستینگ (Hosting Provider) یا شرکت ثبت دامنه (Domain Registrar) که دامنه را از آن خریداری کرده‌اید، مدیریت و پیکربندی می‌شوند. هر دامنه باید حداقل دو سرور معتبر داشته باشد تا دسترس‌پذیری آن افزایش یابد.

4. حل‌کننده (Resolver)

حل‌کننده، سروری است که درخواست DNS را از طرف کاربر (کلاینت) آغاز می‌کند و فرآیند جستجو را تا دریافت پاسخ نهایی انجام می‌دهد. دو نوع اصلی Resolver وجود دارد:

Stub Resolver: این نوع Resolver در سیستم‌عامل کاربر (مانند ویندوز، macOS، لینوکس) یا در مرورگر قرار دارد. Stub Resolver وظیفه ساده‌ای دارد: تنها به یک سرور DNS (که معمولاً توسط ISP یا کاربر پیکربندی شده است) پرس‌وجو می‌کند و منتظر پاسخ می‌ماند. خودش جستجوی کامل را انجام نمی‌دهد.

Recursive Resolver (یا DNS Recursor): این سرور، جستجوی کامل و تکراری را انجام می‌دهد. پس از دریافت درخواست از Stub Resolver، خود Recursive Resolver با سرورهای ریشه، TLD و Authoritative Server ارتباط برقرار کرده و تمام مراحل لازم را طی می‌کند تا پاسخ نهایی را به دست آورد. سپس این پاسخ را به Stub Resolver کاربر بازمی‌گرداند. معروف‌ترین Recursive Resolverهای عمومی عبارتند از:

Google Public DNS: 8.8.8.8 و 8.8.4.4

Cloudflare DNS: 1.1.1.1 و 1.0.0.1

OpenDNS: 208.67.222.222 و 208.67.220.220

این معماری توزیع شده و سلسله مراتبی، به DNS اجازه می دهد تا به صورت مؤثر و مقیاس پذیر عمل کند و دسترسی به منابع اینترنتی را برای میلیاردها کاربر در سراسر جهان ممکن سازد.

ذکر این نکته را اینجا مهم میدانیم که اگر سایت شما باز نمیگردد یا به دلایلی فیلتر شده و نمیدانید چرا سایت بسته و فیلتر شده اینجا را بخوانید و بعد کارهای dns را پیگیری کنید.

فرآیند جستجوی DNS (DNS Lookup Step-by-Step)

حال بیایید قدم به قدم و با جزئیات کامل، فرآیند پیچیده‌ای را که در پسِ یک جستجوی ساده DNS رخ می‌دهد، بررسی کنیم. فرض کنید شما آدرس www.example.com را در مرورگر خود تایپ می کنید و می‌خواهید به وب سایت مربوطه دسترسی پیدا کنید.

مرحله 1: بررسی کش مرورگر و سیستم‌عامل

اولین جایی که مرورگر شما برای یافتن آدرس IP مربوط به www.example.com جستجو می‌کند، کش (Cache) خود مرورگر است. مرورگرها نتایج جستجوهای DNS اخیر را برای مدتی (بسته به تنظیمات TTL) ذخیره می‌کنند تا در صورت نیاز مجدد به همان آدرس، نیازی به پرس‌وجوی مجدد در شبکه نباشد و سرعت بارگذاری صفحات افزایش یابد.

اگر رکورد مورد نظر در کش مرورگر پیدا نشد (یا منقضی شده بود)، مرورگر به سراغ کش سیستم‌عامل میرود. سیستم‌عامل نیز دارای یک DNS Cache است که نتایج جستجوهای DNS را برای تمام برنامه‌های در حال اجرا نگهداری می‌کند.

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

مرحله 2: پرس‌وجو از Resolver

درخواست DNS از طریق Stub Resolver (که بخشی از سیستم‌عامل یا مرورگر است) به Recursive Resolver ارسال می‌شود. این Recursive Resolver معمولاً توسط ارائه‌دهنده خدمات اینترنت (ISP) شما ارائه می‌شود، یا ممکن است شما آن را به صورت دستی به یکی از DNSهای عمومی (مانند Google DNS یا Cloudflare DNS) تغییر داده باشید. وظیفه Recursive Resolver این است که کل فرآیند جستجو را برای شما انجام دهد.

مرحله 3: پرس و جو از سرور ریشه (Root Server)

Recursive Resolver (که در ادامه به اختصار Resolver نامیده می‌شود) در ابتدا از یکی از 13 سرور ریشه DNS می‌پرسد: “آدرس IP مربوط به www.example.com کجاست؟”

سرور ریشه، اطلاعات مستقیم در مورد آدرس IP www.example.com ندارد، زیرا این سطح بالاترین سطح سلسله‌مراتب است. اما سرور ریشه می‌داند که مسئول مدیریت دامنه‌های سطح بالای (TLD) مانند .com کدام سرور TLD است. بنابراین، سرور ریشه به Resolver پاسخ می‌دهد: “من آدرس IP مورد نظر تو را ندارم، اما برای یافتن آن، باید از سرور TLD مربوط به دامنه .com بپرسی.” در این مرحله، Resolver آدرس IP سرور TLD .com را دریافت می‌کند.

مرحله 4: پرس‌وجو از سرور TLD (Top-Level Domain Server)

حالا Resolver به سرور TLD .com مراجعه می‌کند و همان سوال را می پرسد: “آدرس IP مربوط به www.example.com کجاست؟”

سرور TLD .com نیز مانند سرور ریشه، آدرس IP دقیق www.example.com را نمی‌داند. اما می‌داند که دامنه example.com توسط کدام سرور DNS معتبر (Authoritative Name Server) مدیریت می‌شود. بنابراین، سرور TLD پاسخ می‌دهد: “من آدرس IP آن را ندارم، اما دامنه example.com توسط سرور معتبری به نام ns1.example.com (یا مشابه آن) مدیریت می‌شود. برای دریافت پاسخ نهایی، به آن سرور مراجعه کن.” سرور TLD آدرس IP سرور معتبر مربوط به example.com را به Resolver می‌دهد.

مرحله 5: پرس‌وجو از سرور معتبر (Authoritative Name Server)

در نهایت، Resolver به سرور معتبر (ns1.example.com) که آدرس IP آن را از سرور TLD دریافت کرده است، مراجعه می‌کند و می‌پرسد: “آدرس IP مربوط به www.example.com چیست؟”

این بار، سرور معتبر، صاحب اطلاعات نهایی است. این سرور، رکورد DNS مربوط به www.example.com را در پایگاه داده خود جستجو می‌کند و پاسخ قطعی را ارائه می‌دهد: “آدرس IP مربوط به www.example.com برابر با 93.184.216.34 است.”

مرحله 6: ذخیره در کش و بازگشت پاسخ

Resolver اکنون پاسخ نهایی را از سرور معتبر دریافت کرده است. این پاسخ شامل آدرس IP صحیح است. قبل از اینکه Resolver پاسخ را به سیستم کاربر برگرداند، آن را در کش خود ذخیره می‌کند. مدت زمانی که این رکورد در کش نگهداری می‌شود، توسط مقدار TTL (Time To Live) تعیین شده برای آن رکورد DNS مشخص می‌شود.

سپس، Resolver آدرس IP 93.184.216.34 را به سیستم کاربر (که از طریق Stub Resolver درخواست را ارسال کرده بود) برمی‌گرداند.

پس از دریافت آدرس IP، کامپیوتر کاربر مستقیماً به آدرس IP 93.184.216.34 متصل می‌شود و فرآیند بارگذاری صفحه وب آغاز می‌گردد.

این چرخه کامل، از لحظه تایپ آدرس تا دریافت آدرس IP، معمولاً در چند دهم ثانیه (یا حتی کمتر) اتفاق می افتد و نشان دهنده هماهنگی و کارایی بالای سیستم DNS است.

انواع پرس و  جو در DNS

برای درک بهتر نحوه تعامل بین کلاینت‌ها و سرورهای DNS، سه نوع اصلی پرس‌وجو (Query) وجود دارد:

Recursive Query (پرس‌وجوی بازگشتی):
این رایج‌ترین نوع پرس و جو است که توسط کلاینت‌ها (مانند مرورگر شما) به Recursive Resolver ارسال می‌شود. در این حالت، کلاینت از Resolver می خواهد که یا پاسخ نهایی (آدرس IP) را برگرداند، یا اگر قادر به یافتن پاسخ نبود، یک پیغام خطا (مانند NXDOMAIN) ارسال کند. کلاینت منتظر پاسخ نهایی می‌ماند و نیازی به انجام مراحل بعدی جستجو ندارد.

Iterative Query (پرس‌وجوی تکراری):
این نوع پرس‌وجو معمولاً بین سرورهای DNS انجام می‌شود. وقتی یک Resolver (که به عنوان کلاینت عمل می‌کند) پرس‌وجویی تکراری را از سرور دیگری (مثلاً سرور ریشه یا TLD) انجام می‌دهد، سرور پاسخ‌دهنده به جای اینکه خودش جستجوی کامل را انجام دهد، بهترین مرجع بعدی را به Resolver معرفی می‌کند. Resolver سپس به سرور معرفی شده مراجعه می‌کند و این فرآیند تکرار می‌شود تا زمانی که به سرور معتبر برسد و پاسخ نهایی را دریافت کند.

Non-Recursive Query (پرس‌وجوی غیربازگشتی):
در این نوع پرس‌وجو، سرور DNS فقط در صورتی پاسخ می‌دهد که اطلاعات مورد نظر را مستقیماً در کش خود داشته باشد. اگر اطلاعات در کش نباشد، سرور بدون انجام هیچ جستجوی دیگری، پیغام خطا برمی‌گرداند. این نوع پرس‌وجو معمولاً زمانی رخ می‌دهد که یک Resolver مستقیماً از یک Authoritative Server درخواستی را می‌پرسد که در کش آن سرور موجود است.

انواع رکوردهای DNS (DNS Record Types)

DNS از انواع مختلفی از رکوردها برای ذخیره اطلاعات گوناگون مربوط به دامنه ها استفاده می‌کند. هر رکورد دارای یک نوع (Type) است که مشخص می‌کند چه نوع اطلاعاتی در آن ذخیره شده است. در اینجا به معرفی پرکاربردترین انواع رکوردها می‌پردازیم:

رکورد A (Address Record)

این پرکاربردترین نوع رکورد DNS است. وظیفه اصلی رکورد A، نگاشت (Mapping) یک نام دامنه یا زیردامنه به یک آدرس IPv4 است. وقتی شما نام یک وب سایت را تایپ می کنید، Resolver در نهایت به دنبال یک رکورد A میگردد تا آدرس IP سرور آن وب سایت را پیدا کند.

مثال:
example.com. IN A 93.184.216.34

example.com. : نام دامنه یا زیردامنه.

IN : مخفف “Internet”، نشان‌دهنده استفاده در پروتکل اینترنت.

A : نوع رکورد (Address Record).

93.184.216.34 : آدرس IPv4 مربوطه.

رکورد AAAA (IPv6 Address Record)

این رکورد مشابه رکورد A است، اما به جای نگاشت نام دامنه به یک آدرس IPv4، آن را به یک آدرس IPv6 نگاشت می‌کند. با گسترش استفاده از IPv6، رکوردهای AAAA نیز اهمیت بیشتری پیدا کرده‌اند.

مثال:
example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946

AAAA : نوع رکورد (Quad-A Record).

2606:2800:220:1:248:1893:25c8:1946 : آدرس IPv6 مربوطه.

رکورد CNAME (Canonical Name Record)

این رکورد برای ایجاد یک نام مستعار (Alias) برای یک دامنه یا زیردامنه استفاده می شود. به عبارت دیگر، CNAME به شما اجازه می‌دهد تا چندین نام را به یک نام دامنه اصلی (Canonical Name) ارجاع دهید. این رکورد بسیار پرکاربرد است، به خصوص برای ایجاد نام www برای دامنه‌ها.

مثال:
www.example.com. IN CNAME example.com.

این رکورد به مرورگرها و سرورها می گوید که هر درخواستی برای www.example.com باید در واقع به example.com ارجاع داده شود. این کار مدیریت را آسان‌تر می‌کند؛ مثلاً اگر آدرس IP اصلی دامنه تغییر کند، فقط کافی است رکورد A دامنه اصلی را به‌روز کنید و تمام زیردامنه‌هایی که به آن CNAME شده‌اند، به طور خودکار به روز خواهند شد.

رکورد MX (Mail Exchange Record)

این رکورد مشخص می‌کند که ایمیل های مربوط به یک دامنه باید به کدام سرور پست الکترونیکی (Mail Server) ارسال شوند. رکوردهای MX دارای یک پارامتر “اولویت” (Priority) هستند که مشخص می‌کند کدام سرور اولویت بالاتری برای دریافت ایمیل دارد. عدد اولویت پایین‌تر نشان دهنده اولویت بالاتر است.

مثال:

example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 backup-mail.example.com.

10 و 20 : اولویت سرورهای ایمیل. سرور mail.example.com با اولویت 10، اولویت بالاتری نسبت به backup-mail.example.com با اولویت 20 دارد.

اگر سرور با اولویت بالاتر در دسترس نباشد، سرور با اولویت بعدی مورد استفاده قرار می گیرد.

رکورد NS (Name Server Record)

این رکورد مشخص می‌کند که کدام سرورهای DNS به عنوان سرورهای معتبر (Authoritative Name Server) برای یک دامنه یا زیردامنه خاص عمل می‌کنند. سرورهای ریشه و TLD از رکوردهای NS برای هدایت پرس‌وجوها به سرورهای معتبر دامنه‌ها استفاده می‌کنند.

مثال:
example.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

این رکوردها به سیستم DNS می گویند که مسئولیت مدیریت رکوردهای example.com بر عهده سرورهای ns1.example.com و ns2.example.com است.

اگر برای ست کردن سرچ کنسول خود از dns میخواهیداستفاده کنید اینجا را بخوانید: آموزش ثبت سایت در گوگل سرچ کنسول

رکورد TXT (Text Record)

این رکورد به شما اجازه می‌دهد تا اطلاعات متنی دلخواه را در DNS دامنه خود ذخیره کنید. رکوردهای TXT کاربردهای متنوعی دارند، از جمله:

تأیید مالکیت دامنه: بسیاری از سرویس‌ها (مانند Google Search Console) با قرار دادن یک رکورد TXT خاص، مالکیت شما را بر روی دامنه تأیید می‌کنند.

SPF (Sender Policy Framework): برای جلوگیری از جعل ایمیل و اسپم، SPF با مشخص کردن سرورهایی که مجاز به ارسال ایمیل از طرف دامنه شما هستند، امنیت ایمیل را افزایش می‌دهد.

DKIM (DomainKeys Identified Mail): با امضای دیجیتال ایمیل‌ها، هویت فرستنده را تأیید می‌کند.

DMARC (Domain-based Message Authentication, Reporting & Conformance): سیاست‌های SPF و DKIM را ترکیب کرده و گزارش‌هایی در مورد وضعیت تحویل ایمیل‌ها ارائه می‌دهد.

مثال:
example.com. IN TXT “v=spf1 include:_spf.google.com ~all” این رکورد، بخشی از پیکربندی SPF برای دامنه example.com است.

رکورد SOA (Start of Authority)

این رکورد برای هر ناحیه (Zone) DNS اجباری است. SOA اطلاعات مدیریتی کلیدی در مورد آن ناحیه DNS را فراهم می‌کند. این اطلاعات شامل:

Primary Name Server: نام سرور DNS اصلی که این ناحیه را مدیریت می‌کند.

Email of the administrator: آدرس ایمیل مسئول مدیریت ناحیه DNS (معمولاً نقطه به جای @ استفاده می‌شود، مثلاً admin.example.com. به معنای admin@example.com).

Serial Number: یک شماره سریال منحصر به فرد که با هر بار تغییر در ناحیه DNS افزایش می‌یابد. سرورهای ثانویه از این شماره برای تشخیص نیاز به به‌روزرسانی (Zone Transfer) استفاده می‌کنند.

Refresh Interval: مدت زمان انتظار سرور ثانویه قبل از بررسی مجدد سرور اصلی برای تغییرات.

Retry Interval: مدت زمان انتظار سرور ثانویه قبل از تلاش مجدد برای دریافت ناحیه، در صورتی که در تلاش قبلی ناموفق بوده باشد.

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

Minimum TTL: حداقل TTL برای رکوردهای غیرمعتبر (Negative Caching).

مثال:

example.com. IN SOA ns1.example.com. admin.example.com. (
2026032901 ; Serial
3600 ; Refresh (1 hour)
900 ; Retry (15 minutes)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)

رکورد SRV (Service Record)

این رکورد برای مشخص کردن موقعیت (نام میزبان و شماره پورت) سرویس‌های خاصی که ممکن است در یک دامنه میزبانی شوند، استفاده می‌شود. این سرویس‌ها می‌توانند شامل SIP (برای VoIP)، LDAP (برای دایرکتوری)، XMPP (برای چت) و غیره باشند.

مثال:
_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com. این رکورد نشان می‌دهد که سرویس SIP (با پروتکل TCP) در دامنه example.com روی سرور sipserver.example.com در پورت 5060 با اولویت 10 و وزن 60 اجرا می‌شود.

رکورد PTR (Pointer Record)

این رکورد معکوس رکورد A است. به جای نگاشت نام به IP، رکورد PTR یک آدرس IP را به نام دامنه نگاشت می‌کند. این نوع رکورد برای Reverse DNS Lookup استفاده می‌شود که برای تأیید صحت آدرس IP (به عنوان مثال، هنگام ارسال ایمیل) یا برای گزارش‌دهی و ثبت لاگ‌ها مفید است.

مثال:
34.216.184.93.in-addr.arpa. IN PTR www.example.com.

34.216.184.93.in-addr.arpa. : فرمت خاص نام دامنه برای Reverse DNS lookup.

PTR : نوع رکورد.

www.example.com. : نام دامنه‌ای که به این IP نگاشت شده است.

رکورد CAA (Certification Authority Authorization)

این رکورد به صاحبان دامنه اجازه می‌دهد تا مشخص کنند کدام گواهینامه‌های صادرکننده گواهی SSL/TLS (Certificate Authority – CA) مجاز به صدور گواهی برای دامنه آن‌ها هستند. این یک لایه امنیتی اضافی برای جلوگیری از صدور گواهی‌های جعلی است.

مثال:
example.com. IN CAA 0 issue “letsencrypt.org” این رکورد بیان می‌کند که تنها “Let’s Encrypt” مجاز به صدور گواهی برای دامنه example.com است.

درک این انواع رکوردها برای پیکربندی صحیح DNS و اطمینان از عملکرد صحیح سرویس‌های اینترنتی (وب‌سایت، ایمیل، و غیره) ضروری است.

* گاهی نیاز هست که بدانید سرور یک سایت در داخل ایران قراردارد یا خارج از ایران، برای اینکه بدانید از کجا بفهمیم سرور یک سایت داخلی است یا خارجی اینجا را مطالعه کنید.

DNS Caching (کش کردن DNS)

کش کردن یکی از حیاتی‌ترین مکانیزم‌ها در سیستم DNS است که نقشی کلیدی در افزایش سرعت، کاهش تأخیر (Latency) و کاهش بار بر روی سرورهای DNS ایفا می‌کند. کش کردن به معنای ذخیره موقت نتایج جستجوهای DNS در مکان‌های مختلف شبکه است.

مکانیزم TTL (Time To Live)

هر رکورد DNS دارای یک پارامتر به نام TTL (Time To Live) است. این مقدار، که بر حسب ثانیه اندازه‌گیری می‌شود، مشخص می‌کند که آن رکورد DNS تا چه مدت در کش معتبر باقی بماند. پس از اتمام زمان TTL، رکورد از کش حذف شده و در صورت نیاز مجدد، یک پرس‌وجوی جدید در شبکه آغاز خواهد شد.

مقادیر رایج TTL:

300 ثانیه (5 دقیقه): برای رکوردهایی که ممکن است نیاز به تغییرات مکرر داشته باشند (مانند رکوردهای MX یا A در محیط‌های پرنوسان).

3600 ثانیه (1 ساعت): یک مقدار معمول و متعادل که برای اکثر رکوردهای وب‌سایت استفاده می‌شود.

86400 ثانیه (1 روز): برای رکوردهایی که بسیار پایدار هستند و به ندرت تغییر می‌کنند (مانند NS Records).

604800 ثانیه (7 روز): حداکثر مقدار TTL که برای رکوردهای بسیار ثابت استفاده می‌شود.

انتخاب مقدار مناسب TTL یک تعادل بین سرعت دسترسی و زمان لازم برای انتشار تغییرات است. TTL پایین‌تر باعث می‌شود تغییرات سریع‌تر در کل اینترنت منتشر شوند، اما بار بیشتری بر روی سرورهای DNS وارد می‌کند. TTL بالاتر باعث کاهش بار سرورها و افزایش سرعت برای کاربران می‌شود، اما ممکن است انتشار تغییرات زمان‌بر باشد.

سطوح کش DNS

کش DNS در سطوح مختلفی اتفاق می‌افتد:

کش مرورگر (Browser Cache): همانطور که در بخش فرآیند جستجوی DNS ذکر شد، مرورگرها نتایج DNS را برای مدت کوتاهی کش می‌کنند. این کش معمولاً برای هر برنامه مرورگر به صورت جداگانه عمل می‌کند.

کش سیستم‌عامل (Operating System Cache): سیستم‌عامل (مانند ویندوز، macOS، لینوکس) نیز یک DNS Cache برای تمام برنامه‌های در حال اجرا نگهداری می‌کند. این کش برای تمامی نرم‌افزارها مشترک است.

کش Resolver (Recursive Resolver Cache): Recursive Resolverها (مانند 8.8.8.8) حجم عظیمی از اطلاعات DNS را کش می‌کنند. این کش‌ها معمولاً بیشترین مدت زمان TTL را دارند و بخش عمده‌ای از نیازهای جستجوی DNS را برآورده می‌کنند، که این امر باعث کاهش چشمگیر بار بر روی سرورهای ریشه و TLD می‌شود.

کش روتر/مودم (Router/Modem Cache): برخی از دستگاه‌های شبکه خانگی یا اداری، مانند روترها و مودم‌ها، نیز ممکن است قابلیت کش کردن DNS را داشته باشند تا دسترسی سریع‌تری را برای دستگاه‌های متصل به خود فراهم کنند.

Negative Caching

مکانیزم Negative Caching به زمانی اشاره دارد که یک رکورد DNS جستجو شده و مشخص می‌شود که آن دامنه یا رکورد وجود ندارد (مثلاً خطای NXDOMAIN برگردانده می‌شود). در این حالت، سرور DNS (معمولاً Recursive Resolver) این پاسخ منفی را نیز برای مدتی در کش خود ذخیره می‌کند (با یک TTL تعریف شده برای پاسخ‌های منفی، که معمولاً کوتاه است، مثلاً 5 دقیقه). این کار از پرس‌وجوهای مکرر برای دامنه‌هایی که وجود ندارند جلوگیری کرده و بار سرورها را کاهش می‌دهد.

با استفاده هوشمندانه از کشینگ و تنظیم صحیح TTL، سیستم DNS می‌تواند به سرعت و کارایی بالایی دست یابد و تجربه کاربری مطلوبی را فراهم کند.

DNS Propagation (انتشار DNS)

وقتی شما یک رکورد DNS را تغییر می‌دهید (مثلاً آدرس IP یک وب‌سایت را عوض می‌کنید، یا رکورد MX را به‌روز می‌کنید)، این تغییر بلافاصله در سراسر اینترنت قابل مشاهده نخواهد بود. این تأخیر در انتشار تغییرات در سراسر سیستم DNS را DNS Propagation یا انتشار DNS می‌نامند.

این پدیده به دلیل مکانیزم کشینگ DNS و توزیع‌شدگی سیستم DNS رخ می‌دهد. سرورهای مختلف در سراسر جهان، اطلاعات DNS را در کش خود نگه می‌دارند و هر کدام بر اساس TTL تعیین شده، اطلاعات را به‌روز می‌کنند.

عوامل مؤثر بر زمان انتشار DNS:

مقدار TTL قبل از تغییر: این مهم‌ترین عامل است. اگر TTL رکوردی که قصد تغییر آن را دارید، بالا باشد (مثلاً 24 ساعت)، آن رکورد برای مدت طولانی در کش Resolverها و سیستم‌ها باقی خواهد ماند. بنابراین، قبل از انجام تغییرات مهم، توصیه می‌شود TTL را به مقدار پایین‌تری (مثلاً 5 دقیقه) کاهش دهید. پس از اینکه تغییرات در سراسر شبکه منتشر شد، می‌توانید TTL را دوباره به مقدار اولیه افزایش دهید.

کش ISPها (Internet Service Providers): ISPها Resolverهای بزرگی را مدیریت می‌کنند که اطلاعات DNS را کش می‌کنند. هرچه ISPها سریع‌تر کش خود را به‌روز کنند، انتشار سریع‌تر خواهد بود.

آپدیت Zone File روی سرورهای معتبر: ابتدا باید تغییرات در فایل ناحیه (Zone File) روی سرور معتبر (Authoritative Name Server) اعمال شود.

کش مرورگر کاربران: هرچند این مورد تأثیر کمتری دارد، اما کش مرورگر کاربران نیز می‌تواند باعث شود که تا زمان پاک شدن یا انقضای کش، تغییرات مشاهده نشوند.

نکته مهم: اگر TTL را قبل از ایجاد تغییر به مقدار پایین (مثلاً 300 ثانیه) کاهش دهید، انتشار تغییرات بسیار سریع‌تر اتفاق می‌افتد. این تکنیک به “Low TTL Trick” معروف است و برای مواقعی که نیاز به اعمال سریع تغییرات DNS دارید، بسیار مفید است.

به طور کلی، انتشار DNS می‌تواند از چند دقیقه تا 48 ساعت (در موارد نادر و با TTLهای بسیار بالا) طول بکشد. ابزارهای آنلاین متعددی وجود دارند که وضعیت انتشار DNS را در نقاط مختلف جهان نشان می‌دهند.

امنیت DNS

DNS در ابتدا با هدف سادگی و سرعت طراحی شد و ملاحظات امنیتی کمی در آن لحاظ گردید. این فقدان امنیتی ذاتی، DNS را به هدف آسانی برای حملات سایبری تبدیل کرده است. در این بخش به بررسی برخی از حملات رایج DNS و راهکارهای مقابله با آن‌ها می‌پردازیم.

حملات رایج DNS

DNS Spoofing / Cache Poisoning (جعل DNS / مسموم کردن کش):
در این حمله، مهاجم پاسخ‌های DNS جعلی را به Resolverها یا کش‌های DNS ارسال می‌کند. وقتی یک کاربر درخواستی را ارسال می‌کند، Resolver به جای دریافت آدرس IP واقعی، آدرس IP جعلی که توسط مهاجم ارائه شده را دریافت می‌کند. این کار باعث می‌شود که کاربر به جای وب‌سایت اصلی، به یک وب‌سایت مخرب (مانند صفحه ورود جعلی یا سایتی برای توزیع بدافزار) هدایت شود. مهاجم از این طریق می‌تواند اطلاعات حساس کاربران را سرقت کند.

DNS Tunneling (تونل‌زنی DNS):
این تکنیک از پروتکل DNS برای انتقال داده‌های غیرمجاز و معمولاً مخرب استفاده می‌کند. داده‌ها به قطعات کوچک تقسیم شده و در قسمت‌های مختلف درخواست‌ها یا پاسخ‌های DNS (مانند نام زیردامنه یا رکوردهای TXT) جاسازی می‌شوند. از آنجایی که ترافیک DNS معمولاً توسط فایروال‌ها مجاز است، DNS Tunneling راهی برای دور زدن سیاست‌های امنیتی شبکه و انتقال داده‌ها به خارج از محیط محافظت شده (Exfiltration) یا ایجاد کانال ارتباطی مخفی (Command and Control) است.

DNS Amplification DDoS Attack (حمله DDoS تشدید شده با DNS):
این یکی از رایج‌ترین و مخرب‌ترین حملات DDoS (Distributed Denial of Service) است که از DNS استفاده می‌کند. مهاجم با ارسال درخواست‌های DNS کوچک (معمولاً با استفاده از رکوردهای ANY) به سرورهای DNS باز (Open Resolvers) و با جعل آدرس IP مبدأ (Source IP Address) به آدرس IP قربانی (Victim)، باعث می‌شود که سرورهای DNS با حجم عظیمی از داده به سمت قربانی پاسخ دهند. از آنجایی که پاسخ‌های DNS اغلب بزرگتر از درخواست‌ها هستند (Amplification)، مهاجم می‌تواند با ارسال تعداد کمی درخواست، حجم بسیار زیادی از ترافیک را به سمت قربانی هدایت کرده و آن را از دسترس خارج کند.

DNS Hijacking (ربودن DNS):
در این حمله، مهاجم کنترل DNS یک دامنه را به دست می‌آورد. این کار می‌تواند از طریق روش‌های مختلفی مانند هک کردن حساب ثبت‌کننده دامنه (Domain Registrar)، فریب دادن کارمند مسئول، یا حمله به سرورهای DNS انجام شود. پس از ربودن کنترل، مهاجم می‌تواند رکوردهای DNS را تغییر داده و کاربران را به سمت وب‌سایت‌های مخرب هدایت کند.

Random Subdomain Attack:
در این حمله، مهاجم حجم بسیار زیادی از درخواست‌های DNS را برای زیردامنه‌های تصادفی یک دامنه خاص ارسال می‌کند (مثلاً random12345.example.com, abcdefg.example.com و غیره). هدف این حمله، پر کردن کش Resolverها و سرورهای DNS با نتایج منفی (NXDOMAIN) و از کار انداختن یا کند کردن بیش از حد سرور DNS هدف است.

راهکارهای امنیتی

برای مقابله با این تهدیدات، چندین راهکار امنیتی برای DNS توسعه یافته است:

DNSSEC (DNS Security Extensions)

DNSSEC یک مجموعه از افزونه‌هاست که امنیت DNS را با استفاده از امضای دیجیتال تضمین می‌کند. این پروتکل تضمین می‌کند که پاسخ‌های DNS که دریافت می‌کنید، از منبع معتبر بوده و در طول مسیر دستکاری نشده‌اند.

RRSIG (Resource Record Signature): هر رکورد DNS با یک امضای دیجیتال که توسط کلید خصوصی سرور معتبر ایجاد شده، امضا می‌شود.

DNSKEY (DNS Public Key): شامل کلید عمومی سرور DNS است که برای تأیید امضای RRSIG استفاده می‌شود.

DS (Delegation Signer): این رکورد، ارتباط اعتماد بین سطوح مختلف سلسله‌مراتب DNS را برقرار می‌کند. DS Record در ناحیه والد (Parent Zone) قرار می‌گیرد و کلید عمومی سرور معتبر ناحیه فرزند را امضا می‌کند، و بدین ترتیب یک زنجیره اعتماد از ریشه تا دامنه مورد نظر ایجاد می‌شود.

NSEC/NSEC3 (Next Secure Record): این رکوردها برای اثبات عدم وجود یک رکورد خاص در یک ناحیه DNS استفاده می‌شوند، که این امر مانع حملاتی می‌شود که سعی در جعل وجود یک رکورد دارند.

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

DNS over HTTPS (DoH)

DoH یک پروتکل امنیتی است که درخواست‌های DNS را از طریق پروتکل HTTPS (با استفاده از پورت 443) رمزنگاری و ارسال می‌کند. این امر مزایای متعددی دارد:

رمزنگاری کامل: هم محتوای درخواست DNS و هم پاسخ آن رمزنگاری می‌شوند.

حفظ حریم خصوصی: ISP یا هر ناظر دیگری در شبکه نمی‌تواند محتوای درخواست‌های DNS شما را مشاهده کند.

دور زدن سانسور/فیلترینگ: در برخی کشورها، DoH می‌تواند برای دور زدن فیلترینگ DNS مورد استفاده قرار گیرد.

عدم تداخل با پروکسی‌ها: برخلاف DoT، DoH از پورت استاندارد HTTPS استفاده می‌کند و کمتر احتمال دارد توسط فایروال‌ها مسدود شود.

استاندارد DoH در RFC 8484 تعریف شده است. ارائه‌دهندگان مطرح DoH شامل Cloudflare (1.1.1.1)، Google (8.8.8.8) و Quad9 (9.9.9.9) هستند.

DNS over TLS (DoT)

DoT نیز مانند DoH، درخواست‌های DNS را رمزنگاری می‌کند، اما از پروتکل TLS (Transport Layer Security) بر روی پورت اختصاصی 853 استفاده می‌کند.

تفاوت اصلی DoT و DoH:

DoT: از پورت اختصاصی 853 استفاده می‌کند. این پورت ممکن است توسط برخی شبکه‌ها مسدود شود.

DoH: از پورت استاندارد HTTPS (443) استفاده می‌کند که کمتر احتمال دارد مسدود شود.

هر دو پروتکل DoH و DoT به افزایش حریم خصوصی و امنیت کاربران در برابر شنود و دستکاری DNS کمک می‌کنند.

DNS over QUIC (DoQ)

DoQ جدیدترین روش امن‌سازی DNS است که از پروتکل QUIC (که بر پایه UDP ساخته شده و در HTTP/3 استفاده می‌شود) بهره می‌برد. QUIC قابلیت‌های بهتری در زمینه سرعت، امنیت و تحمل خطا نسبت به TCP و TLS سنتی ارائه می‌دهد. DoQ با ترکیب امنیت DoH/DoT با مزایای QUIC، پتانسیل کاهش تأخیر بیشتر و بهبود عملکرد را دارد.

با استفاده از این راهکارها، می‌توان امنیت سیستم DNS را به طور قابل توجهی افزایش داد و از شبکه‌ها و کاربران در برابر تهدیدات متنوع محافظت کرد.

DNS Zone File و مدیریت ناحیه

Zone File چیست؟

یک Zone File (فایل ناحیه) یک فایل متنی است که تمام اطلاعات مربوط به یک ناحیه DNS (Zone) را در خود نگه می‌دارد. ناحیه DNS بخشی از فضای نام DNS است که توسط یک سازمان یا فرد مدیریت می‌شود؛ به عنوان مثال، example.com یک ناحیه DNS است. Zone File شامل تمام رکوردهای DNS (مانند A, AAAA, MX, NS, TXT, SOA و…) برای آن دامنه و زیردامنه‌هایش است.

ساختار Zone File استاندارد شده است و از دستورات (Directives) و رکوردهای منابع (Resource Records) تشکیل شده است.

Directives: دستوراتی هستند که نحوه تفسیر فایل را مشخص می‌کنند، مانند:

$ORIGIN: نام دامنه اصلی که رکوردهای بعدی به آن اضافه می‌شوند (اگر نام کامل نباشد).

$TTL: مقدار Time To Live پیش‌فرض برای تمام رکوردهایی که TTL مشخصی ندارند.

Resource Records (RR): هر خط در Zone File که با یک رکورد DNS مطابقت دارد. فرمت کلی یک رکورد DNS به صورت زیر است:

[Name] [TTL] [Class] [Type] [Data]

Name: نام دامنه یا زیردامنه. اگر خالی باشد، به $ORIGIN ارجاع داده می‌شود.

TTL: Time To Live (اختیاری، اگر مشخص نشود از $TTL استفاده می‌شود).

Class: معمولاً IN برای Internet.

Type: نوع رکورد (A, MX, CNAME, SOA و…).

Data: اطلاعات مربوط به رکورد (آدرس IP، نام سرور، متن و…).

ساختار Zone File

در اینجا یک مثال از ساختار یک Zone File برای دامنه example.com آورده شده است:

; This is a comment line

$ORIGIN example.com.
$TTL 3600 ; Default TTL for 1 hour

@ IN SOA ns1.example.com. admin.example.com. (
2026032901 ; Serial Number: YYYYMMDDnn
3600 ; Refresh Interval (1 hour)
900 ; Retry Interval (15 minutes)
604800 ; Expire Time (1 week)
86400 ; Minimum TTL (1 day)
)

; Name Server Records
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.

; Address Records
@ IN A 93.184.216.34 ; Main IP for example.com
www IN A 93.184.216.34 ; IP for www.example.com
mail IN A 192.168.1.100 ; IP for mail server

; Mail Exchange Records
@ IN MX 10 mail.example.com. ; Primary mail server
@ IN MX 20 backup-mail.example.com. ; Secondary mail server

; Canonical Name Record
ftp IN CNAME example.com. ; ftp.example.com is an alias for example.com

; Text Records
@ IN TXT “v=spf1 mx -all” ; SPF record for email authentication
@ IN TXT “google-site-verification=abcdef12345” ; Verification for Google Search Console

توضیحات:

خطوطی که با ; شروع می‌شوند، توضیحات هستند و توسط سرور DNS نادیده گرفته می‌شوند.

@ در ستون Name معمولاً به $ORIGIN اشاره دارد (در این مثال example.com.).

رکورد SOA اطلاعات مدیریتی ناحیه را ارائه می‌دهد.

رکوردهای NS سرورهای DNS معتبر برای این دامنه را مشخص می‌کنند.

رکوردهای A آدرس‌های IPv4 را برای نام‌های دامنه/زیردامنه مشخص می‌کنند.

رکورد MX سرورهای ایمیل را تعیین می‌کند.

رکورد CNAME برای ایجاد نام مستعار استفاده شده است.

رکوردهای TXT برای اهداف تأیید و امنیتی به کار رفته‌اند.

انواع DNS Zones

DNS Zones بر اساس نحوه نگهداری و نقششان در سیستم DNS دسته‌بندی می‌شوند:

Primary Zone (ناحیه اولیه):
این نسخه اصلی و قابل ویرایش از Zone File است. تمام تغییرات و به‌روزرسانی‌ها ابتدا در این ناحیه اعمال می‌شوند. سرور DNS که این ناحیه را میزبانی می‌کند، Primary DNS Server نامیده می‌شود.

Secondary Zone (ناحیه ثانویه):
این ناحیه یک کپی فقط‌خواندنی (Read-only) از ناحیه اولیه است. سرور DNS که ناحیه ثانویه را میزبانی می‌کند، Secondary DNS Server نامیده می‌شود. Secondary Zones برای افزایش دسترس‌پذیری (Availability) و تحمل خطا (Fault Tolerance) ایجاد می‌شوند. اگر Primary Server از دسترس خارج شود، Secondary Server می‌تواند به پرس‌وجوها پاسخ دهد. اطلاعات از Primary به Secondary از طریق فرآیندی به نام Zone Transfer منتقل می‌شود.

Stub Zone (ناحیه Stub):
یک Stub Zone اطلاعاتی در مورد ناحیه دیگری که توسط سرور DNS متفاوتی مدیریت می‌شود، نگهداری می‌کند. این نوع ناحیه فقط شامل رکوردهای NS (Name Server) و SOA (Start of Authority) ناحیه دیگر است. هدف از Stub Zone، کاهش بار بر روی Primary Name Server و بهبود کارایی Recursive Resolverها است. Stub Resolver فقط نیاز دارد که بداند کدام سرور معتبر را برای یک ناحیه خاص پرس‌وجو کند.

Reverse Zone (ناحیه معکوس):
این ناحیه برای انجام Reverse DNS Lookup استفاده می‌شود (تبدیل IP به نام). ساختار نام‌گذاری برای Reverse Zones متفاوت است و از دامنه‌های خاصی مانند in-addr.arpa (برای IPv4) یا ip6.arpa (برای IPv6) استفاده می‌کند. رکوردهای PTR در این نواحی نگهداری می‌شوند.

مدیریت صحیح Zone Fileها و درک انواع نواحی DNS برای اطمینان از عملکرد صحیح و پایدار سرویس‌های مبتنی بر دامنه حیاتی است.

DNS Load Balancing و Failover

DNS یکی از ابزارهای قدرتمند برای پیاده‌سازی Load Balancing (توزیع بار) و Failover (انتقال خودکار به پشتیبان) در شبکه های کامپیوتری است. این تکنیک ها به افزایش دسترس پذیری، بهبود عملکرد و مقیاس پذیری وب سایت ها و سرویس های آنلاین کمک می‌کنند.

برای اینکه با مباحت لود بالانسینگ (Load Balancing) آشنا شوید اینجا را بخوانید.

Round Robin DNS

این ساده‌ترین روش Load Balancing با استفاده از DNS است. در این روش، چندین رکورد A (یا AAAA) برای یک نام دامنه یا زیردامنه با آدرس‌های IP مختلف تعریف می‌شود. هنگامی که یک Resolver پرس‌وجو می‌کند، سرور DNS لیستی از این آدرس‌های IP را به ترتیب چرخشی (Round Robin) به Resolver برمی‌گرداند.

مثال:

example.com. IN A 192.168.1.10
example.com. IN A 192.168.1.11
example.com. IN A 192.168.1.12

وقتی Resolver اول پرس‌وجو می‌کند، ممکن است 192.168.1.10 را دریافت کند. پرس‌وجوی بعدی 192.168.1.11 و پرس‌وجوی بعدی 192.168.1.12 را دریافت خواهد کرد.

محدودیت‌ها:

Round Robin DNS از وضعیت سلامت سرورها (Health Status) اطلاعی ندارد. اگر یکی از سرورها از کار بیفتد، همچنان ممکن است در لیست آدرس‌های برگشتی قرار گیرد و کاربران به آن هدایت شوند.

توزیع بار همیشه یکنواخت نیست، زیرا Resolverها ممکن است خود اطلاعات را کش کنند.

GeoDNS / Geographic Load Balancing

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

مزایا:

کاهش تأخیر (Latency) برای کاربران با هدایت آن‌ها به نزدیک‌ترین سرور.

توزیع بار بر اساس منطق جغرافیایی.

امکان مسیریابی کاربران یک منطقه به سرورهای مخصوص آن منطقه.

خیلی از مدیران سایت ها با توجه به شرایطی که در ایران ایجاد شد برای اینترنت، برای سایت های خود جئو dns یا همان geo dns انجام داده اند، که البته اغلب با مشکلاتی مانند کندی سرعت رو برو شده اند، اگر در رابطه با geo dns سوالاتی دارید، حتما اینجا را بخوانید» آموزش Geo DNS و آشنایی و روش انجام جئو dns

Weighted DNS (DNS با وزن‌دهی)

این روش امکان توزیع بار نامتعادل را فراهم می‌کند. به هر سرور در لیست رکوردهای A (یا AAAA) یک وزن (Weight) اختصاص داده می‌شود. سرورهایی که وزن بالاتری دارند، احتمال بیشتری دارد که در لیست آدرس‌های IP برگشتی ظاهر شوند.

مثال:

server1.example.com. IN A 192.168.1.10 (Weight: 3)
server2.example.com. IN A 192.168.1.11 (Weight: 1)

در این حالت، server1 سه برابر server2 درخواست دریافت خواهد کرد. این روش برای سرورهایی با توان پردازشی متفاوت یا برای تست یک سرور جدید قبل از اختصاص تمام بار به آن، مفید است.

Failover DNS

Failover DNS به طور خودکار کاربران را به یک سرور پشتیبان هدایت می‌کند، در صورتی که سرور اصلی از دسترس خارج شود. این کار معمولاً با ترکیب DNS با سیستم‌های مانیتورینگ سلامت (Health Monitoring Systems) انجام می‌شود.

نحوه عملکرد:

یک سیستم مانیتورینگ به طور مداوم وضعیت سلامت سرورهای اصلی و پشتیبان را بررسی می‌کند.

در صورت تشخیص عدم در دسترس بودن سرور اصلی، سیستم مانیتورینگ به طور خودکار رکورد DNS مربوطه را تغییر می‌دهد (مثلاً با حذف رکورد IP سرور اصلی از لیست یا تغییر آن به IP سرور پشتیبان).

با اعمال تغییرات DNS، Resolverها به مرور زمان (بسته به TTL) به سمت سرور پشتیبان هدایت می‌شوند.

مزایا:

افزایش دسترس‌پذیری سرویس در صورت بروز مشکل در سرور اصلی.

کاهش زمان قطعی سرویس.

نکته مهم: این روش‌ها اغلب با هم ترکیب می‌شوند. به عنوان مثال، ممکن است از Weighted DNS برای توزیع بار بین چندین سرور فعال و سپس از Failover DNS برای هدایت کاربران به سرورهای پشتیبان در صورت خرابی همه سرورهای فعال استفاده شود. این تکنیک‌ها ابزارهای قدرتمندی برای اطمینان از ارائه خدمات پایدار و با کارایی بالا در دنیای آنلاین هستند.

DNS Tools و دیباگ کردن

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

nslookup

nslookup (name server lookup) یکی از ابزارهای کلاسیک و پرکاربرد برای پرس‌وجو از سرورهای DNS است که در سیستم‌عامل‌های ویندوز، macOS و لینوکس به صورت پیش‌فرض موجود است.

نحوه استفاده:

پرس‌وجوی ساده:

nslookup google.com

این دستور آدرس IP (رکورد A) و معکوس آن (اگر موجود باشد) را برای google.com نمایش می‌دهد.

مشخص کردن نوع رکورد:

nslookup -type=mx example.com

این دستور رکوردهای MX (Mail Exchange) را برای دامنه example.com نمایش می‌دهد. انواع دیگر شامل ns, txt, soa, aaaa و any هستند.

پرس‌وجو از یک سرور DNS خاص:

nslookup google.com 8.8.8.8

این دستور پرس‌وجو را به سرور DNS 8.8.8.8 (Google Public DNS) ارسال می‌کند.

حالت تعاملی:
با تایپ nslookup و فشردن Enter، وارد حالت تعاملی می‌شوید که می‌توانید دستورات متعددی را پشت سر هم اجرا کنید.

dig (Domain Information Groper)

dig یک ابزار قدرتمندتر و حرفه‌ای‌تر برای پرس‌وجو از DNS است که عمدتاً در سیستم‌عامل‌های مبتنی بر یونیکس (لینوکس، macOS) یافت می‌شود. dig اطلاعات بسیار جزئی‌تری نسبت به nslookup ارائه می‌دهد.

نحوه استفاده:

پرس‌وجوی ساده:

dig google.com

خروجی شامل جزئیاتی مانند TTL، سرور پاسخ‌دهنده و رکورد DNS است.

نمایش کامل مسیر جستجو (Trace):

dig +trace example.com

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

پرس‌وجوی معکوس (Reverse DNS):

dig -x 8.8.8.8

این دستور، نام دامنه مربوط به آدرس IP 8.8.8.8 را جستجو می‌کند.

پرس‌وجو از سرور DNS خاص و نوع رکورد:

dig @8.8.8.8 example.com A

این دستور، رکورد A را برای example.com از سرور 8.8.8.8 درخواست می‌کند.

host

host یک ابزار ساده‌تر در سیستم‌عامل‌های لینوکس و macOS است که برای پرس‌وجوهای DNS سریع و ابتدایی استفاده می‌شود.

نحوه استفاده:

پرس‌وجوی ساده:

host google.com

مشخص کردن نوع رکورد:

host -t mx gmail.com

ابزارهای آنلاین

علاوه بر ابزارهای خط فرمان، وب‌سایت‌های متعددی وجود دارند که امکان بررسی DNS را به صورت آنلاین فراهم می‌کنند:

DNS Checker (dnschecker.org): ابزاری جامع برای بررسی انواع رکوردهای DNS در سراسر جهان، وضعیت انتشار DNS، و بررسی ابزارهای دیگر DNS.

What’s My DNS (whatsmydns.net): نمایش وضعیت انتشار DNS در سرورهای مختلف DNS در سراسر جهان.

IntoDNS (intodns.com): تحلیل جامعی از پیکربندی DNS یک دامنه، از جمله رکوردهای MX، NS، A، و مشکلات احتمالی.

MXToolbox (mxtoolbox.com): مجموعه‌ای از ابزارهای مفید برای بررسی DNS، MX Records، SPF، و عیب‌یابی مشکلات ایمیل.

کدهای خطای رایج DNS

هنگام عیب‌یابی DNS، ممکن است با کدهای خطای مختلفی مواجه شوید:

NXDOMAIN (Non-Existent Domain): دامنه درخواستی وجود ندارد.

SERVFAIL (Server Failure): سرور DNS با خطایی مواجه شده و قادر به پردازش درخواست نبوده است.

REFUSED (Connection Refused): سرور DNS درخواست را رد کرده است (ممکن است به دلیل پیکربندی نامناسب یا خط‌مشی‌های امنیتی).

NOERROR با 0 پاسخ: دامنه وجود دارد، اما رکورد درخواستی (مثلاً رکورد A) برای آن تعریف نشده است.

استفاده منظم از این ابزارها به شما کمک می‌کند تا همواره از سلامت و عملکرد صحیح تنظیمات DNS خود اطمینان حاصل کنید.

DNS در عمل: مدیریت DNS برای وب‌سایت

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

گام‌های عملی برای تنظیم DNS

خرید دامنه (Domain Registration):

اولین گام، خرید نام دامنه مورد نظر شما از یک شرکت ثبت دامنه (Domain Registrar) معتبر است. Registrarها مانند GoDaddy, Namecheap, Dynadot, یا در ایران، Nic.ir، امکان ثبت و مدیریت دامنه‌های اینترنتی را فراهم می‌کنند.

انتخاب DNS Provider:
پس از خرید دامنه، شما نیاز به یک سرویس DNS دارید که رکوردهای دامنه شما را مدیریت کند. سه گزینه اصلی وجود دارد:

DNS Registrar: بسیاری از Registrarها خدمات DNS رایگان را همراه با خرید دامنه ارائه می‌دهند. این گزینه ساده‌ترین راه برای شروع است، اما ممکن است قابلیت‌های پیشرفته یا سرعت بالایی نداشته باشد.

DNS هاستینگ (Hosting DNS): ارائه‌دهندگان خدمات هاستینگ وب (مانند HostGator, Bluehost, یا هاستینگ‌های داخلی) معمولاً خدمات DNS را نیز به صورت رایگان یا پولی ارائه می‌دهند. این گزینه برای کسانی که وب‌سایت خود را روی همان سرور هاست می‌کنند، راحت است.

DNS اختصاصی (Managed DNS): این خدمات توسط شرکت‌های تخصصی DNS ارائه می‌شوند که تمرکز اصلی آن‌ها بر روی سرعت، قابلیت اطمینان، امنیت و قابلیت‌های پیشرفته DNS است. مثال‌های مطرح عبارتند از: Cloudflare DNS, AWS Route 53, Google Cloud DNS, Akamai Edge DNS. این گزینه برای وب‌سایت‌های بزرگ، با ترافیک بالا و نیازمند بالاترین سطح دسترسی‌پذیری توصیه می‌شود.

تنظیم Nameservers (NS Records):

پس از انتخاب DNS Provider، باید Nameserverهای دامنه خود را به Nameserverهای ارائه‌دهنده جدید تغییر دهید. این تنظیم در پنل مدیریت دامنه (در وب‌سایت Registrar) انجام می‌شود. شما باید آدرس Nameserverهایی که DNS Provider به شما داده است (مثلاً ns1.cloudflare.com, ns2.cloudflare.com) را در بخش مربوط به Nameservers دامنه خود وارد کنید. این تغییر ممکن است تا 24-48 ساعت (بسته به TTL) طول بکشد تا در سراسر اینترنت منتشر شود.

افزودن رکوردهای ضروری DNS:

پس از اینکه Nameserverها به روز شدند، شما باید رکوردهای DNS لازم را در پنل مدیریت DNS Provider خود اضافه کنید. رکوردهای ضروری معمولاً شامل موارد زیر هستند:

A/AAAA Record: برای اشاره به آدرس IP سروری که وب‌سایت شما روی آن قرار دارد. این رکورد برای دسترسی به وب‌سایت ضروری است.

MX Record: برای دریافت ایمیل‌های مربوط به دامنه شما. باید سرور(های) ایمیل و اولویت آن‌ها را مشخص کنید.

TXT Record: برای تأیید مالکیت دامنه (مثلاً برای Google Search Console) و پیکربندی SPF، DKIM و DMARC برای افزایش امنیت ایمیل.

CNAME Record: برای ایجاد نام‌های مستعار (Alias) مانند www به دامنه اصلی، یا برای اشاره به سرویس‌های خارجی (مانند سرویس‌های CDN).

NS Record: برای مشخص کردن Nameserverهای معتبر برای دامنه (این رکوردها معمولاً توسط DNS Provider شما مدیریت می‌شوند).

تست و مانیتورینگ:
پس از اضافه کردن و به‌روزرسانی رکوردهای DNS، ضروری است که عملکرد آن‌ها را تست کنید.

از ابزارهای خط فرمان مانند dig یا nslookup برای بررسی صحت رکوردهای اضافه شده استفاده کنید.

از ابزارهای آنلاین مانند DNS Checker یا IntoDNS برای اطمینان از انتشار صحیح تغییرات و عدم وجود خطاهای پیکربندی استفاده کنید.

عملکرد وب سایت و سرویس ایمیل را به طور مداوم مانیتور کنید تا از دسترس‌پذیری آنها اطمینان حاصل شود.

نکات حرفه ای مدیریت DNS

TTL را هوشمند تنظیم کنید: همانطور که پیشتر اشاره شد، قبل از اعمال تغییرات مهم در رکوردهای DNS، TTL را به مقدار پایین (مثلاً 300 ثانیه) کاهش دهید و پس از انتشار تغییرات، آن را مجدداً افزایش دهید.

از DNSSEC استفاده کنید: اگر DNS Provider شما از DNSSEC پشتیبانی می کند، آن را فعال کنید. این امر امنیت DNS شما را در برابر حملاتی مانند Cache Poisoning به طور قابل توجهی افزایش میدهد.

داشتن Multiple NS Records: همیشه از حداقل دو Nameserver معتبر برای دامنه خود استفاده کنید. این کار دسترس‌پذیری DNS را افزایش می‌دهد.

مانیتورینگ مداوم: قطعی DNS می‌تواند وب‌سایت شما را کاملاً از دسترس خارج کند. از ابزارهای مانیتورینگ برای تشخیص سریع هرگونه مشکل DNS استفاده کنید.

استفاده از API مدیریت DNS: برای اتوماسیون فرآیندهای مربوط به مدیریت DNS (مثلاً در زمان استقرار نرم‌افزار یا تغییرات گسترده)، استفاده از APIهای ارائه شده توسط DNS Providerها بسیار مفید است.

امنیت Registrar Account: حساب کاربری Registrar شما که دامنه را از آن خریده‌اید، بسیار حساس است. احراز هویت دو مرحله‌ای (2FA) را برای آن فعال کنید تا از ربوده شدن دامنه جلوگیری شود.

بررسی رکوردهای TXT: اطمینان حاصل کنید که رکوردهای SPF، DKIM و DMARC شما به درستی پیکربندی شده‌اند تا از مشکلات تحویل ایمیل جلوگیری شود.

مدیریت صحیح DNS یک فرآیند مستمر است که نیاز به توجه و دانش کافی دارد. با رعایت این نکات، می‌توانید اطمینان حاصل کنید که وب‌سایت و سرویس‌های شما به بهترین شکل ممکن عمل می‌کنند.

DNS و CDN (شبکه توزیع محتوا)

شبکه های توزیع محتوا (Content Delivery Networks – CDN) مانند Cloudflare, Akamai, Fastly و Amazon CloudFront، نقش حیاتی در بهبود سرعت، امنیت و دسترس‌پذیری وب‌سایت‌ها دارند. DNS یکی از مؤلفه‌های کلیدی است که CDNها برای دستیابی به این اهداف از آن بهره می‌برند.

نحوه استفاده CDN ها از DNS:

Anycast DNS:
بسیاری از CDNها از تکنیک Anycast برای استقرار سرورهای DNS خود استفاده می‌کنند. در Anycast، چندین سرور DNS در نقاط جغرافیایی مختلف، یک آدرس IP واحد را به اشتراک می‌گذارند. وقتی کاربر درخواستی را ارسال می‌کند، ترافیک به نزدیک‌ترین سرور DNS موجود هدایت می‌شود. این امر باعث کاهش تأخیر در پاسخ‌دهی DNS و توزیع بار بین سرورها می‌شود.

Geo-aware DNS (DNS آگاه از موقعیت جغرافیایی):

CDNها با استفاده از DNS، کاربران را به نزدیک‌ترین سرور لبه (Edge Server) خود هدایت می‌کنند. وقتی کاربری درخواست یک صفحه وب را ارسال می‌کند، DNS CDN آدرس IP سرور لبه‌ای که از نظر جغرافیایی به کاربر نزدیک‌تر است را برمی‌گرداند. این کار باعث می‌شود که محتوا سریع‌تر به کاربر تحویل داده شود، زیرا مسافت فیزیکی کمتری طی می‌شود.

CNAME Flattening:

برخی از CDNها از Record Type خاصی به نام ALIAS یا ANAME استفاده می‌کنند که شبیه CNAME عمل می‌کند اما می‌تواند در ریشه دامنه (Apex Domain) نیز استفاده شود. از آنجایی که ریشه دامنه نمی‌تواند CNAME داشته باشد (به دلیل تداخل با رکوردهای NS و SOA)، CNAME Flattening این مشکل را حل می‌کند. DNS Providerهای پیشرفته، CNAME Flattening را به صورت خودکار انجام می‌دهند؛ به این معنی که وقتی شما یک CNAME را برای دامنه اصلی خود تنظیم می‌کنید، آن‌ها آن را به یک رکورد A یا AAAA معادل تبدیل می‌کنند.

DDoS Protection (حفاظت در برابر حملات DDoS):
CDNها اغلب لایه اول دفاع در برابر حملات DDoS هستند. آن‌ها با استفاده از شبکه گسترده سرورهای خود و DNS، می‌توانند ترافیک مخرب را فیلتر کنند. در لایه DNS، CDNها می‌توانند درخواست‌های مخرب را شناسایی کرده و قبل از رسیدن به سرور اصلی شما، مسدود کنند. همچنین، با Anycast DNS، حتی در صورت حمله به یک نقطه، سایر نقاط شبکه فعال باقی می‌مانند.

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

به طور خلاصه، CDNها از DNS به عنوان یک ابزار استراتژیک برای توزیع هوشمند ترافیک، کاهش تأخیر، افزایش امنیت و اطمینان از دسترس‌پذیری بالای وب‌سایت‌ها در سطح جهانی استفاده می‌کنند.

IPv6 و DNS

با نزدیک شدن به پایان تخصیص آدرس‌های IPv4، اینترنت به سمت پذیرش گسترده‌تر IPv6 در حرکت است. این انتقال، بر روی سیستم DNS نیز تأثیر گذاشته و تغییراتی را ایجاب کرده است.

AAAA Records

برای نگاشت نام دامنه‌ها به آدرس‌های IPv6، از رکوردهای DNS به نام AAAA Records استفاده می‌شود. این رکوردها معادل رکوردهای A برای IPv4 هستند. هر نام دامنه می‌تواند هم دارای رکورد A (برای IPv4) و هم رکورد AAAA (برای IPv6) باشد. این وضعیت به عنوان Dual Stack شناخته می‌شود و به دستگاه‌ها اجازه می‌دهد تا با استفاده از هر دو پروتکل، با دیگران ارتباط برقرار کنند.

مثال:
example.com. IN A 93.184.216.34example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946

Reverse DNS برای IPv6

مشابه Reverse DNS برای IPv4 که از رکورد PTR در دامنه in-addr.arpa استفاده می‌کند، برای IPv6 نیز مکانیزم مشابهی وجود دارد. این مکانیزم از رکوردهای PTR در دامنه‌های خاصی مانند ip6.arpa استفاده می‌کند. آدرس IPv6 به صورت معکوس و با افزودن پسوند ip6.arpa ساخته می‌شود.

مثال:
برای آدرس IPv6 2001:db8::1، نام دامنه برای Reverse DNS Lookup به صورت 1.0.0.0.0.0.0.0.0.0.0.0.8.b.d.2.0.0.2.ip6.arpa. خواهد بود.

چالش‌های IPv6 و DNS

با وجود پیشرفت‌ها، انتقال کامل به IPv6 و ادغام آن با DNS با چالش‌هایی همراه است:

پشتیبانی شبکه‌ای: برخی از شبکه‌های قدیمی یا تجهیزات شبکه ممکن است هنوز به طور کامل از IPv6 پشتیبانی نکنند. این موضوع می‌تواند مانع ارتباط دستگاه‌هایی شود که تنها IPv6 دارند.

پیکربندی فایروال: فایروال‌ها و تجهیزات امنیتی شبکه ممکن است ترافیک DNS (UDP/TCP پورت 53) را بر روی IPv6 مسدود کنند، که این امر مانع عملکرد صحیح DNS برای آدرس‌های IPv6 می‌شود.

پشتیبانی نرم‌افزاری: برخی از نرم‌افزارها و سرویس‌ها ممکن است هنوز به طور کامل برای کار با IPv6 بهینه نشده باشند.

مدیریت رکوردهای IPv6: نگهداری و مدیریت صحیح رکوردهای AAAA که معمولاً طولانی‌تر از رکوردهای A هستند، نیازمند دقت بیشتری است.

با این حال، با افزایش adoption IPv6، سیستم DNS نیز به طور مداوم در حال سازگاری و بهبود برای پشتیبانی بهتر از این نسل جدید پروتکل اینترنت است.

آینده DNS

سیستم نام دامنه (DNS) که اساساً در دهه 1980 طراحی شد، به طور مداوم در حال تکامل برای پاسخگویی به نیازهای امنیتی، حریم خصوصی و عملکردی دنیای مدرن اینترنت است. در ادامه به برخی از روندهای کلیدی و نوآوری‌های آینده DNS می‌پردازیم:

DNS over HTTPS (DoH) و DNS over TLS (DoT)

این پروتکل‌ها دیگر صرفاً مفاهیم نوظهور نیستند، بلکه به سرعت در حال تبدیل شدن به استاندارد هستند. مرورگرهای اصلی مانند Firefox و Chrome به طور فزاینده‌ای از DoH به صورت پیش‌فرض یا با امکان فعال‌سازی آسان استفاده می‌کنند. این روند نشان‌دهنده اهمیت روزافزون حریم خصوصی کاربران و نیاز به محافظت از ترافیک DNS در برابر شنود و دستکاری است. انتظار می‌رود که استفاده از DoH و DoT در سال‌های آینده به طور چشمگیری افزایش یابد.

Oblivious DNS over HTTPS (ODoH)

ODoH یک گام فراتر از DoH است و هدف آن افزایش بیشتر حریم خصوصی کاربران است. در ODoH، درخواست DNS ابتدا به یک سرور پروکسی (Relay) ارسال می‌شود و سپس این پروکسی درخواست را به سرور DNS ارسال می‌کند. این لایه اضافی باعث می‌شود که هم سرور DNS و هم سرور پروکسی، اطلاعات کاملی از هویت کاربر و درخواست او نداشته باشند (Relay does not know the DNS query, DNS server does not know the client IP). این رویکرد، حریم خصوصی را در برابر هر دو طرف (ISP، ارائه‌دهنده DNS و سرور پروکسی) به حداکثر می‌رساند.

DNS over QUIC (DoQ)

QUIC یک پروتکل حمل و نقل جدید است که توسط گوگل توسعه یافته و پایه پروتکل HTTP/3 را تشکیل می‌دهد. QUIC بر پایه UDP ساخته شده و مزایایی مانند کاهش تأخیر اتصال (Connection Establishment Latency)، تحمل بهتر خطا و مدیریت جریان داده را ارائه می‌دهد. DoQ با ترکیب امنیت و کارایی QUIC با نیازهای DNS، پتانسیل کاهش قابل توجهی در تأخیر جستجوهای DNS و بهبود کلی عملکرد شبکه را دارد.

Decentralized DNS (DNS غیرمتمرکز)

با ظهور فناوری بلاکچین و علاقه‌مندی به سیستم‌های غیرمتمرکز، پروژه‌هایی برای ایجاد یک سیستم DNS غیرمتمرکز در حال ظهور هستند. نمونه‌هایی مانند ENS (Ethereum Name Service) و Handshake، تلاش می‌کنند تا DNS را از کنترل متمرکز خارج کرده و آن را در برابر سانسور و دستکاری مقاوم‌تر سازند. در این سیستم‌ها، نام دامنه‌ها به جای نگهداری در سرورهای متمرکز، بر روی بلاکچین ثبت می‌شوند.

هوش مصنوعی (AI) در DNS

استفاده از هوش مصنوعی و یادگیری ماشین در سیستم‌های DNS در حال افزایش است. AI می‌تواند برای موارد زیر به کار رود:

پیش‌بینی و تشخیص تهدیدات: شناسایی الگوهای مشکوک ترافیک DNS که ممکن است نشان‌دهنده حملات DDoS، DNS Tunneling یا بدافزار باشند.

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

مدیریت خودکار: اتوماسیون فرآیندهای پیچیده مدیریت DNS.

DNS و اینترنت اشیا (IoT)

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

DNS و حریم خصوصی

با توجه به نگرانی‌های روزافزون در مورد حریم خصوصی داده‌ها، انتظار می‌رود که تقاضا برای سرویس‌های DNS که حریم خصوصی را در اولویت قرار می‌دهند، افزایش یابد. این شامل خدماتی است که لاگ‌های DNS را نگهداری نمی‌کنند یا حداقل این لاگ‌ها را برای مدت زمان کوتاهی نگه می‌دارند.

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

جمع بندی و نتیجه گیری dns

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

در طول این مقاله، به بررسی عمیق جنبه‌های مختلف DNS پرداختیم:

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

تاریخچه و دلیل اختراع: مشکلات ناشی از روش‌های اولیه مدیریت نام‌ها (HOSTS.TXT) و نحوه ظهور DNS مدرن در دهه 1980 را مرور کردیم.

معماری و ساختار: ساختار سلسله‌مراتبی (ریشه، TLD، SLD، زیردامنه) و اجزای اصلی سیستم (سرورهای ریشه، TLD، معتبر و Resolverها) را تشریح کردیم.

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

انواع رکوردهای DNS: با انواع پرکاربرد مانند A, AAAA, CNAME, MX, NS, TXT, SOA و کاربردهای آن‌ها آشنا شدیم.

کشینگ و انتشار: مکانیزم TTL و اهمیت کشینگ DNS در افزایش سرعت و کاهش بار شبکه، و همچنین مفهوم DNS Propagation را بررسی کردیم.

امنیت DNS: تهدیدات امنیتی رایج مانند DNS Spoofing، Amplification DDoS و راهکارهای مقابله‌ای مانند DNSSEC، DoH و DoT را معرفی کردیم.

مدیریت ناحیه و Zone File: با ساختار فایل‌های ناحیه و انواع مختلف نواحی DNS آشنا شدیم.

Load Balancing و Failover: نقش DNS در توزیع بار و افزایش دسترس‌پذیری از طریق تکنیک‌هایی مانند Round Robin و GeoDNS را توضیح دادیم.

ابزارهای DNS: ابزارهای کاربردی مانند nslookup، dig و منابع آنلاین برای عیب‌یابی و مدیریت DNS را معرفی کردیم.

مدیریت عملی DNS: گام‌های ضروری برای تنظیم DNS یک وب‌سایت و نکات حرفه‌ای برای مدیریت بهینه آن را بیان کردیم.

DNS و CDN، IPv6 و آینده DNS: به نقش DNS در CDNها، سازگاری آن با IPv6 و روندهای آینده مانند DoH، DoT، DNS غیرمتمرکز و AI در DNS پرداختیم.

نکات کلیدی که باید به خاطر سپرد:

DNS یک سیستم پیچیده و توزیع‌شده است که برای ترجمه نام‌های دامنه به آدرس‌های IP ضروری است.

فرآیند جستجوی DNS شامل چندین مرحله و تعامل بین سرورهای مختلف است.

انواع رکوردهای DNS اطلاعات متنوعی را برای عملکرد سرویس‌های مختلف ذخیره می‌کنند.

کش کردن DNS برای سرعت و کارایی حیاتی است، اما انتشار تغییرات زمان‌بر است.

امنیت DNS یک نگرانی رو به رشد است و راهکارهایی مانند DNSSEC و DoH/DoT برای مقابله با آن وجود دارد.

مدیریت صحیح DNS، بخش جدایی‌ناپذیر از راه‌اندازی و نگهداری هر وب‌سایت یا سرویس آنلاین است.

امیدواریم این مقاله جامع توانسته باشد به طور کامل به سؤال «DNS چیست؟» پاسخ دهد و درک شما را از این فناوری بنیادین اینترنت عمیق‌تر کرده باشد. DNS شاید در ظاهر ساده به نظر برسد، اما در عمق، دنیایی از پیچیدگی، مهندسی هوشمندانه و همکاری جهانی را در خود جای داده است.

پرسش‌های متداول (FAQ) در خصوص dns

سؤال ۱: DNS روی چه پورتی کار می‌کند؟

DNS عمدتاً از UDP پورت 53 برای اکثر پرس و جوهای کلاینت به سرور استفاده می کند. UDP سریع تر است و سربار کمتری دارد. با این حال، برای انتقال حجم بالای داده مانند Zone Transfer (انتقال کل اطلاعات یک ناحیه DNS از یک سرور به سرور دیگر)، از TCP پورت 53 استفاده می‌شود، زیرا TCP اتصال قابل اطمینان‌تری را تضمین می‌کند.

سؤال ۲: تفاوت DNS و Nameserver چیست؟

DNS (Domain Name System) یک پروتکل و یک سیستم توزیع‌شده جهانی است که مسئول ترجمه نام‌های دامنه به آدرس‌های IP است.
Nameserver (سرور نام) یک سرور فیزیکی یا مجازی است که نرم‌افزار DNS را اجرا می‌کند و به پرس‌وجوهای DNS پاسخ می‌دهد. Nameserverها بخشی از سیستم DNS هستند و داده‌های DNS را میزبانی و مدیریت می‌کنند.

سؤال ۳: بهترین DNS عمومی چیست؟

انتخاب “بهترین” DNS عمومی به اولویت شما (سرعت، حریم خصوصی، امنیت، قابلیت‌های اضافه) بستگی دارد، اما برخی از محبوب‌ترین و مورد اعتمادترین گزینه‌ها عبارتند از:

Cloudflare DNS: 1.1.1.1 و 1.0.0.1 (تمرکز قوی بر سرعت و حریم خصوصی)

Google Public DNS: 8.8.8.8 و 8.8.4.4 (قابلیت اعتماد بالا و عملکرد خوب)

Quad9 DNS: 9.9.9.9 و 149.112.112.112 (تمرکز بر امنیت و مسدودسازی بدافزارها)

OpenDNS: 208.67.222.222 و 208.67.220.220 (ارائه قابلیت‌های اضافی مانند فیلترینگ محتوا و کنترل والدین)

سؤال ۴: آیا تغییر DNS سرعت اینترنت را افزایش می‌دهد؟

تغییر DNS به طور مستقیم سرعت دانلود یا آپلود (پهنای باند) اینترنت شما را افزایش نمی دهد. اما می‌تواند زمان بارگذاری اولیه وب سایت ها را کاهش دهد. اگر DNS Provider فعلی شما کند باشد، تغییر به یک DNS سریع تر باعث می شود که کامپیوتر شما سریع تر آدرس IP سرور وب سایت را پیدا کند و فرآیند اتصال و بارگذاری صفحه سریع تر آغاز شود.

سؤال ۵: DNS لاگینگ چیست و آیا خطرناک است؟

DNS Logging به معنای ثبت و نگهداری تاریخچه‌ی تمام درخواست های DNS است که توسط کاربران یک شبکه یا توسط یک Resolver انجام می‌شود. ارائه‌دهندگان DNS ممکن است این لاگ‌ها را برای اهداف مختلفی مانند تحلیل عملکرد، عیب‌یابی، تبلیغات هدفمند یا حتی به اشتراک‌گذاری با نهادهای دیگر نگهداری کنند.

خطرناک بودن آن به نحوه استفاده از این لاگ‌ها بستگی دارد:

اگر لاگ‌ها حاوی اطلاعات حساسی در مورد فعالیت‌های آنلاین شما باشند و به درستی محافظت نشوند، می‌توانند خطر نقض حریم خصوصی را به همراه داشته باشند.

استفاده از سرویس‌های DNS که تاکید زیادی بر حفظ حریم خصوصی دارند (مانند Cloudflare یا Quad9) و یا استفاده از DoH/DoT، می‌تواند این نگرانی‌ها را کاهش دهد.

سؤال ۶: DNS Cache چیست و چطور پاک می‌شود؟

DNS Cache حافظه موقتی است که نتایج جستجوهای DNS را برای مدتی ذخیره می‌کند تا از نیاز به پرس‌وجوهای مکرر در شبکه جلوگیری شود. این کش در سطوح مختلف (مرورگر، سیستم‌عامل، Resolver) وجود دارد.

برای پاک کردن DNS Cache در سیستم‌عامل خود، می‌توانید از دستورات زیر استفاده کنید:

ویندوز:
Command Prompt را با دسترسی Administrator باز کرده و دستور زیر را اجرا کنید: ipconfig /flushdns

macOS:
Terminal را باز کرده و دستور زیر را اجرا کنید: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (پس از اجرای دستور، رمز عبور خود را وارد کنید.)

لینوکس:
روش پاک کردن کش DNS بسته به سیستم init (systemd یا SysVinit) و سرویس DNS مورد استفاده متفاوت است. برای سیستم‌هایی که از systemd-resolved استفاده می‌کنند: sudo systemd-resolve –flush-caches برای توزیع‌هایی که از dnsmasq استفاده می‌کنند: sudo /etc/init.d/dnsmasq restart

سؤال ۷: دامنه .ir هم از DNS استفاده می‌کند؟

بله، قطعاً. تمام دامنه‌های اینترنتی، از جمله دامنه‌های سطح بالای ملی مانند .ir، کاملاً بر اساس پروتکل استاندارد DNS کار می‌کنند. مرکز ثبت دامنه ایران (IRNIC) مسئولیت مدیریت دامنه .ir را بر عهده دارد و رکوردهای DNS مربوط به این دامنه در سرورهای DNS خاصی که توسط IRNIC یا نمایندگان آن مدیریت می‌شوند، نگهداری می‌گردد. این سرورها خود بخشی از زیرساخت جهانی DNS هستند.

سؤال ۸: تفاوت Public DNS و Private DNS چیست؟

Public DNS (DNS عمومی): این سرویس ها توسط شرکت های بزرگ (مانند Google, Cloudflare) یا ISPها ارائه می‌شوند و برای عموم مردم در دسترس هستند. هدف اصلی آن‌ها ارائه خدمات DNS سریع، قابل اطمینان و اغلب با تمرکز بر حریم خصوصی است.

Private DNS (DNS خصوصی): این سرویس ها معمولاً در داخل یک شبکه محلی (LAN) سازمان یا توسط ISP به صورت سفارشی برای مشتریان خاص راه اندازی می شوند. Private DNS اغلب قابلیت های پیشرفته تری مانند فیلترینگ محتوا، مسدودسازی وب سایت های خاص، سیاست های امنیتی سفارشی، و گزارش دهی دقیق تر را ارائه می دهد. این سرویس ها معمولاً برای استفاده سازمانی یا خانگی با نیازهای خاص طراحی شده‌اند.

منابع و مراجع

برای اطلاعات بیشتر و درک عمیق‌تر موضوعات مطرح شده در این آموزش (راهنمای جامع و تخصصی)، مطالعه منابع تخصصی زیر توصیه میشود:

RFC 1034: Domain Names – Concepts and Facilities

RFC 1035: Domain Names – Implementation and Specification

RFC 8484: DNS Queries over HTTPS (DoH)

RFC 7858: DNS over TLS (DoT)

RFC 4033, 4034, 4035: DNS Security Extensions (DNSSEC)

RFC 6891: EDNS0: Extension Mechanisms for DNS

IANA Root Zone Database: اطلاعات مربوط به سرورهای ریشه DNS. (Root-Anchored Zone)

ICANN (Internet Corporation for Assigned Names and Numbers): منابع و اطلاعات مربوط به مدیریت نام های دامنه.

Cloudflare Learning Center: مقالات و توضیحات مفید در مورد DNS و موضوعات مرتبط با شبکه.

RFC 8483: DNS over Dedicated TLS Connections (DoT)

RFC 9250: DNS over Dedicated QUIC Connections (DoQ)

نویسنده: تیم محتوای فنی سئو ایران