پیکربندی Bind به عنوان سرور DNS برای درخواست های Authoritative-Only — به زبان ساده

DNS یا «سیستم نام دامنه» معمولاً یکی از اجزایی است که پیکربندی آن در وب‌سایت‌ها و سرورها با دشواری‌هایی همراه است. با این که اغلب افراد از سرورهای DNS-ی استفاده می‌کنند که شرکت میزبان وب‌سایت یا ثبت کننده دامنه‌شان تنظیم کرده است؛ اما شما می‌توانید سرورهای DNS خودتان را پیکربندی کنید که قطعاً مزیت‌های زیادی دارد.

در این راهنما شیوه نصب و پیکربندی سرور DNS با استفاده از Bind9 را به صورت Authoritative-Only روی سرورهای اوبونتو آموزش می‌دهیم. بدن ترتیب ما دو سرور Bind به صورت master و slave در دامنه خود راه‌اندازی می‌کنیم.

پیش‌نیازها و اهداف

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

همچنین شما به دو سرور نیاز دارید. یکی از این سرورها به عنوان سرور DNS master خواهد بود که فایل‌های zone برای دامنه شما روی آن قرار می‌گیرند و دیگری سرور Slave است که داده‌های zone را از طریق انتقال از سرور Master دریافت می‌کند و در مواردی که آن سرور از کار بیفتد، روی این سرور در دسترس خواهد بود. بدین ترتیب از مشکل «نقطه منفرد شکست» (single failure point) برای سرورهای DNS خود جلوگیری می‌کنیم.

برخلاف سرورهای کش یا فوروارد DNS و یا یک سرور چندمنظوره DNS، در مورد سرورهای DNS به صورت Authoritative-Only باید گفت که این سرورها تنها به کوئری‌های تکراری که در مورد zone خودشان معتبر هستند است پاسخگو هستند. این بدان معنی است که اگر سرور پاسخ کوئری را نداند، صرفاً به کلاینت (که معمولاً نوعی سرور resolving برای DNS است) اعلام می‌کند که در این مورد اطلاعی ندارد و آن را به سروری که احتمالاً در این خصوص اطلاع دارد، ارجاع می‌دهد.

سرورهای DNS به صورت Authoritative-Only یعنی «صرفاً معتبر» غالباً پیکربندی مطلوبی برای مواردی که به عملکرد بالا نیاز دارند محسوب می‌شوند، چون سربار کوئری‌های بازگشتی resolving از سوی کلاینت‌ها را ندارند. آن‌ها تنها در قبال zoneهایی که برای خدمت‌رسانی به آن طراحی شده‌اند، مسئول هستند.

در جهت مقاصد آموزشی که داریم در این راهنما عملاً از سه سرور استفاده خواهیم کرد. دو «سرور نام» که قبلاً اشاره کردیم و یک سرور که آن را به عنوان میزبان ، درون zoneخود پیکربندی می‌کنیم.

ما از دامنه ساختگی www.example.com در این راهنما استفاده می‌کنیم. شما باید این دامنه را با نام دامنه مورد نظر خود جایگزین کنید. در جدول زیر جزییات رایانه‌هایی که قرار است پیکربندی کنیم را می‌بینید:

شما پس از به پایان بردن این راهنما دو سرور نام Authoritative-Only خواهید داشت که برای zoneهای دامنه پیکربندی شده‌اند. از نام‌های موجود در ستون میانی جدول فوق می‌توان برای دسترسی به میزبان‌های مختلف استفاده کرد. با استفاده از این پیکربندی یک سرور DNS بازگشتی می‌تواند داده‌هایی در مورد دامنه‌های شما به کلاینت‌هایش بازگرداند.

تنظیم نام میزبان (Hostname) روی سرورهای نام

پیش از آن که وارد بحث پیکربندی سرورهای نام شویم، ابتدا باید اطمینان یابیم که نام میزبان ما روی هر دو سرور master و slave به طور صحیحی پیکربندی شده است.

کار خود را با بررسی فایل etc/hosts/ آغاز می‌کنیم. این فایل را با استفاده از دسترسی sudo در ویرایشگر متن خود باز کنید:

sudo nano /etc/hosts

