مفاهیم DNS و انواع سرورهای آن – راهنمای جامع

DNS یا سیستم نام دامنه غالباً بخش بسیار دشواری از یادگیری چگونگی پیکربندی وب‌سایت‌ها و سرورها محسوب می‌شود. درک طرز کار DNS به شما کمک می‌کند که مشکلات پیکربندی دسترسی به وب‌سایت‌ها را رفع کنید و همچنین درک شما از آن چه در پشت پرده رخ می‌دهد را افزایش می‌دهد. پیش از آن که وارد مبحث تنظیم سرورها برای resolve کردن دامنه یا راه‌اندازی دامنه در پنل کنترل بکنیم، به معرفی برخی مفاهیم ابتدایی در مورد طرز کار همه این فناوری‌ها می‌پردازیم.

اصطلاحات مربوط به دامنه

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

سیستم نام دامنه (Domain Name System)

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

نام دامنه (Domain Name)

نام دامنه یک نام آشنا برای انسان است که از آن برای اشاره به یک منبع اینترنتی استفاده می‌کنیم. برای مثال «google.com» یک نام دامنه است. برخی افراد خواهند گفت که دامنه در واقع بخش «google» است؛ اما می‌توانیم به ترکیب این دو بخش نیز به صورت کلی به عنوان نام دامنه اشاره کنیم.

URL به صورت «google.com» به سرورهایی که تحت تملک گوگل هستند اشاره می‌کند. سیستم نام دامنه به ما اجازه می‌دهد که وقتی «google.com» را در مرورگرهای خود وارد می‌کنیم، به سرورهای گوگل برسیم.

آدرس آی‌پی (IP Address)

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

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

دامنه سطح بالا (Top-Level Domain)

یک دامنه سطح بالا (TLD) عمومی‌ترین بخش دامنه است. دامنه سطح بالا نخستین بخش از سمت راست در نام دامنه محسوب می‌شود که به وسیله نقطه از بخش‌های دیگر جدا می‌شود. نمونه‌هایی از دامنه‌های سطح بالا به صورت «com»، «net»، «org»، «gov»، «edu» و «io» هستند.

دامنه‌های سطح بالا در بخش فوقانی سلسله مراتب اصطلاح‌های مرتبط با نام‌های دامنه قرار دارند. طرف‌های معینی، کنترل مدیریت دامنه‌های سطح بالا از سوی ICANN (سازمان اینترنتی برای نام‌ها و شماره‌های واگذار شده) دریافت می‌کنند می‌شوند. این طرف‌ها می‌توانند نام‌های دامنه را تحت TLD معمولاً از طریق ثبت دامنه توزیع کنند.

میزبان‌ها (Hosts)

درون یک دامنه، مالک دامنه می‌تواند میزبان‌های مختلفی تعریف کند که به رایانه‌ها یا سرویس‌های مختلف از طریق دامنه اصلی (example.com) اشاره می‌کند. همچنین این بخش‌های مختلف از طریق تعریف میزبان مثلاً به صورت «www» قابل دسترسی هستند (www.example.com).

تعاریف دیگری از میزبان نیز تحت دامنه عمومی وجود دارد. برای مثال می‌توانید از طریق میزبان api امکان دسترسی به api خاصی را فراهم سازید (api.example.com) همچنین می‌توانید یک میزبان به نام ftp یا files تعریف کنید (ftp.example.com یا files.examples.com). نام‌های میزبان تا زمانی که برای هر دامنه منحصر به فرد هستند، می‌توانند با هر طولی تعریف شوند.

زیردامنه (Subdomain)

زیردامنه‌ها نیز اصطلاحی در ارتباط با میزبان (host) هستند. DNS به صورت سلسله مراتبی عمل می‌کند. یک TLD می‌تواند دامنه‌های زیادی زیر خودش داشته باشد. برای مثال هر دو دامنه google.com و Ubuntu.com زیر TLD به صورت com هستند. یک زیردامنه به دامنه‌ای اشاره دارد که بخشی از دامنه بزرگ‌تر است. در این مورد می‌توان گفت که Ubuntu.com زیردامنه com است. البته این بخش معمولاً صرفاً دامنه (SLD) یعنی دامنه سطح دوم (Second Layer Domain) نامیده می‌شود.

به طور مشابه هر دامنه‌ای می‌تواند زیردامنه‌هایی زیر خودش داشته باشد. این معنی دوم در مورد زیردامنه متداول‌تر است. برای نمونه دانشگاه شما می‌تواند برای هر بخش از دانشگاه، یک زیردامنه داشته باشد. برای نمونه دانشکده تاریخ می‌تواند زیردامنه‌ای به صورت «www.history.school.edu» داشته باشد.

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

نام دامنه جامع‌الشرایط (Fully Qualified Domain Name)

یک نام دامنه جامع‌الشرایط که غالباً FQDN نامیده می‌شود، در واقع یک نام دامنه مستقل است. دامنه‌ها در سیستم DNS می‌توانند نسبت به هم دیگر نسبی باشند و از این رو می‌توانند تا حدی ابهام‌برانگیز باشند. یک FQDN نامی مستقل است که موقعیت یک جزء شبکه را در رابطه با ریشه مطلق در سیستم نام دامنه تعیین می‌کند.

