DNS یا همون دفترچه­ تلفن اینترنت، یک سرویس ساده برای تبدیل آدرس­‌هایی مثل google.com به یک آدرس IP هست. در دنیای کامپیوتر همه ­چیز با اعداد انجام میشه و داستان سرویس نام­‌گذاری فقط برای این بوده که یاد آوری IP ها برای انسان سخته. برای مثال در زبان ­های برنامه‌نویسی با مفهوم متغیرها (Variables) رو به رو هستیم، مثلا متغیر a برابر میشه با مقدار عددی 2. کامپایلر و یا مفسر زبان­ برنامه‌نویسی در واقع با آدرسی در memory شما سر و کار داره و متوجه متغیر a نیست. به همین صورت در شبکه‌های کامپیوتری هم ما نیاز به این سازوکار داریم که این رو DNS یا همون Domain Name Service انجام میده.

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

حملات و روش‌­های جمع ­آوری اطلاعات زیادی در حوزه DNS کشف­ و مورد استفاده قرار گرفته. تعداد زیادی ابزار و چهارچوب‌­های کدباز (Open Source) در سطح اینترنت موجود هستن و اغلب بدونه نیاز به آگاهی از زیرساخت DNS میشه از اون‌ها استفاده کرد. اما هدف از این پست آگاهی نسبت به زیرساخت و سازوکار حملات هست و نه صرفا استفاده از ابزارها. برای درک بهتر حملات مرتبط با یک سرویس، آگاهی از سازوکار اون سرویس خیلی به روند آشنایی سرعت می‌­بخشه. پس در اولین قدم باهم بررسی می‌کنیم که سرویس DNS چطوری کار میکنه؟

---

درک ساختار DNS

وقتی می‌خواهیم وارد وب‌سایتی بشیم، باید آدرس Web Server اون رو بدونیم. آدرس Web Server با یک IP مشخص میشه. اما به خاطر سپردن IP، دشوار هستش. می­تونیم به جای IP، از نام‌دامنه (Domain Name) استفاده کنیم (برای هر آدرس IP یک (یا چند) نام‌دامنه در نظر گرفته شده‌). مثلا آدرس IP وب سایت گوگل، 179.201.14.2 هست.

در DNS تمامی آدرس‌های اینترنت درون پایگاه­‌های‌داده (Databases) توزیع شده‌ای هستن که هیچ تمرکزی روی نقطه‌ای خاص از شبکه ندارن. روش ترجمه نام به این صورت هست که، وقتی یک نرم ­افزار (Application) مجبور هست برای یک ارتباط، معادل IP از یک ماشین با نام‌دامنه‌­ای مثل google.com رو بدست بیاره، قبل از هر کاری یک تابع کتابخانه‌ای رو فراخوانی می­کنه که به این تابع، تحلیل‌گر نام (Name Resolver) گفته میشه.

تابع تحلیل‌گر، نام دامنه ای رو که باید ترجمه بشه، به عنوان پارامتر ورودی می­گیره و بعد یک بسته درخواست (Query Packet) از نوع UDP تولید می‌­کنه و به یک DNS server (که به صورت پیش فرض مشخص شده) ارسال می‌کنه. همه ماشین‌ ها، حداقل باید یک IP از یک DNS Server رو داشته باشن. این سرویس‌دهنده بعد از جستجو، آدرس IP معادل با نام‌دامنه مذکور رو برمی­‌گردونه. تابع تحلیل‌­گر نام هم اون رو به نرم‌­افزار مورد نظر تحویل میده. با پیدا شدن آدرس IP، نرم افزار میتونه به کار خودش ادامه بده.

مراحل ترجمه نام ­دامنه به IP توسط تابع تحلیل­‌گر (Name Resolver)

تابع تحلیل­گر، قبل از ارسال درخواست به DNS Server، برای ترجمه نام‌دامنه به ترتیب به دو منبع دیگه مراجعه می‌­کنه، که اولویت اون­‌ها به این صورت هست:

---

فایل Hosts

اولین منبع که تابع تحلیل­گر به اون مراجعه می­کنه فایل Hosts هست. این فایل میتونه شامل لیستی از آدرس های IP باشه که برابر با نام‌دامنه‌ای قرار گرفتن. این فایل رو میشه به سادگی ویرایش کرد. مسیر (Directory) این فایل در سیستم عامل های مختلف به این صورت هستش:

یک نمومه از فایل Hosts رو در زیر می­‌بینیم. با این فایل hosts زمانی که کاربر localhost یا loopback رو وارد می­کنه، تابع تحلیل‌­گر متوجه میشه که باید درخواست رو به IP خودِ ماشین که 127.0.0.1 هست ترجمه کنه.

127.0.0.1  localhost loopback
::1        localhost

از کاربردهای دیگه این فایل که شاید قبلا استفاده کرده باشید، بستن تبلیغات  در نرم‌افزارهای مختلف هست. برای مثال اگه چند خط زیر رو به فایل hosts خودمون اضافه کنیم، برنامه Spotify برای نشون دادن تبلیغ به 127.0.0.1 درخواست میده که طبیعتا پاسخی دریافت نمی‌کنه و در نتیجه خبری از تبلیغات نیست.

127.0.0.1	www.googleadservices.com
127.0.0.1	open.spotify.com

---

پایگاه‌داده‌ موقتی (DNS Cache)

تابع تحلیل­‌گر بعد از فایل Hosts به Cache DNS مراجعه می­کنه و اون رو مورد بررسی قرار میده. DNS Cache یک پایگاه‌داده (Database) موقت هست که سیستم ­عامل اون رو ذخیره می­کنه. این پایگاه شامل تمامی فعالیت‌های تابع تحلیل­‌گر هست. یک نمونه از DNS Cache رو در زیر می­بینیم:

در بالا ستون Time To Live (TTL) رو مشاهده می­‌کنیم. هر سطر (Record) در DNS Cache یک زمان استفاده داره. مثلا در بالا دامنه forums.suse.com مقدار 6139 رو در TTL خودش داره و این به این معنی­ هست که بعد از 6139 ثانیه (از اجرای دستور)، این سطر از DNS Cache به کلی پاک میشه.

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

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

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

هم­چنین برای از بین بردن تمامی سطرها در DNS Cache یا به اصلاح flush کردن اون، باید از دستورات زیر استفاده کنیم:

برای جزئیات بیشتر در این زمینه می­تونید به این لینک مراجعه کنید.

---

سرور DNS

تابع تحلیل‌­گر بعد از تلاش برای ترجمه نام‌دامنه به صورت محلی (Local)، اگه قادر به ترجمه نام‌­دامنه نبود مجبور به ارتباط با DNS Server میشه. پس تابع یک بسته درخواستی (Query Packet) به صورت UDP تشکیل میده و به DNS Server ارسال می­کنه و منتظر بسته دریافتی (Response Packet) می­مونه. تا IP مورد نظر رو بگیره.

آدرس IP سرور DNS در سیستم‌عامل‌هایی مثل Linux و FreeBSD تو فایل /etc/resolv.conf قرار داره. این فایل به صورت متن ساده (Plain-Text) در دسترس هست و به راحتی میشه اون رو ویرایش کرد. در زیر نمونه‌­ای از این فایل رو می­‌بینیم، اولویت سطرها در این فایل اهمیت داره، سطرها به ترتیب مورد استفاده تابع تحلیل­‌گر قرار می­‌گیره و فقط درصورتی که Server اول در سرویس‌دهی ناتوان باشه تابع به Server دوم مراجعه می­کنه.

nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 9.9.9.10

در Microsoft Windows برای تغییر DNS Server میشه از طریق PowerShell با دستور Set-DnsClientServerAddress این کار رو انجام داد.

Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses ("1.1.1.1","8.8.8.8")

---

---

DNS Zone چیست؟

DNS از یک ساختار سلسله‌مراتبی برای سیستم نام‌­گذاری استفاده می­کنه. با توجه به این ماهیت سلسله‌مراتبی، چندین ماشین می­تونن دارای اسامی یکسانی بر روی یک شبکه باشن و هیچگونه نگرانی ناشی از عدم ارسال پیام‌­ها وجود نخواهد داشت. برای مثال نام cloudflare میتونه در چندین Zone مختلف استفاده بشه، مثلا cloudflare.org و cloudflare.com که در اینجا .com و .org به عنوان Zone یاد میشن.

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

DDNS Zone میتونه شامل چند زیردامنه (subdomain) باشه و هر DNS Server هم میتونه شامل چند DNS Zone باشه (DNS Zone ها لزوما به صورت فیزیکی از هم جدا نمی­شن و یک سرور میتونه چند Zone رو شامل بشه). در مثال زیر 4 دامنه رو فرض کنیم:

حالا فرض کنیم که بلاگ یک وب­‌سایت کاملا مستقل هستش و نیاز به مدیریت جداگانه داره، اما صفحه پشتیبانی و انجمن با cloudflare.com به صورت مستقیم در ارتباط هستن و نیاز به مدیریت جداگانه‌ای ندارن. پس همه اون‌­ها رو در یک Zone و بلاگ رو در یک Zone جداگانه قرار میدیم.

---

انواع مختلف سرورهای DNS

تمام DNS Server ها در یکی از چهار دسته زیر قرار میگیرن، این چهار دسته باهم در عملیات ترجمه نام دامنه همکاری دارن:

سرور Recursive (aka DNS Recursor)

سرور ترجمه بازگشتی (Recursive Resolver) اولین ایستگاه یک بسته درخواستی DNS هست. وقتی DNS Recursor درخواست ترجمه (Query Packet) رو دریافت می­کنه مثل یک Client، اول از همه تو فایل Hosts و بعد پایگاه ­داده DNS Cache خودش به دنبال پاسخ می‌گرده. اگه نتونست پاسخ رو پیدا کنه، شروع به ارتباط با دیگر سرورهای DNS می­کنه تا بتونه پاسخگوی درخواست باشه.

برای مثال در زیر، روند ترجمه نام ­دامنه www.globomantics.com رو می‌بینیم.

در ابتدا Recursive DNS Server با یکی از سیزده DNS Server ریشه (root) ارتباط برقرار می‌کنه، سرور root با توجه به نام ­دامنه درخواستی، آدرس TLD DNS Server مرتبط (که در اینجا com هست)، رو به سرور Recursive می­ده. بعد سرور Recursive بسته درخواستی (Query Packet) حاوی نام‌­دامنه مورد نظر رو به com DNS Server ارسال می­کنه. سرور TLD هم آدرس سرور Authoritative مرتبط با نام‌دامنه، که در این مثال globomantics.com DNS Server هست رو به Recursive DNS Server میده. تو این مرحله سرور Recursive با globomantics.com DNS Server ارتباط برقرار میکنه. در بیشتر مواقع این آخرین مرحله برای پیدا کردن آدرس IP مربوط به نام‌­دامنه هست. در اینجا سرور Authoritative، آدرس IP مرتبط با نام‌­دامنه www.globomantics.com رو به سرور DNS محلی ارسال میکنه. حالا سرور Recursive، آدرس IP رو به ماشین درخواست­ دهنده تحت یک بسته DNS از نوع واکنشی (Response) ارسال می­کنه و اون رو در پایگاه DNS Cache خودش ذخیره می­‌کنه تا درخواست­ های بعدی مربوط به نام‌دامنه مشابه رو با سرعت بیشتری پاسخ بده و نیاز به طی این مراحل نباشه. استفاده از UDP در DNS باعث شده که تمامی مراحل این عملیات در زمان کوتاهی انجام بشه.

در تصویر زیر یک نمای درختی از DNS Server ها را می‌­بینید.

---

سرور Root

حالا سوال مطرح میشه که سرور Recursive، آدرس Root DNS Server رو از کجا میاره؟

Root Nameserver یا Root Hints، سرورهای ریشه هستن که تعداد سرویس دهنده­‌های اون­ 13 تا هست که توسط 12 سازمان مستقل در دنیا اداره میشن (تمامی این سرویس ها تحت نظارت ICANN هستن). آدرس این سرورها به صورت پیش‌­فرض در سیستم‌عامل سرور به صورت متن ­ساده (Plain-Text) موجود هست و با ویرایش‌گر متن قابل تغییر هست.

مسیر این فایل در سیستم عامل های مختلف به این صورت هستش:

سرورهای ریشه فقط درخواست­ های بازگشتی (Recursive Query) رو قبول میکنن (جلوتر به ساختار درخواست های مختلف می‌پردازیم)، و درخواست دهنده (سرور Recursive) رو به یک سرور TLD راهنمایی می­کنن.

توجه داشته باشیم که 13 سرور ریشه به این معنی نیست که فقط 13 سرور (ماشین فیزیکی) در دنیا وجود داره. چندین نسخه از هر سرویس در سرتاسر دنیا وجود دارد که با استفاده از Anycast Routing سریع‌ترین سرویس رو به شما میدن.

---

سرور TLD