باید این فایل را چنان پیکربندی کنیم که به درستی هر یک از نام میزبان‌های سرورهای ما و FQDN ها را شناسایی کند. در مورد سرور نام master این فایل باید در ابتدا چیزی شبیه زیر باشد:

127.0.0.1 localhost

127.0.1.1 ns1 ns1

...

می‌بایست خط دوم را ویرایش کنیم تا به ترکیب میزبان و دامنه مورد نظر ما ارجاع داده و آن را به آدرس IP استاتیک عمومی ما وصل کند. سپس می‌توانیم نام دلخواه خود را به صورت مستعار در انتها اضافه کنیم. در این مثال برای سرور master خط دوم را به صورت زیر تغییر می‌دهیم:

127.0.0.1 localhost

192.0.2.1 ns1.example.com ns1

...

در انتها فایل را ذخیره کرده و ببندید.

فایل etc/hostname/ را نیز باید ویرایش کنیم تا شامل نام میزبان غیر FQDN ما باشد:

sudo nano /etc/hostname

ns1

با اجرای دستور زیر می‌توانیم مقدار فوق را در سیستم در حال اجرا وارد کنیم:

sudo hostname -F /etc/hostname

همین رویه را در مورد سرور slave نیز اجرا می‌کنیم.

با فایل etc/hosts/ کار خود را آغاز می‌کنیم.

sudo nano /etc/hosts

---

127.0.0.1 localhost

192.0.2.2 ns2.example.com ns2

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

سپس فایل etc/hostname/ را ویرایش می‌کنیم. به خاطر داشته باشید که در این فایل تنها از میزبان وقعی (در این مثال تنها از ns2) باید استفاده کنید.

sudo nano /etc/hostname

---

ns2

در این مورد نیز فایل را برای تغییر سیستم کنونی می‌خوانیم:

sudo hostname -F /etc/hostname

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

نصب Bind روی هر دو سرور نام

روی هر یک از سرورهای نام خود می‌توانید Bind را نصب کنید. Bind سرور DNS-ی است که مورد استفاده قرار خواهیم داد.

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

sudo apt-get update

sudo apt-get install bind9 bind9utils bind9-doc

با اجرای دستور فوق روی سرورهای DNS به صورت master و slave، آن‌ها می‌توانند فایل‌های مورد نظر را دریافت کنند.

پیکربندی Bind روی سرور master

اینک که نرم‌افزار مورد نیاز خود را نصب کردیم، می‌توانیم شروع به پیکربندی سرور DNS روی سرور master خود بکنیم.

پیکربندی فایل Options

نخستین کاری که باید انجام دهیم بررسی تنظیمات فایل named.conf.options است.

سرور دی‌ان‌اس Bind که به نام named نیز شناخته می‌شود، دارای یک فایل پیکربندی اصلی در مسیر etc/bind/named.conf است. این فایل، فایل‌های دیگر را که ما در عمل پیکربندی خواهیم کرد فراخوانی می‌کند.

فایل Options را با دسترسی sudo و ویرایشگر متنی مورد نظر خود باز کنید:

sudo nano /etc/bind/named.conf.options

در ادامه غالب خطوط کامنت این فایل حذف شده‌اند تا خوانایی بیشتری ایجاد شود. به طور کلی فایل Options پس از نصب باید چیزی شبیه زیر باشد:

options {
        directory "/var/cache/bind";

        dnssec-validation auto;
  
        auth-nxdomain no; # conform to RFC1035
        listen-on-v6 { any; };
};

اصلی‌ترین چیزی که باید در این فایل پیکربندی کنیم، بحث بازگشت (recursion) است. از آنجا که ما می‌خواهیم یک سرور Authoritative-Only را پیکربندی کنیم، قصد نداریم که از بازگشت در این سرور استفاده کنیم. بنابراین امکان را می‌توانیم در بلوک options خاموش کنیم.

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

options {
       directory "/var/cache/bind";
       recursion no;
      allow-transfer { none; };

      dnssec-validation auto;
 
       auth-nxdomain no; # conform to RFC1035
      listen-on-v6 { any; };
};

در انتها فایل را ذخیره کرده و خارج شوید.

پیکربندی فایل محلی