این بدان معنی است که FQDN هر یک از دامنه‌های والدی را که در TLD قرار دارد، مشخص می‌کند. یک FQND صحیح با یک نقطه به پایان می‌رسد که ریشه سلسله مراتب DNS را مشخص می‌سازد. نمونه‌ای از یک FQDN به صورت «mail.google.com.» است. در برخی موارد وقتی نرم‌افزارهای مختلف از شما FQDN را می‌خواهند، در واقع ذکر آن نقطه پایانی الزامی نیست؛ اما این نقطه پایانی بر اساس استانداردهای ICANN الزامی محسوب می‌شود.

سرور نام (Name Server)

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

سرورهای نام می‌توانند «معتبر» (authoritative) باشند، یعنی به کوئری‌هایی در مورد دامنه‌های تحت کنترل خود پاسخ بدهند. در غیر این صورت آن‌ها می‌توانند به سرورهای دیگر اشاره کنند یا رونوشت‌های کش شده‌ای از داده‌های سرورهای نام دیگر ارائه کنند.

فایل منطقه (Zone File)

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

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

رکوردها (Records)

رکوردها درون یک فایل منطقه نگهداری می‌شوند. رکورد در ساده‌ترین شکل خود اساساً یک نگاشت بین یک منبع و نام آن است. بدین ترتیب می‌توان نام یک دامنه را به آدرس IP نگاشت کرد، سرورهای نام را برای آن دامنه تعریف کرد، سرورهای mail را برای دامنه معین ساخت و مواردی از این دست.

DNS چگونه کار می‌کند؟

اینک که با برخی اصطلاح‌های ابتدایی DNS آشنا شدید، می‌توانیم طرز کار DNS را نیز توضیح دهیم.

سیستم DNS از منظر کلی بسیار ساده است؛ اما وقتی به جزییات نگاه می‌کنیم می‌بینیم که بسیار پیچیده است. با این حال در کل DNS زیرساخت کاملاً قابل اتکایی است که برای شکل‌گیری اینترنت، چنان که امروز می‌بینیم، جزئی کاملاً ضروری محسوب می‌شود.

سرورهای ریشه (Root Servers)

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

در حال حاضر 13 سرور ریشه عملیاتی وجود دارند. با این حال، با وجود هزاران درخواست resolve نام دامنه که هر لحظه ارسال می‌شوند، هر یک از این سرورها در واقع اقدام به بازتاب دادن آن درخواست می‌کنند. نکته جالب در مورد این تنظیمات آن است که هر یک از این سرورهای بازتاب‌دهنده، دارای آدرس IP مشترکی هستند. زمانی که درخواست‌ها به یک سرور ریشه مشخص ارسال می‌شوند، درخواست به نزدیک‌ترین سرور ریشه بازتابی مسیریابی می‌شود.

وظیفه این سرورهای ریشه این است که درخواست‌های اطلاعات را برای دامنه‌های سطح بالا مدیریت کنند. بنابراین اگر یک درخواست برای دامنه‌ای ارسال شود که یک سرور نام در سطوح پایین‌تر نتواند آن را resolve کند، برای آن دامنه یک کوئری به سرور ریشه ارسال می‌شود.

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

بنابراین اگر یک درخواست برای دامنه «www.wikipedia.org» به سرور ریشه ارسال شود، سرور ریشه نتیجه این کوئری را در رکوردهای خود ندارد. در این زمان سرور ریشه فایل‌های منطقه خود را بررسی می‌کند تا مورد مطابقی برای «www.wikipedia.org» بیابد؛ ولی چنین چیزی نخواهد یافت.

در عوض سرور ریشه رکوردی برای TLD مربوط به «org» می‌یابد و آدرس سرور نام مسئول آدرس‌های org را به درخواست‌کننده بازمی‌گرداند.

سرورهای TLD

در این زمان درخواست‌کننده، یک درخواست جدید برای آدرس IP که از سرور ریشه دریافت کرده، ارسال می‌کند. این آدرس مسئول دامنه‌های سطح بالای مورد تقاضا است.

بنابراین در تداوم مثال قبلی، درخواست‌کننده تقاضایی برای سرور نام مسئول دامنه‌های org می‌فرستد تا ببیند آیا این سرور نام اطلاعاتی در مورد محل «www.wikipedia.org» دارد یا نه. در این مورد نیز سرور به رکوردهای فایل منطقه خود نگاه می‌کند و این رکورد را در فایل‌های خود نمی‌یابد.

با این حال سرور نام رکوردی را می‌یابد که آدرس IP سرور نام مسئول برای www.wikipedia.org را دارد. بدین ترتیب ما یک گام دیگر به پاسخ نزدیک‌تر شده‌ایم.

سرورهای نام سطح دامنه

در این زمان درخواست‌کننده آدرس IP توانسته است آن سرور نام که مسئول دانستن اطلاعاتی در مورد آدرس IP منبع مورد تقاضایش است را به دست آورد. بنابراین یک درخواست جدید به سرور نام مورد بحث ارسال می‌کند و یک بار دیگر از آن می‌خواهد که دامنه www.wikipedia.org را resolve کند.

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

سرور نام Resolving چیست؟

در سناریوی فوق ما از یک درخواست‌کننده نام بردیم. اما معنی درخواست‌کننده در این موقعیت چیست؟