یک TLD Nameserver شامل تمام دامنه‌هایی میشه که از یک پسوند مثل .com یا .org استفاده میکنن. همون­‌طور که در قسمت ­قبل اشاره کردیم سرور ریشه، سرور DNS محلی رو به سرور TLD مرتبط راهنمایی میکنه. سپس DNS Server محلی یک بسته درخواستی (Query Packet) به سرور TLD ارسال می­کنه.

سرور TLD هم مثل سرور Root فقط بسته­‌ژهای بازگشتی (Recursive Query) رو قبول میکنن و در پاسخ، سرور Recursive رو به یک سرور Authoritative راهنمایی میکنن.

سرور های TLD توسط بنیاد IANA کنترل میشن. IANA یا همان آیانا نهادی تحت مالکیت ICANN هست.

IANA، سرورهای TLD رو به دو دسته تقسیم میکنه:

• سرورهای عمومی که به کشور یا منطقه‌ای مربوط نمیشن مثل: .com, .gov, .org, .net
• سرورهای کشوری که شامل دامنه‌های مرتبط با یک کشور یا یک منطقه میشن، مثل: .ir, .de, .tv

---

سرور Authoritative

همون­‌طور که در قسمت قبل دیدیم سرور TLD، یک پاسخ ارجاع ­دهده (redirect) به یک سرور Authoritative، به سرور Recursive میفرسته. سرور Authoritative معمولا آخرین قدم برای برای پیدا کردن IP مرتبط با نام­ دامنه هست. سرور Authoritative شامل تمام زیردامنه‌­های (subdomains) مرتبط با یک دامنه (مثلا google.com) میشه. هرچند مانند مثال قبلی ممکن هست که پاسخ این سرور یک ارجاع (redirect) به یک سرور DNS دیگه باشه که در مثال قبلی blog.cloudflare.com بود.

---

---

بررسی عمیق تر

در این قسمت می­خواهیم بسته­ های DNS رو مورد بررسی قرار بدیم. در اغلب موارد بهترین راه برای مطالعه یک پروتکل، مطالعه RFC اون پروتکل هست. DNS در طی عصر اینترنت بارها تغییر کرده و RFC های مختلفی براش ثبت شدن برای مثال در اینجا میتونیم یک نسخه از RFC2929 پروتکل DNS رو مطالعه کنیم.

---

ساختار بسته های DNS

تمامی بسته­ های DNS ساختاری شبیه به تصویر زیر دارن:

Header در بسته DNS، نوع بسته و بخش­ های اون رو توصیف میکنه. در ادامه بخش‌های Question و Answer رو داریم. دقت کنید که قسمت­ های با رنگ زرد میتونه تو بسته نباشه ولی یک بسته DNS حداقل Header و Question رو نیاز داره تا یک بسته معتبر شناخته بشه.

---

بررسی هدر (Header)

همون­‌طور که خوندیم header در بسته، نوع بسته رو نشون میده. ساختار header بسته DNS به این شکل هست:

ID – 16bit:

یک ماشین ممکن هست در لحظه چند درخواست در حال بررسی باشه.

درون این فیلد یک شناسه قرار میگره. این شناسه توسط ماشین درخواست‌دهنده ساخته میشه. این مقدار در سرور DNS ذخیره میشه و در بسته پاسخ (Response) هم همون مقدار درج میشه تا ماشین درخواست‌دهنده بتونه تشخیص بده که کدوم پاسخ (Response) برای کدوم درخواست (Query) هست.

این فیلد به نام TXID هم شناخته میشه.

QR – 1bit:

درون این فیلد نوع بسته مشخص میشه (درخواست (Query) یا پاسخ (Response)). معنی و مفهوم مقادیر به شرح زیر هست:

• صفر: بسته از نوع درخواستی (Query) است.
• یک: بسته از نوع پاسخ (Response) است.

Opcode – 4bit:

این فیلد چهار بیتی مشخص‌کننده­ نوع بسته درخواست هست. مقادیر این فیلد به شرح زیر هست:

• صفر: بسته یک درخواست استاندارد و ساده (Standard query).
• یک: بسته درخواست معکوس (Inverse query). به این معنی که درخواست‌دهنده قصد داره نام‌دامنه رو با توجه به آدرس IP پیدا کنه.
• دو: یعنی درخواست‌دهنده قصد داره وضعیت سرور رو چک کنه (Server status request).
• چهار: این مقدار به این معنی هست که یک سرور DNS اصلی (Master)، به DNS فرعی (Slave) خودش هشدار میده که اطلاعات عوض شده و باید خودش رو بروزرسانی کند (Notify).
• پنج: به این معنی هست که سرور DNS قصد بروزرسانی داره (Update) و به اصطلاح zone transfer شکل می‌گیره.
• سه و شش تا پانزده: بدون کاربرد هستش و برای استفاده ­های احتمالی رزرو شده (البته در RFCهای جدید تر از این مقادیر استفاده شده).