مرحله بعدی این است که zoneهایی که می‌خواهیم این سرور کنترل کند را تعیین کنیم. منظور از zone هر بخشی از دامنه است که مسئولیت آن به یک سرور نام داده می‌شود و این مسئولیت به سرورهای دیگر داده نشده است.

ما در این راهنما دامنه example.com را پیکربندی می‌کنیم و از این رو نباید مسئولیت هیچ بخشی از دامنه را به سرورهای دیگر واگذار کنیم. از این رو zone شامل همه دامنه ما خواهد بود.

برای پیکربندی zoneهای خود باید فایل etc/bind/named.conf.local/ را با دسترسی‌های sudo باز کنیم:

sudo nano /etc/bind/named.conf.local

در این فایل به جز کامنت چیز دیگری وجود ندارد. zoneهای دیگری وجود دارند که سرور ما برای اطلاعات کلی از آن‌ها اطلاع دارد؛ اما این zoneها در فایل named.conf.default-zones ذکر نشده‌اند.

برای آغاز به کار باید zone فوروارد را برای دامنه example.com پیکربندی کنیم. منظور از zone فوروارد همان ترجمه متعارف نام به IP است که اغلب هنگامی که صحبت از دی‌ان‌اس می‌شود به ذهنمان می‌آید. یک بلوک پیکربندی برای zone-ی که می‌خواهیم پیکربندی شود، ایجاد می‌کنیم:

zone "example.com" {

};

درون این بلوک اطلاعات مدیریتی در مورد zone را اضافه می‌کنیم. ما رابطه این سرور دی‌ان‌اس را با zone تعیین می‌کنیم. در این مورد، این سرور master محسوب می‌شود، زیرا مشغول پیکربندی این دستگاه به عنوان سرور نام master برای همه zoneها هستیم. همچنین Bind را در مورد فایلی که رکوردهای منبع واقعی تعریف این zone را دارد، راهنمایی می‌کنیم.

ما قصد داریم فایل‌های zone در سرور master را در یک زیردایرکتوری به نام zones درون دایرکتوری پیکربندی Bind نگهداری کنیم. این فایل را db.example.cm می‌نامیم تا بتوانیم آن را از دیگر فایل‌های zone موجود در دایرکتوری Bind متمایز سازیم. این بلوک چیزی مانند زیر خواهد بود:

zone "example.com" {
   type master;
   file "/etc/bind/zones/db.example.com";

};

همچنین باید به این zone اجازه بدهیم که به سرورهای slave انتقال یابد. بدین منظور باید خطی مانند زیر اضافه کنیم:

zone "example.com" {
   type master;
   file "/etc/bind/zones/db.example.com";
   allow-transfer { 192.0.2.2; };
};

سپس به تعریف zone معکوس برای دامنه خود می‌پردازیم.

اطلاعاتی در خصوص zoneهای معکوس (reverse)

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

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

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

اطلاعاتی که برای درک نگاشت معکوس نیاز دارید در ادامه ارائه شده‌اند:

• در یک دامنه، جزئی‌ترین بخش آدرس در سمت چپ آن قرار دارد. در یک آدرس IP، جزئی‌ترین بخش در سمت راست قرار دارد.
• جزئی‌ترین بخش یک دامنه تعیین می‌کند که این نام یک زیردامنه است یا نام میزبان. این مسئله در فایل  zoneبرای آن دامنه تعریف شده است.
• هر زیردامنه می‌تواند به نوبه خود زیردامنه ها یا میزبان‌های بیشتری را تعریف کند.

همه نگاشت‌های zone معکوس زیردامنه خاص in-addr.arpa تعریف می‌شوند که از سوی سازمان «مرجع اعداد واگذاری شده» (IANA) کنترل می‌شود. زیر این دامنه یک درخت وجود دارد که از زیردامنه‌ها برای نگاشت هر یک از اجزای آدرس IP استفاده می‌کند. برای اطمینان از این که جزییات آدرس‌های IP بازتاب‌دهنده جزییات دامنه‌های معمولی است، بخش‌های مختلف آدرس IP در عمل معکوس می‌شوند.

بنابراین سرور DNS master، با استفاده از آدرس آی‌پی 192.0.2.1 می‌تواند به صورت 1.2.0.192 معکوس شود. وقتی که جزییات را به این میزبان به صورت یک درخت موجود زیردامنه in-addr.arpa اضافه کنیم، میزبان خاص می‌تواند به صورت 1.2.0.192.in-addr.arpa مورد ارجاع قرار گیرد.