تقریباً در همه موارد، منظور از درخواست‌کننده چیزی است که آن را سرور نام resolving می‌نامیم. سرور نام resolving برای پرسش از سرورهای دیگر پیکربندی شده است. این سرور اساساً یک میانجی بین کاربر و سرورهای بالاتر است که نتیجه کوئری‌های قبلی را کش می‌کند تا بتواند در موارد پرسش‌های بعدی سریع‌تر پاسخ دهد و از طرف دیگر آدرس‌های سرورهای ریشه را می‌داند تا بتواند درخواست‌هایی را که از قبل نمی‌داند resolve کند.

یک کاربر معمولاً چند سرور resolving دارد که در سیستم عاملش تنظیم شده‌اند. سرورهای نام resolving معمولاً از سوی ISP یا سازمان‌های دیگر ارائه شده‌اند. برای مثال گوگل سرورهای resolving DNS خود را ارائه کرده است و می‌توانید به آن‌ها کوئری بزنید. این سرورها را می‌توانید به صورت دستی یا خودکار روی رایانه خود پیکربندی کنید.

زمانی که یک URL را در نوار آدرس مرورگر خود وارد می‌کنید، رایانه شما ابتدا می‌گردد تا ببیند که آیا این آدرس را در کش محلی ذخیره کرده است یا نه. سپس فایل hosts و چند مکان دیگر را روی رایانه بررسی می‌کند. سپس درخواستی به سرورهای نام resolving می‌فرستد و منتظر می‌ماند تا آدرس IP منبع را دریافت کند.

سپس سرورهای نام resolving کش مرورگر کاربر را بررسی می‌کنند. اگر پاسخی نیافتند وارد مراحلی می‌شوند که در بخش قبل اشاره کردیم. سرورهای نام resolving اساساً فرایند درخواست را برای کاربر نهایی فشرده می‌کنند. بدین ترتیب کلاینت تنها کافی است سرورهای نام resolving را بشناسد و می‌تواند مطمئن باشد که این سرورها پاسخ نهایی را برای او یافته و تحویل می‌دهند.

• مطلب پیشنهادی برای مطالعه: نحوه تغییر DNS در اندروید — راهنمای کاربردی

فایل‌های منطقه

در فرایند فوق به ایده «فایل‌های منطقه» و «رکوردها» اشاره کردیم.

فایل‌های منطقه همان روشی هستند که سرورهای نام به وسیله آن اطلاعاتی در مورد دامنه‌هایی که در موردشان اطلاع دارند ذخیره می‌کنند. هر دامنه که یک سرور نام، آن را می‌شناسد در فایل منطقه ذخیره می‌شود. اغلب درخواست‌هایی که برای یک سرور نام معمولی می‌آید، چیزهایی نیستند که سرور آن‌ها را در فایل منطقه خود داشته باشد.

اما سرورهای نام طوری پیکربندی شده‌اند که مانند سرور نام resolving کوئری‌های بازگشتی اجرا کنند و پاسخ را یافته و بازگشت دهند. در غیر این صورت آن‌ها به طرف درخواست‌کننده اعلام می‌کنند که کجا باید به دنبال پاسخ بگردد.

هر چه یک سرور نام، فایل‌های منطقه بیشتری داشته باشد، می‌تواند به درخواست‌های بیشتری به صورت معتبر پاسخ دهد.

یک فایل منطقه در واقع یک منطقه DNS را توضیح می‌دهند که اساساً زیرمجموعه‌ای از سیستم نامگذاری کلی DNS است. این فایل برای پیکربندی تنها یک دامنه منفرد استفاده می‌شود. این فایل می‌تواند شامل چند رکورد باشد که منابع مورد نیاز برای دامنه مورد تقاضا را تعیین می‌کنند.

پارامتر ORIGIN$ در منطقه، پارامتری است که بالاترین سطح مجاز منطقه را به صورت پیش‌فرض تعیین می‌کند.

بنابراین اگر یک فایل منطقه برای پیکربندی دامنه «example.com» استفاده شود، این پارامتر ORIGIN$ را می‌توان به صورت .example.com تنظیم کرد.

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

به طور مشابه پارامتر TTL$ مقدار «time to live» را مشخص می‌سازد. این پارامتر اساساً یک تایمر است. یک سرور کش نام می‌تواند از نتایج کوئری‌های انجام یافته قبلی برای پاسخ دادن به سؤالاتی که هنوز مقدار TTL-شان به پایان نرسیده است، استفاده کند.

انواع رکورد

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

رکوردهای SOA

رکورد SOA به معنی «آغاز اعتبار» (Start of Authority) یک رکورد اجباری در همه فایل‌های منطقه است. این مورد باید نخستین رکورد واقعی در یک فایل منطقه باشد (گرچه ممکن است مقادیر ORIGIN$ یا TTL$ بالاتر از آن واقع شده باشند.) همچنین باید گفت که درک این رکورد نسبت به رکوردهای دیگر دشوارتر است.

رکورد آغاز اعتبار مانند زیر است:

domain.com.  IN SOA ns1.domain.com. admin.domain.com. (
                                            12083   ; serial number
                                            3h      ; refresh interval
                                            30m     ; retry interval
                                            3w      ; expiry period
                                            1h      ; negative TTL
)

در ادامه توضیح می‌دهیم که هر بخش مسئول چه چیزی است:

• .domain.com – این پارامتر ریشه منطقه است. این پارامتر تعیین می‌کند که فایل منطقه برای دامنه domain.com. است. در اغلب موارد می‌بینید که به جای این پارامتر @ جایگزین شده است که تنها یک اشاره‌گر است که جایگزین محتوای متغیر ORIGIN$ می‌شود که قبلاً توضیح دادیم.
• IN SOA - بخش IN به معنی اینترنت است (و در اغلب رکوردها وجود دارد). SOA نشان می‌دهد که این رکورد SOA است.
• .ns1.domain.com – این بخش سرور نام ارباب (master) اصلی این دامنه را تعیین می‌کند. سرورهای نام می‌توانند به صورت ارباب یا برده (slave) باشند و اگر سرور به صورت DNS دینامیک پیکربندی شده باشد، باید یک ارباب اصلی (primary master) نیز وجود داشته باشد. اگر DNS دینامیک تنظیم نشده باشد، در این صورت تنها یکی از انواع ارباب یا برده کفایت می‌کند.
• .admin.domain.com - این آدرس ایمیل مدیر منطقه است. در این آدرس ایمیل به جای کاراکتر @ یک نقطه (.) قرار می‌گیرد. اگر بخش نام آدرس ایمیل به طور معمول یک نقطه در خود داشته باشد در این پارامتر با یک / جایگزین می‌شوند. یعنی آدرس ایمیل «your.name@domain.com» به صورت «your\name.domain.com» درمی‌آید.
• 12083 – این شماره سری فایل منطقه است. هر زمان که یک فایل منطقه را ویرایش می‌کنید، باید این عدد را یک واحد افزایش دهید تا فایل منطقه به طور صحیحی انتشار یابد. سرورهای برده بررسی می‌کنند که آیا شماره سری سرور اصلی برای یک منطقه بزرگ‌تر از سری فایلی است که آن‌ها دارند یا نه. اگر چنین بود فایل منطقه جدید را درخواست می‌کنند و در غیر این صورت به ارائه فایل اصلی می‌پردازند.
• 3h – این بازه رفرش برای منطقه است. منظور از بازه رفرش مقدار زمانی است که سرورهای برده منتظر می‌مانند تا تغییراتی که در فایل منطقه ارباب ایجاد می‌شود را بررسی کنند.
• 30m – مقدار بازه تلاش مجدد برای این منطقه است. اگر سرور برده نتواند وقتی دوره رفرش تمام شد به سرور ارباب وصل شود، این مقدار زمان صبر می‌کند تا دوباره از سرور ارباب فایل منطقه را تقاضا کند.
• 3w – این زمان انقضا است. اگر یک سرور نام برده نتواند در طی این مقدار زمان به سرور ارباب وصل شود، پس از آن دیگر به عنوان یک منبع معتبر برای این منطقه پاسخی بازنمی‌گرداند.
• 1h – این مقدار زمانی است که سرور در صورت نیافتن نام مورد درخواست در این فایل یک خطای نام را کش می‌کند.

رکوردهای A و AAAA

هر دوی این رکوردها یک میزبان را به آدرس IP مربوطه نگاشت می‌کنند. رکورد A برای نگاشت یک میزبان به آدرس‌های IP به صورت Ipv4 استفاده می‌شود؛ در حالی که رکوردهای AAAA برای نگاشت میزبان‌ها به آدرس‌های IPv6 استفاده می‌شوند.قالب کلی این رکوردها به صورت زیر است:

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

بنابراین از آنجا که رکورد SOA یک سرور ارباب اصلی را در «ns1.domain.com» فراخوانی می‌کند، می‌توانیم این مقدار را به یک آدرس IP نگاشت کنیم، چون «ns1.domain.com» درون منطقه «ns1.domain.com» قرار دارد که این فایل آن را تعریف می‌کند. این رکورد می‌تواند چیزی شبیه زیر باشد:

ns1 IN A 111.222.111.222

توجه کنید که لازم نیست نام کامل را داشته باشیم. ما تنها میزبان را بدون FQDN ارائه می‌کنیم و سرور DNS باقی آن را بر اساس مقدار ORIGIN$ پر می‌کند. با این حال ما می‌توانیم کل FQDN را نیز به صورت زیر ارائه کنیم:

ns1.domain.com. IN A 111.222.111.222

در اغلب موارد این همان جایی است که وب‌سرور خود را به صورت www تعریف می‌کنیم:

www IN A 222.222.222.222

همچنین باید تعیین کنیم که دامنه اصلی به کجا resolve می‌شود. این کار به صورت زیر انجام می‌گیرد:

domain.com. IN A 222.222.222.222

می‌توانیم از @ برای ارجاع به دامنه اصلی نیز استفاده کنیم.

@ IN A 222.222.222.222

همچنین می‌توانیم هر چیزی که زیر این دامنه قرار می‌گیرد و صراحتاً تعریف نشده است را به این سرور تعریف کنیم:

* IN A 222.222.222.222

همه این‌ها علاوه بر رکوردهای A با رکوردهای AAAA نیز کار می‌کنند.

رکوردهای CNAME

رکوردهای CNAME یک نام مستعار (alias) برای نام کانونی سرور شما تعریف می‌کنند. برای نمونه ما می‌توانیم یک رکورد نام A داشته باشیم که میزبان «server1» را تعریف کند و سپس از «www» به عنوان نام مستعاری برای این میزبان استفاده کنیم:

server1 IN A 111.111.111.111
www IN CNAME server1

آگاه باشید که این نام‌های مستعار باعث کاهش اندکی در عملکرد سیستم می‌شوند، زیرا به یک کوئری اضافه در سرور نیاز دارند. در اغلب موارد همین نتیجه را می‌توان با استفاده از یک رکورد A یا AAAA اضافی به دست آورد.

یکی از مواردی که استفاده از رکورد CNAME توصیه می‌شود، زمانی است که می‌خواهیم یک نام مستعار برای منبعی خارج از منطقه کنونی تعریف کنیم.

رکوردهای MX

رکوردهای MX برای تعریف مبادله‌گران پستی استفاده می‌شوند که برای یک دامنه تعریف می‌شوند. بدین ترتیب پیام‌های ایمیل می‌توانند به طرز صحیحی در سرور mail دریافت شوند.

رکوردهای mail برخلاف انواع دیگری از رکوردها برای نگاشت یک میزبان به چیز دیگری استفاده نمی‌شود، چون در مورد کل منطقه اعمال می‌شوند. بدین ترتیب ظاهر آن‌ها معمولاً مانند زیر است:

IN MX 10 mail.domain.com.

توجه داشته باشید که در ابتدا نام میزبانی وجود ندارد. همان طور که می‌بینید یک عدد اضافی در اینجا وجود دارد. این عددِ ترجیح است که به رایانه‌ها کمک می‌کند تا تصمیم بگیرند در صورت وجود چند سرور mail، به کدام یک ایمیل بفرستند. اعداد پایین‌تر اولویت پایین‌تری دارند.

رکورد MX باید به طور معمول به یک میزبان تعریف شده توسط رکورد A یا AAAA اشاره کند و نه رکورد تعریف شده به وسیله CNAME.

بنابراین اگر فرض کنیم دو سرور mail داریم، رکوردهای آن‌ها چیزی مانند زیر خواهد بود:

IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

در این مثال، میزبان «mail1» سرور مبادله mail ترجیحی است. همچنین می‌توانیم آن را به صورت زیر نیز بنویسیم:

IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

رکوردهای NS

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

همانند رکوردهای MX، این نوع از رکوردها نیز پارامترهایی در سطح منطقه دارند و از این رو میزبانی برای آن‌ها تعیین نمی‌شود. به طور کلی این نوع رکوردها مانند زیر هستند:

IN NS ns1.domain.com.
IN NS ns2.domain.com.

شما باید در هر فایل منطقه دست کم دو سرور نام داشته باشید تا در صورتی که برای یک از سرورها مشکلی پیش آمد، سرور دیگر به درستی عمل کند. اغلب نرم‌افزارهای سرور DNS، در صورتی که تنها یک سرور نام منفرد در فایل منطقه تعریف شده باشد، آن را نامعتبر تلقی می‌کنند. مانند موارد دیگر نگاشت‌های میزبان‌ها با استفاده از رکوردهای A یا AAAA صورت می‌گیرد:

IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233

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

رکوردهای PTR

رکوردهای PTR برای تعریف کردن نام مرتبط با یک آدرس IP استفاده می‌شود. رکوردهای PTR معکوس رکورد A یا AAAA هستند. رکوردهای PTR منحصر به فرد هستند، چون در ریشه arpa. آغاز می‌شوند و به مالکان آدرس‌های IP تحویل داده می‌شوند. رجیستری‌های اینترنت منطقه‌ای (RIR ها) آدرس‌های IP تحویلی به سازمان‌ها و ارائه‌دهندگان خدمات را مدیریت می‌کنند. رجیستری‌های اینترنت منطقه‌ای شامل APNIC, ARIN, RIPE NCC, LACNIC و AFRINIC هستند. در ادامه نمونه‌ای از رکورد PTR را برای آی‌پی 111.222.333.444 می‌بینید:

444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.

این نمونه‌ای از رکورد PTR برای یک آدرس IPv6 است که قالب نیبل (nibble) معکوس سرور DNS IPv6 گوگل (2001:4860:4860::8888) را نشان می‌دهد.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

از ابزار خط فرمان dig با فلگ x- می‌توان برای بررسی نام DNS معکوس یک آدرس IP استفاده کرد. در ادامه نمونه‌ای از یک دستور dig را می‌بینید. short+ به آن الحاق شده است تا خروجی نام DNS معکوس را کوتاه‌تر سازد:

dig -x 8.8.4.4 +short

خروجی دستور dig فوق نام دامنه‌ای خواهد بود که رکورد PTR آدرس IP را دارد:

google-public-dns-b.google.com.

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

اغلب سرورهای ایمیل وقتی یک ایمیل جدید دریافت می‌کنند، آدرس IP رکورد PTR آن را بررسی می‌کنند. اگر آدرس IP منبع یک رکورد PTR نداشته باشد، احتمالاً با آن مانند یک اسپم یا ایمیل رد شده برخورد می‌کنند. در این مورد مهم نیست که FQDN در PTR با نام دامنه ایمیل ارسال شده مطابقت داشته باشد یا نه. آنچه که مهم است این است که یک رکورد PTR معتبر متناظر با رکورد A فوروارد شده وجود داشته باشد.