AA – 1bit:

این فیلد مشخص‌کننده نوع پاسخ (Answer) هستش و مقادیر اون به شرح زیر هست:

• یک: به این معنی است که پاسخ Authoritative است.
• صفر: یعنی non-Authoritative است.

کمی جلوتر این مفاهیم رو توضیح میدیم.

TC – 1bit:

این مقدار مشخص کننده این هست که آیا بسته کوتاه شده یا خیر. وقتی که حجم بسته درخواستی بیشتر از حجم پشتیبانی شده باشه مقدار این فیلد یک میشه. در TCP ما محدودیتی برای حجم نداریم ولی در UDP حداکثر مقدار 512 بایت هستش. در این مواقع ممکن هست که Client نیاز به یک TCP Session داشته باشه.

RD – 1bit:

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

• صفر: ارتباطی با دیگر سرورها صورت نگرفته (Recursion not desired).
• یک: برای ترجمه با دیگر سرورها ارتباط صورت گرفته (Recursion desired).

RA – 1bit:

مقدار این فیلد مشخص کننده این هست که آیا سرور از بسته­ های درخواست بازگشتی (Recursive query) پشتیبانی میکنه یا نه. که مشخصا مقدار یک به معنی پشتیبانی کردن از این نوع درخواست هست.

Z – 3bit:

 این فیلد بی­ استفاده هست و برای استفاده ­های احتمالی رزرو شده، و مقدار اون همیشه صفر هستش.

RCODE – 4bit:

این فیلد برای خطایابی در نظر گرفته شده. به این صورت که در بسته درخواستی مقدار اون صفر تعیین میشه و سرور پاسخ دهنده اون رو با توجه به وضعیت تغییر میده. مقادیر استفاده شده در این فیلد به شرح زیر هست:

• صفر: اگر بدون هیچ مشکلی درخواست پاسخ داده بشه این مقدار صفر باقی میمونه.
• یک: به این معنی هست که یک خطای ساختاری رخ داده (Format Error) و سرور نمیتونه بسته درخواست رو بخونه.
• دو: این مقدار یعنی سرور مشکل داره و قادر به پاسخ­گویی نیست (Server Failure).
• سه: به معنی این هست که نام ­دامنه وجود ندارد (Name Error).
• چهار: نوع بسته درخواستی توسط سرور پشتیبانی نمیشه(Not Implemented).
• پنج: به این معنی هست که سرور درخواست رو رد کرده که اغلب به علت سیاست­ های امنیتی رخ میده (Refused).

CDCount – 16bit:

این فیلد تعداد درخواست های بسته رو مشخص میکنه.

ANCount – 16bit:

این فیلد تعداد پاسخ های موجود در بسته رو مشخص میکنه.

NSCount – 16bit:

مشخص کننده تعداد پاسخ های authoritative در بسته هست.

ARCount – 16bit:

 تعداد پاسخ های فرعی در بسته رو مشخص میکنه.

---

رکوردهای DNS

DNS سرور فقط وظیفه تبدیل نام دامنه به آدرس IP و بالاعکس رو نداره، مثلا دفترچه تلفن موبایل شما میتونه بیشتر از شماره تلفن و اسم یک شخص رو ذخیره کنه، مثل محل کار یا Email. سرور DNS هم به همین صورت عمل میکنه. در سرورهای Authoritative ما میتونیم اطلاعات بیشتری رو مرتبط با نام دامنه ذخیره کنیم. هر کدوم از این اطلاعات به نسبت نوعشون یک برچسب میخورن که به اون ها Record گفته میشه (همچنین به Zone file هم معروف هستن). این Recordها در فایل متن ساده ای (Plain-text) به اسم Zone فایل ذخیره میشن و هر کدوم TTL مختص خودشون رو دارن. در ادامه انواع Recordها رو بررسی میکنیم.

A Record (ID : 1):

این رکورد برای ثبت IPv4 مربوط به دامنه هست.

AAAA Record (ID : 28):

این رکورد برای ثبت IPv6 استفاده میشه

MX Record (ID : 15):