از آنجا که ما میزبان‌های منفرد (مانند 1 در این مثال) را هنگام استفاده از DNS درون خود فایل zone تعریف می‌کنیم، این zone را می‌توان به صورت 2.0.192.in-addr.arpa پیکربندی کرد. اگر ارائه‌دهنده شبکه به ما یک بلوک 24/ مانند 192.0.2.0/24 از آدرس داده باشد این آی‌پی‌ها می‌توانند در بخش in-addr.arpa به ما اختصاص یابند.

اینک که می‌دانید چگونه نام zone معکوس را بیان کنید، تعریف واقعی آن دقیقاً همانند zone فوروارد است. در ادامه تعریف zone برای example.com را ارائه کرده‌ایم تا یک zone معکوس برای شبکه‌ای که ارائه شده است داشته باشیم. در این مورد نیز این تعریف تنها در حالتی ضروری است که کنترل یک بلوک از آدرس‌ها به شما داده شده باشد:

zone "2.0.192.in-addr.arpa" {
   type master;
   file "/etc/bind/zones/db.192.0.2";
};

نام فایل را به صورت db.192.0.2 تعیین کردیم. این نام نشان دهنده این است که کدام zone پیکربندی شده است و خوانایی بیشتری نسبت به نمادگذاری معکوس دارد.

در انتهای کار خود فایل را ذخیره کرده و خارج شوید.

ایجاد فایل zone فوروارد

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

اگر به خاطر داشته باشید ما مکان فایل‌ها را که در زیردایرکتوری zones خواهند بود نیز تعیین کردیم و اینک باید این دایرکتوری را ایجاد کنیم:

sudo mkdir /etc/bind/zones

در این زمان می‌توانیم از برخی فایل‌های zone از پیش موجود در دایرکتوری Bind به عنوان قالبی برای فایل‌های zone-ی که می‌خواهیم ایجاد کنیم بهره بگیریم. در مورد zoneفوروارد فایل db.local به آنچه ما می‌خواهیم ایجاد کنیم نزدیک‌تر است. بنابراین فایل را در زیردایرکتوری zones کپی کنید و نام آن را به named.conf.local تغییر دهید.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

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

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

اینک فایل zone فوروارد را با استفاده از دسترسی sudo در ویرایشگر متنی مورد نظر خود باز کنید:

sudo nano /etc/bind/zones/db.example.com

این فایل به صورت زیر است:

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1

نخستین کاری که باید انجام دهیم این است که رکورد SOA یعنی «آغاز مرجعیت» (Start of Authority) را تغییر دهیم. این رکورد با علامت @ آغاز می‌شود و تا انتهای پرانتزها ادامه دارد.

باید مقدار .localhost موجود در این رکورد را با FQDN سرور خود تعویض کنیم. این بخش از رکورد برای تعریف هر سرور نام که مسئولیت پاسخگویی برای zone تعریف شده دارد را شامل می‌شود. ns1.example.com. همان سروری است که اینک قصد داریم آن را پیکربندی کنیم. به نقطه انتهایی توجه کنید چون برای ثبت صحیح الزامی است.

همچنین باید بخش بعدی را نیز تغییر دهیم که در عمل آدرس ایمیل را با فرمت خاصی ارائه می‌کند در این فرمت به جای «@» از «.» استفاده می‌شود. ما می‌خواهیم که ایمیلمان به مدیر دامنه برود که ایمیل سنتی آن به صورت admin@example.com است. بنابراین آن را به صورت admin.example.com. ترجمه می‌کنیم:

@ IN SOA ns1.example.com. admin.example.com. (

در بخش بعدی باید شماره سری را ویرایش کنیم. مقدار شماره سری به Bind می‌گوید که اطلاعات به‌روزرسانی شده را به سرور slave ارسال کند.

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

یک رویه رایج برای راحت‌تر شدن افزایش این عدد این است که از تاریخ با فرمت YYYYMMDD به همراه شماره بازبینی برای آن روز در انتها استفاده کنید. بنابراین نخستین بازبینی در تاریخ 5 مهر 1397 به صورت 1397070501 خواهد بود و اگر در ادامه به‌روزرسانی دیگری انجام یافت، می‌توانید این شماره سری را به صورت 1397070502 تنظیم کنید. بدین ترتیب می‌توانید هر روز تا 10 مورد بازبینی روی فایل داشته باشید.

استفاده از این رویه برای سهولت کار بسیار مناسب است؛ اما برای این که آموزش ما هر چه ساده‌تر بماند، در مثال‌های خود تنها از عدد 5 استفاده می‌کنیم:

@ IN SOA ns1.example.com. admin.example.com. (

5; Serial

سپس می‌توانیم سه خط انتهایی را حذف کنیم، چون مواردی که می‌خواهیم را خودمان خواهیم نوشت.

نخستین چیزی که می‌خواهیم پس از نوشتن رکورد SOA تعریف کنیم، سرورهای نام برای zone است. ابتدا دامنه را ذکر می‌کنیم و سپس دو سرور نام که مسئول zone هستند را معرفی می‌کنیم. از آنجا که سرورهای نام در واقع میزبان‌هایی درون خود دامنه هستند، این وضعیت تا حدودی خود-ارجاع به نظر می‌رسد.

در این راهنما وضعیت به صورت زیر خواهد بود. در این مورد نیز باید به نقطه‌های انتهایی توجه داشته باشید:

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

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

بنابراین در ادامه باید یک رکورد A ایجاد کنیم که این سرورهای نام را به آدرس‌های IP واقعی سرورهای نام ما ارتباط می‌دهند:

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

اینک که رکوردهای A برای resolve موفق سرورهای نام خود به آدرس‌های IP صحیح را داریم، می‌توانیم رکوردهای بیشتری به آن اضافه کنیم. به یاد داشته باشید که ما یک وب سرور روی یکی از میزبان‌های خود داریم که می‌خواهیم از آن برای عرضه وب‌سایت خود استفاده کنیم. ما درخواست‌ها برای دامنه عمومی خود (در این مثال example.com) را به یک میزبان و درخواست‌های www را نیز به همان میزبان هدایت می‌کنیم. بنابراین مانند زیر خواهد بود:

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

در ادامه می‌توانید هر تعداد میزبان دیگری که می‌خواهید را با ایجاد رکوردهای A بیشتر تعریف کنید. برای آشنایی بیشتر با این رکوردها و گزینه‌هایی که در اختیار دارید، به مطلب «راهنمای جامع DNS» مراجعه کنید.

زمانی که کار خود را به پایان بردید، فایل نهایی چیزی شبیه زیر خواهد بود:

$TTL    604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

زمانی که کارتان تمام شد، فایل را ذخیره کرده و خارج شوید.

ایجاد فایل zone معکوس

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

 

بنابراین در این مرحله کافی است این فایل را با استفاده از دسترسی sudo باز کنیم:

sudo nano db.192.0.2

این فایل در ابتدا شبیه زیر است:

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

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

@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial

در این مورد نیز خطوط زیر پرانتز انتهایی رکورد SOA را پاک می‌کنیم. در ادامه آخرین بخش از هر آدرس IP در محدوده شبکه خود را انتخاب می‌کنیم و آن را با استفاده از رکورد PTR به FQDN میزبان خود ارتباط می‌دهیم. هر آدرس آی‌پی باید تنها یک رکورد PTR داشته باشد تا از بروز مشکلات در برخی نرم‌افزارها جلوگیری کنیم و از این رو باید نام میزبانی که می‌خواهید نگاشت معکوس بکنید را انتخاب نمایید.

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

در ابتدا باید سرورهای نام خود را یک بار دیگر تنظیم کنیم:

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

سپس از آخرین بخش آدرس IP برای ارجاع به آن استفاده می‌کنیم و آن را به نام دامنه جامع‌الشرایط (FQDN) خود که می خواهیم بازگشت دهد، ارجاع می‌دهیم. در این مثال از چیزی شبیه زیر استفاده می‌کنیم:

; PTR Records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

وقتی این کار را انجام دادید، فایل نهایی باید به صورت زیر باشد:

$TTL    604800
@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

; PTR records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

وقتی کارتان تمام شد، فایل را ذخیره کرده و خارج شوید.

تست کردن فایل‌ها و ری‌استارت کردن سرور

پیکربندی سرور master اینک به پایان رسیده است؛ اما باید برخی تغییرات را روی آن اعمال کنیم.

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

در ابتدا باید فایل‌های named.conf.local و named.conf.options را با استفاده از دستور named-checkconf بررسی کنیم. از آنجا که هر دو این فایل‌ها از روی اسکلت فایل named.conf ساخته شده‌اند، این ابزار ساختار فایل‌هایی که تغییر داده‌ایم را بررسی می‌کند.

sudo named-checkconf

اگر دستور فوق هیچ پیامی بازنگرداند، بدان معنی است که فایل‌های named.conf.local و named.conf.options از نظر ساختاری معتبر هستند.

سپس باید فایل‌های zone را با ارسال دامنه‌ای که zone را مدیریت می‌کند و موقعیت فایل zone را با استفاده از دستور named-checkzone بررسی کنیم. در مورد این راهنما فایل zone را با وارد کردن دستور زیر می‌توانیم بررسی کنیم:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

اگر این فایل مشکلی نداشته باشد، خروجی دستور فوق شماره سری صحیح فایل را نشان می‌دهد و پیام «OK» نمایش می‌یابد:

zone example.com/IN: loaded serial 5

OK

اگر با هر پیام دیگری مواجه شدید، به این معنی است که اشکالی در فایل zone وجود دارد. معمولاً پیام‌هایی که می‌بینید به طور کامل در مورد بخشی که اشکال وجود دارد توضیح می‌دهند.

با ارسال آدرس in-addr.arpa و نام فایل می‌توانید zone معکوس را نیز بررسی کنید. در این راهنما از دستور زیر استفاده می‌شود:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

در این مورد نیز پیامی مشابه بخش قبلی به همراه شماره سری و OK باید نمایش یابد:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5

OK

اگر همه فایل‌ها را بررسی کردید و اشکالی نبود می‌توانید سرویس Bind را ری‌استارت کنید:

sudo service bind9 restart

با وارد کردن دستور زیر می‌توانید لاگ را بررسی کنید:

sudo tail -f /var/log/syslog

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

پیکربندی Bind برای سرور Slave

اینک که سرور master را پیکربندی کردیم می‌توانیم به کار خود ادامه داده و سرور slave را نیز راه‌اندازی کنیم. این بخش به طور خاص آسان‌تر از سرور master خواهد بود.

پیکربندی فایل Options

در این مورد نیز کار خود را با فایل named.conf.options آغاز می‌کنیم. این فایل را با دسترسی‌های sudo در ویرایشگر متنی خود آغاز می‌کنیم:

sudo nano /etc/bind/named.conf.options

در این مورد نیز دقیقاً همان تغییراتی را که در مورد فایل Options سرور master ایجاد کردیم، در این فایل اعمال می‌کنیم:

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

در انتها فایل را ذخیره کرده و خارج شوید.

پیکربندی فایل پیکربندی محلی

سپس فایل named.conf.local را روی سرور slave پیکربندی می‌کنیم. آن را با دسترسی sudo در ویرایشگر متنی باز می‌کنیم:

sudo nano /etc/bind/named.conf.local

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

ابتدا روی zone فوروارد کار می‌کنیم. به همان ترتیبی که در مورد فایل master عمل کردیم در این مورد نیز آن را با بلوک زیر آغاز می‌کنیم:

zone "example.com" {

};

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

دلیل این مسئله آن است که Bind در مورد zoneهای slave فایل‌ها را در مسیر var/cache/bind/ ذخیره می‌کند. Bind از قبل طوری پیکربندی شده است که در این دایرکتوری به دنبال فایل‌های zone در سرور slave بگردد و از این رو نیازی به تعیین مسیر نداریم.

در مورد zone فوروارد این جزییات، چیزی شبه زیر هستند:

zone "example.com" {
    type slave;
    file "db.example.com";
};

در نهایت به جای عبارت allow-transfer، مسیر سرورهای master را که این سرور فایل‌های zone را از آن‌ها دریافت می‌کند، به وسیله آدرس‌های IP-شان مشخص می‌کنیم. این کار در عبارت masters صورت می‌گیرد:

zone "example.com" {
    type slave;
    file "db.example.com";
    masters { 192.0.2.1; };
};

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

zone "2.0.192.in-addr.arpa" {
    type slave;
    file "db.192.0.2";
    masters { 192.0.2.1; };
};

زمانی که کار ویرایش به پایان رسید، فایل را ذخیره کرده و خارج شوید.

تست کردن فایل و ری‌استارت کردن سرویس

لازم نیست هیچ کاری در مورد ایجاد فایل‌های واقعی zone روی سرور slave انجام دهیم، زیرا همان طور که قبلاً هم اشاره کردیم، این سرور فایل‌های zone را از سرور master دریافت خواهد کرد. بنابراین می‌توانیم پیکربندی‌های خود را تست کنیم.

در این مورد نیز ابتدا باید ساختار فایل پیکربندی را بررسی کنیم. از آنجا که هیچ فایل zone برای بررسی وجود ندارد، کافی است از ابزار named-checkconf استفاده کنیم:

sudo named-checkconf

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

در این حالت می‌توانید سرور Bind خود را ری‌استارت کنید:

sudo service bind9 restart

لاگ‌های سرور master و slave را می‌توانید با استفاده از دستور زیر چک کنید:

sudo tail -f /var/log/syslog

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

واگذاری مرجعیت به سرورهای نام

در این زمان سرورهای نام Authoritative-Only را می‌توانیم پیکربندی کنیم. با این حال همچنان باید مرجعیت (اعتبار) دامنه خود را به سرورهای نام واگذار کنید.

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

در بخش تنظیمات دامنه به دنبال گزینه‌ای بگردید که امکان تعیین سرورهای نام را می‌دهد. از آنجا که سرورهای نام درون دامنه ما هستند، این یک مورد استثنایی است.

به جای رجیستر کردن صرف واگذاری مرجعیت zone از طریق استفاده از رکوردهای NS، در این مورد لازم است که یک رکورد glue ایجاد کنیم. رکورد Glue یک رکورد A است که آدرس‌های IP را برای سرورهای نام تعیین می‌کند و این مسئله پس از آن است که سرورهای نام که مرجعیت را به آن واگذار کرده است تعیین می‌شوند.

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

بنابراین باید بخشی از پنل کنترل را در وب‌سایت رجیستر دامنه بیابید که در آن سرورهای نام و آدرس‌های سرورهای نام را وارد کنید.

برای مثال در مورد مرجع ثبت دامنه‌های ir در ایران که وب‌سایت nic.ir است، باید در صفحه اصلی از منوی فوقانی به بخش دامنه‌ها> دامنه‌های من مراجعه کنید:

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

در صفحه‌ای که باز می‌شود می‌توانید آدرس‌های آی‌پی و سرورهای نام مورد نظر خود را وارد نمایید:

توجه داشته باشید که این تغییرات برای این که در سراسر اینترنت انتشار یابند به 24 تا 48 ساعت زمان نیاز دارند. برای این که متوجه شوید آیا تغییراتی که در مورد سرورهای نام خود اعمال کردید در نقاط مختلف دنیا اعمال شده است یا نه می‌توانید از خدمات وب‌سایت whatsmydns استفاده کنید.

 

جمع‌بندی

در این راهنما دو سرور DNS را به صورت authoritative-only پیکربندی کردیم تا دامنه‌های مورد نظر ما را ارائه دهند. این سرورها می‌توانند برای ذخیره‌سازی اطلاعات zone برای دامنه‌های دیگری که در آینده تهیه می‌کنید نیز استفاده شوند.

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

اگر به این نوشته علاقه‌مند بودید، پیشنهاد می‌کنیم موارد زیر را نیز ملاحظه کنید:

• DNS چیست و آیا باید سرور DNS خود را تغییر دهیم؟
• مفاهیم DNS، اجزا و انواع سرورهای آن — راهنمای جامع
• ابزارها و راهکارهای مدیریت وبسایت‌ها
• گواهی های SSL وایلدکارد Let’s Encrypt با استفاده از اعتبارسنجی کلودفلیر روی CentOS 7
• رکورد CNAME چیست و چگونه از آن استفاده کنیم؟
• راه‌اندازی و مدیریت سایت با وردپرس

==