به طور معمول روترهای شبکه روی اینترنت، رکوردهای PTR متناظر با موقعیت فیزیکی را ارائه می‌کنند. برای نمونه ممکن است ارجاع‌هایی به صورت NYC یا CHI برای یک روتر که در نیویورک یا شیکاگو واقع شده است مشاهده کنید. این حالت در مواردی که یک tracetoute یا MTR اجرا می‌کنید و ترافیک مسیر اینترنتی را بازبینی می‌کنید، حائز اهمیت است.

اغلب ارائه‌دهندگان سرورهای اختصاصی یا سرویس‌های VPS به مشتریان خود این امکان را می‌دهند که یک رکورد PTR برای آدرس IP خود تعیین کنند. توجه کنید که مطابقت داشتن FQDN در رکورد PTR و رکورد A فوروارد شده مهم است. برای مثال 111.222.333.444 یک PTR به صورت server.example.com داشته باشد و server.example.com یک رکورد A باشد که به 111.222.333.444 اشاره کند.

رکوردهای CAA

رکوردهای CAA برای این استفاده می‌شوند که تعیین کنند کدام مرجع گواهی (CA ها) مجاز به صدور گواهی‌های SSL/TLS برای دامنه شما هستند. از تاریخ 8 سپتامبر 2017، همه CA ها الزام شده‌اند تا این رکوردها را پیش از صدور گواهی بررسی کنند. اگر چنین رکوردی وجود نداشته باشد، CA می‌تواند یک گواهی صادر کند. در غیر این صورت تنها CA های مجاز می‌توانند برای دامنه شما گواهی صادر کنند. رکوردهای CAA می‌توانند در مورد یک میزبان منفرد یا کل دامنه‌ها اعمال شوند. نمونه‌ای از رکورد CAA به صورت زیر است:

example.com. IN CAA 0 issue "letsencrypt.org"

میزبان، IN و رکورد نوع CAA فیلدهای رایج DNS هستند. اطلاعات خاص CAA فوق بخش 0 issue "letsencrypt.org" است. این بخش خود سه قسمت مجزا دارد که شامل فلگ 0، تگ issue و مقدار «letsencrypt.org» است. در ادامه هر کدام از آن‌ها را توضیح داده‌ایم:

فلگ ها اعداد صحیحی هستند که نشان می‌دهند یک CA چگونه می‌تواند تگ‌هایی که درک نمی‌کند را مدیریت کند. اگر فلگ برابر با 0 باشد این رکورد نادیده گرفته می‌شود. اگر برابر با 1 باشد CA باید از صدور گواهی خودداری کند.

تگ‌ها رشته‌هایی هستند که منظور از رکورد CAA را نشان می‌دهند. در حال حاضر این تگ‌ها می‌توانند به صورت issue باشند تا نشان دهند یک CA می‌تواند گواهی‌هایی برای یک نام میزبان خاص صادر کند، همچنین تگ issuewild برای تعیین اجازه صدور گواهی‌های وایلدکارد استفاده می‌شود. تگ iodef برای تعریف یک URL استفاده می‌شود که CA در آن می‌تواند نقض سیاست‌هایش را اعلام کند.

مقادیر (values) نیز رشته‌هایی هستند که به تگ رکورد مربوط هستند. برای تگ‌های issue و issuewild این مقادیر معمولاً برابر با دامنه CA-یی که اجازه صدور گواهی داده می‌شود تعیین می‌شوند. در مورد تگ iodef این رشته به صورت URL است که فرم تماس یا یک لینک :mailto برای ارائه بازخورد به صورت ایمیل در آن قرار دارد.

از dig می‌توان برای دریافت اطلاعات رکورد CAA به صورت زیر می‌توان استفاده کرد:

dig example.com type257

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

مقایسه انواع سرور DNS

DNS یا «سیستم نام دامنه» (Domain Name System) بخشی از فرایند اتصال سیستم‌ها به همدیگر برای برقراری ارتباط روی اینترنت است. افرادی که از رایانه استفاده می‌کنند، بدون وجود DNS مجبور هستند برای اتصال به رایانه‌های دیگر از نشانی‌های عددی آن‌ها که همان آدرس IP است استفاده کنند.

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

مسیر کوئری DNS

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

برخی اپلیکیشن‌ها مانند مرورگرهای وب، اطلاعات کوئری‌های اخیر خود را کَش (cash) می‌کنند. این نخستین جایی است که اپلیکیشن بررسی می‌کند تا بتواند آدرس IP دامنه مورد جستجو را پیدا کند. اگر نتواند پاسخ این سؤال را بیابد در مرحله بعد از system resolver برای یافتن آدرس نام دامنه سؤال می‌کند.

یک resolver به طور کلی جزئی است که به عنوان یخش سمت کلاینت در کوئری DNS عمل می‌کند. resolver سیستم یک کتابخانه از سیستم عامل برای جستجوی پاسخ کوئری‌های DNS بهره می‌گیرد. به طور کلی resolver سیستم یک تحلیل‌گر ساده محسوب می‌شود چون قابلیت اجرای جستجوهای پیچیده ندارد و صرفاً چند فایل استاتیک (مثلاً فایل erc/hosts/) را روی سیستم جستجو می‌کند و یا درخواست‌ها را به یک resolver دیگر فوروارد می‌کند.