این رکورد جهت ثبت سرویس E-mailing مربوط به دامنه هست. این رکورد یک ‍پارامتر دیگه داره برای الویت بندی بین سرورها (درصورت وجود چند Mail Server).

CNAME Record (ID : 5):

این رکورد وظیفه ارجاع (Forward) رو داره. به این معنی که یک نام دامنه رو به نام دامنه دیگه ای ارجاع میده ( کاربردی مثل Redirect).

NS Record (ID : 2):

این رکورد برای نگه داری نام دامنه Authoritative DNS Server هست. یعنی سروری که وظیفه پاسخ گویی به درخواست های DNS مربوط به این دامنه رو داره. از این رکورد معمولا دو مقدار هست و الویت بندی وجود داره. درصورتی که یکی از اون ها پاسخگو نباشه به بعدی مراجعه میشه.

TXT Record (ID : 16):

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

SOA Record (ID : 6):

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

SRV Record (ID : 33):

این رکورد جهت ثبت Host و Port برای سرویس های مختلف در اون حوزه هست. مثلا سرویس VoIP یا Load Balancing و یا Instant Messaging.

PTR Record (ID : 12):

این رکورد عکس عمل A Record رو انجام میده. یعنی آدرس IP رو به نام دامنه تبدیل میکنه. این رکورد در Reverse Lookup Zone استفاده میشه.

DNAME Record (ID : 39):

این رکورد عملی شبیه به CNAME Record رو انجام میده و تفاوت در اینجاست که این رکورد تمام زیردامنه‌های مربوط رو هم ارجاع میکنه. برای مثلا در CNAME اگه exm.com رو به site.com ارجاع بدیم فقط دامنه exm.com ارجاع داده میشه. ولی در DNAME همین کار باعث میشه تمام زیردامنه های exm.com مثل blog.exm.com هم به site.com ارجاع داده بشه.

LOC Record (ID : 29):

مشخص‌کننده موقعیت جغرافیایی یک دامنه هست.

RP Record (ID : 17):

اطلاعاتی درباره شخص یا اشخاص مدیر دامنه رو توی خودش نگه میداره(مثل Email).

CERT Record (ID : 37):

این رکورد هم برای نگهداری اعتبارنامه هاست ( مثلا PGP, SPKI, PKIX).

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

https://en.wikipedia.org/wiki/List_of_DNS_record_types

---

پاسخ‌های Authoritative و non-Authoritative

به طور خلاصه پاسخ‌هایی که به‌طور مستقیم از سرور Recursive بیاد و عملیات پرسش و پاسخ از سرور های دیگه اتفاق نیوفته به عنوان Authoritative response شناخته میشه. و اگه پاسخ طی پرسش و پاسخ از سرور های دیگه حاصل بهش به عنوان non-Authoritative response شناخته میشه.

در بسته زیر می‌تونیم به صورت واضح مشاهده کنیم:

در فیلد Answer RRS تعداد پاسخ‌های پیدا شده که 5 تا هست مشخص شده و در فیلد Authority RRS عدد صفر قرار گرفته به این معنی که هیچ‌کدوم از پاسخ‌ها از در سرور محلی نبوده.

همون طور که در بخش های قبل باهم خوندیم، سرور های Authoritative سرور‌هایی هستن که وظیفه ترجمه نام‌های دامنه خودشون رو دارن. که حداقل از این سرور برای یک وب سایت دو تا وجود داره، که یکی از اون ها اصلی (Master) هست و دومی به عنوان سرویس عمومی فعالیت میکنه و خودش رو از روی سرور اصلی بروزرسانی میکنه.

یک مورد امنیتی مهم در این جا وجود داره. فرض کنید شما به نحوی اطلاع دارید که یک شرکت از یک سرور Recursive خصوصی برای خودش استفاده میکنه. و شما به اون سرور دسترسی دارید (یعنی میتونید به اون سرور درخواست DNS بدین).

شما به عنوان یک آزمون گر میتونید درخواست های متفاوتی برای این سرور بفرستید. مثلا لیست دامنه های مربوط به سرویس بروزرسانی Firewall های مختف.

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

برای جلوگیری از این اتفاق میشه مقدار Authority RSS رو همیشه ثابت فرستاد (با توجه به اهمیت پایین اون برای کاربر معتبر).

---

---

در پست های آینده سعی میکنم مطالبی رو از بررسی امنیتی این پروتکل بنویسم همچنین به مطالبی مثل DNSSec و حملات مختلف که تو بستر این پروتکل انجام میشه بپردازم.