بنابراین به طور کلی یک کوئری از اپلیکیشن کلاینت به resolver سیستم می‌رود و سپس از آنجا به یک سرور DNS که آدرس را دارد ارسال می‌شود. سرور DNS به نام سرور DNS بازگشتی (Recursive servers) نیز نامیده می‌شود. یک سرور بازگشتی آن سرور DNS است که طوری پیکربندی شده تا سرورهای DNS دیگر را مورد پرس و جو قرار دهد و بدین ترتیب پاسخ سؤال خود را بیابد. این سرور یا پاسخ را بازمی‌گرداند یا پیام خطا به کلاینت ارسال می‌کند (در این مورد resolver سیستم به نوبه خود آن را به اپلیکیشن کلاینت می‌فرستد.)

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

اگر این سرور نتواند آدرس هیچ یک از این اجزای دامنه را پیدا کند باید از ابتدایی‌ترین جزء این سلسله مراتب با کوئری زدن به سرورهای نام ریشه (root name servers) کار جستجوی خود را آغاز کند. سرورهای ریشه آدرس همه سرورهای نام TLD (دامنه‌های سطح بالا) را که منطقه‌های.com،.net،.org و غیره را کنترل می‌کنند، می‌داند. سرور ما از سرورهای ریشه سؤال می‌کند که آیا آدرس www.example.com را می‌شناسند یا نه. سرور ریشه سرورهای نام TLD به صورت.com را به سرور بازگشتی ارسال می‌کند.

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

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

تفاوت‌های کارکردی

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

سرورهای DNS به صورت Authoritative-Only

سرور DNS به صورت Authoritative-Only سروری است که تنها برای پاسخ‌دهی به کوئری‌هایی در مورد منطقه‌هایی که مسئولیت دارد طراحی شده است. از آنجا که این سرور برای resolve کردن کوئری‌های خارج از منطقه‌های مشخص عملی انجام نمی‌دهد به طور کلی عملکرد سریعی دارد و می‌تواند درخواست‌های زیاد را با کارایی بالا مدیریت کند.

سرور Authoritative-Only مشخصات زیر را دارد:

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

سرور کش DNS

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

سرورهای کش این مزیت را دارند که به درخواست‌های بازگشتی از سوی کلاینت‌ها پاسخ می‌دهند. با این که سرورهای Authoritative-Only ممکن است برای ارائه اطلاعات منطقه‌ای مناسب باشند؛ اما سرورهای کش DNS از منظر کلاینت‌ها، فایده بسیار بیشتری دارند. این سرورها سیستم DNS را برای رابط‌های کلاینت به میزان بیشتری در دسترس قرار می‌دهند.

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

یک سرور کش DNS مشخصات زیر را دارد:

• به کل محدوده داده‌های DNS عمومی دسترسی دارد - همه داده‌های مناطق که از سوی سرورهای DNS قابل دسترسی عمومی عرضه می‌شوند، وارد یک درخت عرضه جهانی می‌شوند که سرورهای کش DNS به آن‌ها دسترسی دارند. یک سرور کش DNS همه چیز را در مورد سرورهای DNS ریشه می‌داند و می‌تواند موارد ارجاعی را به محض دریافت داده به طور هوشمندانه‌ای پیگیری کند.
• توانایی ارائه داده‌ها به کلاینت‌ها – تقریباً هر سیستم عامل مدرنی از طریق resolver های داخلی خود وظیفه یافتن DNS را به سرورهای اختصاصی بازگشتی واگذار می‌کند. این کتابخانه‌های resolve صرفاً یک درخواست بازگشتی صادر می‌کنند و انتظار دارند که پاسخ کاملی دریافت کنند. یک سرور کش DNS قابلیت‌های دقیقی برای خدمت‌رسانی به این کلاینت‌ها دارد. این سرورها با پذیرش کوئری‌های بازگشتی این تعهد را می‌دهند که یا پاسخ صحیحی بدهند و یا پیام خطای DNS را بازگردانند.
• نگهداری یک کش از داده‌های درخواست شده اخیر – سرورهای کش با ذخیره‌سازی نتایج گردآوری‌شده از سرورهای DNS دیگر، یک حافظه کش برای داده‌های DNS اخیر می‌سازند. بسته به تعداد کاربرانی که از یک سرور کش استفاده می‌کنند، اندازه خود کش، و مدت زمانی که داده‌های TTL در رکوردهای DNS هستند، این فرایند در اغلب موارد می‌تواند موجب افزایش سرعت زیادی در resolve شدن DNS داشته باشد.

سرور فوروارد DNS

یکی از روش‌های جایگزین برای تهیه یک کش برای کلاینت‌ها از طریق استفاده از سرور فوروارد DNS است. در این رویکرد، با پیاده‌سازی سرور فوروارد که به سادگی همه درخواست‌ها را به سرور DNS دیگر با قابلیت‌های بازگشتی (مانند سرور کش DNS) ارسال می‌کند، یک لینک اضافی در زنجیره resolve شدن DNS ایجاد می‌شود.

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

یک سرور فوروارد DNS مشخصات زیر را دارد:

• توانایی مدیریت درخواست‌های بازگشتی بدون اجرای خود بازگشت – بنیادی‌ترین خصوصیت سرور فوروارد DNS این است که درخواست‌ها را به کارگزار دیگری ارسال می‌کند تا آن سرور درخواست را resolve کند. سرور فوروارد می‌تواند دارای کمترین منابع باشد و همچنان با کمک گرفتن از کش خود عملکردی بالا داشته باشد.
• ارائه یک کش محلی در موقعیت فیزیکی نزدیک شبکه – در مواردی که ساخت، نگهداری و تأمین یک راه‌حل DNS بازگشتی کامل مقرون به صرفه نباشد، سرور فوروارد می‌تواند از سرورهای DNS بازگشتی عمومی کمک بگیرد. چنین سروری از آن سرورها کمک می‌گیرد و همزمان موقعیت کش اصلی را به رایانه‌های کلاینت بسیار نزدیک‌تر می‌سازد. این مسئله می‌تواند زمان پاسخ‌دهی را بسیار کاهش دهد.
• افزایش انعطاف‌پذیری در تعریف کردن فضای دامنه محلی – یک سرور فوروارد، با ارسال مشروط درخواست‌ها به سرورهای مختلف می‌تواند تضمین کند که درخواست‌های داخلی از سوی سرورهای داخلی پاسخ‌دهی می‌شوند، در حالی که برای درخواست‌های بیرونی از DNS عمومی استفاده می‌شود.

راه‌حل‌های ترکیبی

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

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

با این که نرم‌افزار DNS به طور خاص برای ایفای نقش مشخصی طراحی شده است؛ اما اپلیکیشن‌هایی مانند Bind کاملاً انعطاف‌پذیر هستند و می‌توانند به صورت راه‌حل‌های ترکیبی استفاده شوند. همچنین گرچه در برخی موارد تلاش برای ارائه سرویس‌های زیاد روی یک سرور می‌تواند موجب کاهش عملکرد شود؛ اما در اغلب موارد به خصوص در حالت‌هایی که زیرساخت کوچک است، داشتن یک راه‌حل منفرد همه‌کاره معقول‌تر به نظر می‌رسد.

تفاوت‌های نسبی

با این که غالباً تفاوت‌های ظاهری بین پیکربندی‌های سرور DNS، احتمالاً تفاوت‌های کارکردی و نسبی هستند؛ اما این تفاوت‌ها بسیار حائز اهمیت هستند.

سرورهای Primary و Slave

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

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

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

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

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

سرورهای عمومی یا خصوصی

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

یک سازمان می‌تواند یک سرور DNS به صورت Authoritative-Only را برای مدیریت کوئری‌های DNS عمومی برای دامنه‌ها و مناطقی که مدیریت می‌کند نگهداری کند. این سازمان برای کاربران داخلی خود می‌تواند از یک سرور DNS جداگانه استفاده کند که شامل اطلاعات مجاز است که DNS عمومی ارائه می‌کند و همچنین اطلاعات اضافی در مورد میزبان‌های داخلی و سرویس‌هایشان را نگهداری می‌کند. این سرورهای DNS داخلی می‌توانند ویژگی‌های دیگری مانند بازگشت و کش را صرفاً برای کلاینت‌های داخلی عرضه کنند.

با این که پیش‌تر بیان کردیم استفاده از یک سرور منفرد برای مدیریت همه این وظایف در سرورهای ترکیبی ممکن است؛ اما مزیت‌های مشخصی نیز در تقسیم بار کاری وجود دارد. در واقع نگهداری سرورهای کاملاً مجزا (داخلی و خارجی) که اطلاعی از همدیگر ندارند، غالباً وضعیت مطلوبی محسوب می‌شود. این وضعیت به طور خاص از نقطه نظر امنیتی حائز اهمیت است، چون سرور عمومی هیچ اطلاعی از همتای خصوصی خود ندارد. این بدان معنی است که سرورهای نام خصوصی شما در رکوردهای NS فایل‌های منطقه عمومی ذخیره نخواهند شد.

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

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

این به آن معنی است که برای هر سرور باید فایل‌های منطقه جداگانه‌ای نگهداری شود که بدیهی است مستلزم زحمت بیشتری است. با این حال این وضعیت می‌تواند برای جداسازی مطلق سرورها و تأمین امنیت ضروری باشد.

نتیجه‌گیری

احتمالاً در این مرحله متوجه شده‌اید که در انتخاب پیکربندی سرور DNS خود انعطاف‌پذیری زیادی دارید. انتخاب‌های شما تا حدود زیادی به نیازهای سازمان و اولویت‌های شما برای ارائه resolve سریع‌تر برای کلاینت‌های منتخب (کش یا فوروارد کردن) یا عرضه گسترده دامنه‌ها و منطقه‌ها به وسعت اینترنت (سرورهای مجاز) بستگی دارد. رویکردهای ترکیبی متداول هستند و در نهایت هر دو طرف فرایند resolve باید به آن متعهد باشند.

اگر این نوشته مورد توجه شما قرار گرفته است، پیشنهاد می‌کنیم موارد زیر را نیز بررسی کنید:

• DNS چیست و آیا باید سرور DNS خود را تغییر دهیم؟
• گواهی های SSL وایلدکارد Let’s Encrypt با استفاده از اعتبارسنجی کلودفلیر روی CentOS 7
• مجموعه آموزش‌های راه‌اندازی و مدیریت سایت با وردپرس
• راهنمای جامع روش‌های اتصال در اینترنت اشیا (Internet of Things)
• رکورد CNAME چیست و چگونه از آن استفاده کنیم؟
• مجموعه آموزش‌های شبکه های کامپیوتری

==