استفاده از NSD به عنوان DNS سرور Authoritative — صفر تا صد

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

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

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

برای حل این مشکل سرورهای جایگزین DNS ایجاد شده‌اند که به طور خاص در یک حوزه خاص از تحلیل DNS فعال هستند. یکی از این نرم‌افزارها به نام NSD یک سرور DNS به صورت authoritative-only است که برای مدیریت zone های DNS به صورت authoritative ارائه شده است. در این حالت بدون این که لازم باشد در مورد مسائلی از قبیل بازگشت (recursion) یا کش (caching) نگران باشیم، این سرور عملکرد بالا و مشکلات کمتری در زمان کار خود دارد.

در این راهنما مراحل نصب و پیکربندی یک سرور NSD روی سیستم اوبونتو را برای مدیریت امن zone‌های DNS خودمان نشان می‌دهیم.

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

پیش از آن که مطالعه این راهنما را آغاز کنید، باید با برخی «مفاهیم و انواع سرورهای DNS» آشنا باشید.

فیلم آموزش تغییر سریع DNS در ویندوز با نرم افزار دی ان اس جامپر در فرادرس

کلیک کنید

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

از آنجا که این راهنما صرفاً مقاصد آموزشی را دنبال می‌کند در این مقاله دو سرور با نرم‌افزار NSD پیکربندی می‌کنیم که به عنوان سرورهای master و slave برای zone‌های ما عمل می‌کنند. همچنین داده‌های پیکربندی مورد نیاز که به کلاینت‌های ما اجازه می‌دهد روی یک ‌هاست ثالث به وب‌سرور ما دسترسی داشته باشند ارائه می‌کنیم. در این راهنما از دامنه ساختگی example.com استفاده می‌کنیم. شما باید نام دامنه مد نظر خود را جایگزین کنید. رایانه‌هایی که پیکربندی می‌کنیم دارای خصوصیات زیر هستند:

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

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

در این راهنما نخستین گامی که باید برداریم مرحله آماده‌سازی است. پیش از آن که به پیکربندی DNS بپردازیم، باید مطمئن شویم که می‌توانیم نام میزبانی آن‌ها را به طرز صحیحی به روشی که نیاز داریم resolve کنیم. در سرور اول DNS خود فایل etc/hosts/ را ویرایش کنید تا FQDN را برای این رایانه تنظیم کنید:

sudo nano /etc/hosts

در این مورد ما باید آدرس IP 192.0.2.1 را به نام کامل سرور نام نخست ns1.example.com نگاشت کنیم این کار از طریق عوض کردن خطی که نام میزبانی ما را با آدرس IP عمومی مشخص می‌کند، FQDN و نام مستعار (alias) کوتاه شده برای میزبان ممکن است:

127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1

هنگامی که این تغییرات را انجام دادید، فایل را ذخیره کرده و ببندید. سپس باید فایل etc/hostname/ را دو بار بررسی کنیم:

sudo nano /etc/hostname

این فایل باید مقدار نام میزبان unqualified ما را داشته باشد. در صورت نیاز آن را ویرایش کنید:

ns1

پس از این تغییرات فایل را ذخیره کرده و خارج شوید. اگر فایل etc/hostname/ فوق را ویرایش کردید، به سیستم بگویید تا فایل را مجدداً بارگذاری کند:

sudo hostname -F /etc/hostname

اینک کار ما با سرور نخست DNS تمام شده است. این مراحل را بر روی سرور دوم نیز تکرار کنید. فایل etc/hosts/ را ویرایش کنید و میزبان سرور DNS دوم را تعیین کنید:

sudo nano /etc/hosts

127.0.0.1 localhost

192.0.2.2 ns2.example.com ns2

فایل etc/hostname/ را نیز بررسی کنید. این فایل باید شامل نام کوتاه unqualified باشد:

sudo nano /etc/hostname

ns2

در این مورد نیز در صورتی که لازم است چیزی را تغییر دهید، اجازه دهید سیستم فایل را مجدداً باز کند:

sudo hostname -F /etc/hostname

اینک سرورهای شما آماده resolve کردن نام‌هایشان بدون استفاده از DNS هستند. در این مرحله آماده هستیم تا NSD را روی سرورها راه‌اندازی کنیم.

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

گام بعدی نصب واقعی نرم‌افزار روی سرورهای نام است. پیش از آن که کار خود را آغاز کنیم، می‌بایست یک گام آماده‌سازی دیگر نیز برداریم. بسته NSD در ریپازیتوری‌ها نرم‌افزار را نصب می‌کند، اجزای آن را پیکربندی می‌کند و تلاش می‌کند تا سرویس را آغاز کند. انتظار می‌رود این سرویس به وسیله کاربری به نام nsd اجرا شود؛ اما بسته مورد نظر این حساب کاربری را واقعاً ایجاد نمی‌کند.

فیلم آموزش تغییر سریع DNS در ویندوز با نرم افزار دی ان اس جامپر در فرادرس

کلیک کنید

برای این که از بروز خطا در زمان نصب پیشگیری کنیم، این کاربر را پیش از نصب نرم‌افزار ایجاد می‌کنیم. بر روی هر یک از سرورها با استفاده از دستور زیر یک کاربر سیستم به نام nsd ایجاد کنید:

sudo useradd -r nsd

بدین ترتیب حساب صحیح مورد نیاز برای تکمیل مراحل نصب نرم‌افزار ایجاد شده است. اینک کافی است نرم‌افزار NSD را نصب کنید. خوشبختانه NSD در ریپازیتوری های اوبونتو وجود دارد و بنابراین می‌توانید با استفاده از دستور apt آن را دانلود کنید. ابتدا ایندکس پکیج محلی خود را به‌روزرسانی کنید و سپس بسته مناسب را دانلود نمایید:

sudo apt-get update

sudo apt-get install nsd

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

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

کار خود را با تنظیم سرور ns1 آغاز می‌کنیم که به صورت سرور DNS master برای zone‌های ما پیکربندی خواهد شد. نخستین کاری که باید انجام دهیم این است که مطمئن شویم کلیدهای SSL و گواهی‌هایی که NSD مورد استفاده قرار می‌دهد بین بخش Daemon اپلیکیشن و کنترلر به طور امنی مبادله می‌شوند. بدین منظور دستور زیر را وارد می‌کنیم:

sudo nsd-control-setup

احتمالاً از قبل کلیدها و گواهی‌هایی در دایرکتوری etc/nsd/ وجود دارند؛ اما این دستور تضمین می‌کند که همه چیز درست است و چیزی حذف نشده است.

پیکربندی فایل nsd.conf

فایل پیکربندی اصلی NSD یک فایل به نام nsd.conf است که در دایرکتوری etc/nsd/ قرار دارد. در این دایرکتوری یک فایل وجود دارد که شامل چند کامنت است؛ اما از یک فایل نمونه کاملاً کامنت شده به عنوان قالب خود استفاده می‌کنیم. با استفاده از دستور زیر این فایل را کپی کنید تا فایل کنونی را بازنویسی کنید:

sudo cp /usr/share/doc/nsd/examples/nsd.conf /etc/nsd/nsd.conf

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

sudo nano /etc/nsd/nsd.conf

درون این فایل، تعدادی از خطوط پیکربندی را می‌بینید که کامنت شده‌اند و در چند بخش دسته‌بندی گشته‌اند. بخش‌های اصلی به صورت server, remote-control, key, pattern, و zone هستند. ما از اغلب این تنظیمات در پیکربندی خود استفاده خواهیم کرد.

برای آغاز باید مشخصات مقدماتی سرور DNS خودمان را در بخش Server پیکربندی کنیم. ما می‌خواهیم ترافیک پایه IPv4 را روی پورت پیش‌فرض 53 DNS داشته باشیم. بنابراین از کاربر nsd که قبلاً ایجاد کردیم استفاده می‌کنیم. در اغلب این تنظیمات از مقادیر پیش‌فرض استفاده می‌کنیم؛ اما خطوط مرتبط را از کامنت درخواهیم آورد تا مقادیرشان را به صورت مشخصی تعیین کنیم.

همچنین می‌خواهیم دایرکتوری شامل داده‌های zone، لاگ‌ها و فایل pid را به طور مشخص تعیین کنیم. انواع پیکربندی‌های مختلف دیگری نیز وجود دارند که می‌توانید در این بخش تعیین کنید؛ اما سعی می‌کنیم آن‌ها را نسبتاً ساده نگهداریم. می‌توانیم تغییرات اضافی نیز ایجاد کنیم. بخش سرور ما مانند زیر خواهد بود:

server:
   do-ip4: yes
   port: 53
   username: nsd
   zonesdir: "/etc/nsd"
   logfile: "/var/log/nsd.log"
   pidfile: "/run/nsd/nsd.pid"

سپس نگاهی به بخش remote-control خواهیم داشت. البته شاید این بخش نام چندان صحیحی نداشته باشد، چون همه تنظیمات آن برای کنترل ریموت دامنه استفاده نمی‌شود. از این پیکربندی برای کنترل محلی Daemon استفاده می‌کنیم.

ابتدا باید منبع را تعیین کنیم و رابط را به صورت شماره پورت مشخص سازیم. این موارد با نام‌های فایل‌ها در هنگام اجرای دستور nsd-control-setup مطابقت دارند و نباید زمانی که از کامنت خارج می‌شوند تغییر یابند. مقادیر ما برای این بخش باید به صورت زیر باشد:

remote-control:
   control-enable: yes
   control-interface: 127.0.0.1
   control-port: 8952
   server-key-file: "/etc/nsd/nsd_server.key"
   server-cert-file: "/etc/nsd/nsd_server.pem"
   control-key-file: "/etc/nsd/nsd_control.key"
   control-cert-file: "/etc/nsd/nsd_control.pem"

سپس بخش key را پیکربندی خواهیم کرد. این بخش کلیدهای رمزی که NSD برای انتقال امن zone بین سرورهای master و slave استفاده می‌کند را شامل می‌شود. باید نام و الگوریتمی که استفاده خواهد شد را تعیین کنیم. از نام demokey در مثال خود استفاده می‌کنیم. همچنین از الگوریتم پیش‌فرض (hmac-sha256) که انتخاب شده است، استفاده خواهیم کرد.

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

dd if=/dev/random of=/dev/stdout count=1 bs=32 | base64

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

0+1 records in
0+1 records out
19 bytes (19 B) copied, 0.000571766 s, 33.2 kB/s
+kO0Vu6gC+9bxzMy3TIZVLH+fg==

کلید رمز تولید شده در خروجی فوق را کپی کنید و فایل پیکربندی را یک بار دیگر باز کنید. از این کلید به عنوان مقدار پارامتر secret استفاده کنید. در نهایت این بخش باید به صورت زیر در آمده باشد:

key:
   name: "demokey"
   algorithm: hmac-sha256
   secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="

سپس یک الگوی ساده ایجاد می‌کنیم چون مقداری اطلاعات تکراری داریم که شامل سرور slave ما می‌شود. در واقع می‌خواهیم zone‌های خود را هر بار به همان سرور slave اطلاع و انتقال دهیم و از این رو ایجاد الگو برای این کار مناسب خواهد بود. ما الگوی خود را «roslave» می‌نامیم تا مشخص شود به چه منظوری ایجاد شده است. نام و فایل هر zone را به صورت مستقل تعیین می‌کنیم تا در مورد آن در هنگام ایجاد الگو نگرانی نداشته باشیم.

می‌خواهیم پارامتر notify را در الگوی خود به صورت آدرس‌های IP سرورهای slave تنظیم کنیم. همچنین می‌خواهیم از کلیدی که تعیین کردیم برای انتقال امن zone‌ها با TSIG بهره بگیریم. پارامتر provide-xfr را دقیقاً به همین روش تعیین می‌کنیم. در انتها بخش pattern ما چیزی شبه زیر خواهد بود:

pattern:
   name: "toslave"
   notify: 192.0.2.2 demokey
   provide-xfr: 192.0.2.2 demokey

درنهایت به بخش zone می‌رسیم. در این بخش شیوه مدیریت zone‌های خاص و فایل‌های مربوطه‌شان در NSD تعیین می‌شوند. در ابتدا zone فوروارد (forward) را پیکربندی خواهیم کرد. باید این zone را به صورت zone example.com پیکربندی کنیم. این کار بسیار ساده است و کافی است خود دامنه را زیر پارامتر name بنویسیم. در ادامه نام فایل zone و همچنین الگویی که برای آن ایجاد کردیم را جهت انتقال به سرورهای slave وارد می‌کنیم. اینک zone فوروارد پایان یافته و باید چیزی شبیه زیر باشد:

zone:
   name: "example.com"
   zonefile: "example.com.zone"
   include-pattern: "toslave"

سپس به zone معکوس (reverse) می‌پردازیم. یک zone معکوس اساساً فایل zone‌ی است که به نرم‌افزار DNS امکان می‌دهد تا یک آدرس IP را به نام میزبان آن برای کلاینت نگاشت کند. به طور کلی در هاستینگ‌های مختلف این مسئله از سوی خود شرکت مدیریت می‌شود.

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

اگر علاقه‌مند هستید در این مورد بیشتر بخوانید می‌توانید به بخش «ایجاد فایل zone معکوس» در مقاله «پیکربندی Bind به عنوان سرور Authoritative-Only» مراجعه کنید. البته در ادامه روش تنظیم zone‌های معکوس در NSD را توضیح داده‌ایم؛ اما باید توجه داشته باشید که این موارد تنها در صورتی به درد شما می‌خورند که کنترل نگاشت‌های معکوس برای یک بلوک از IP-ها به شما واگذار شده باشد.

در یک zone معکوس ما از سه بخش نخست آدرس IP برای معکوس سازی آن استفاده می‌کنیم و آن‌ها را صورت زیردامنه به دامنه خاصی به نام in-addr.arpa اضافه می‌کنیم. بدین ترتیب سیستم DNS می‌تواند با استفاده از همان روش‌هایی که به دنبال دامنه می‌گردد، آدرس‌های IP را نیز جستجو کند. در مورد مثال خودمان یک zone معکوس ایجاد می‌کنیم که نگاشت 2.0.192.in-addr.arpa را ایجاد می‌کند. خصوصیات آن تا حدود زیادی شبیه zone فوروارد است:

zone:
   name: "2.0.192.in-addr.arpa"
   zonefile: "192.0.2.zone"
   include-pattern: "toslave"

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

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

اکنون باید یک فایل برای zone فوروارد ایجاد کنیم. در پیکربندی ما فایل این zone به نام «example.com.zone» است. می‌خواهیم فایلی با این نام در دایرکتوری etc/nsd/ ایجاد کنیم. این فایل را با دسترسی sudo در ویرایشگر متنی باز می‌کنیم:

sudo nano /etc/nsd/example.com.zone

نخستین کاری که باید انجام دهیم تعیین پارامترهای ابتدایی است. پارامتر ORIGIN$ را تعیین می‌کنیم. این پارامتر به دامنه‌ای اشاره می‌کند که در قالب FQDN (با نقطه انتهایی) پیکربندی می‌کنیم. همچنین باید مقدار پیش‌فرض time-to-live را نیز تعیین کنیم. از مقدار 1800 ثانیه یعنی 30 دقیقه استفاده می‌کنیم.

$ORIGIN example.com.

$TTL 1800

سپس باید SOA یعنی رکورد آغاز مرجعیت (Start of Authority) را به صورت زیر تعیین کنیم:

@       IN      SOA     ns1.example.com.      admin.example.com. (
                        2014070201        ; serial number
                        3600                    ; refresh
                        900                     ; retry
                        1209600                 ; expire
                        1800                    ; ttl
                        )

این رکورد مقادیر در سطح دامنه را تعریف می‌کند. مقدار .ns1.example.com برای تعیین موقعیت دامنه یکی از سرورهای معتبر برای این zone استفاده می‌شود. مقدار .admin.example.com برای تعیین آدرس ایمیل مدیر این zone استفاده خواهد شد. آدرس ایمیل در این مورد به صورت admin@example.com است. در فایل zone DNS نماد @ باید به صورت نقطه (.) درآید. نقطه انتهایی نیز مهم است، چون همواره یک FQDN را نشان می‌دهد.

مقادیر داخل پرانتز برخی از مشخصات zone ما را تعیین می‌کنند. تنها موردی که در این بخش برای ما مهم است شماره سری (serial number) است. این مقدار باید هر بار که تغیری در فایل zone ایجاد می‌کنید، افزایش یابد. در این مثال بدین منظور ما این مقدار را به صورت ترکیبی از تاریخ و یک عدد بازبینی می‌نویسیم.

سپس باید رکوردهای NS برای تعیین سرورهای نامی را تعیین کنیم که برای این zone معتبر محسوب می‌شوند. به خاطر داشته باشید که باید از FQDN برای اشاره به دامنه استفاده کنید، یعنی نقطه انتهایی را نیز ذکر کنید:

                    IN      NS      ns1.example.com.
                    IN      NS      ns2.example.com.

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

ns1                 IN      A       192.0.2.1
ns2                 IN      A       192.0.2.2

در نهایت باید رکوردهای A اضافی را برای میزبان‌های خودمان تعیین کنیم. در این مورد دامنه پایه (example.com) و همچنین نام میزبان www را برای نگاشت به وب‌سرور خود تعیین می‌کنیم:

@                   IN      A       192.0.2.3
www                 IN      A       192.0.2.3

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

$ORIGIN example.com.
$TTL 1800
@       IN      SOA     ns1.example.com.      admin.example.com. (
                        2014070201        ; serial number
                        3600                    ; refresh
                        900                     ; retry
                        1209600                 ; expire
                        1800                    ; ttl
                        )
; Name servers
                    IN      NS      ns1.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

; Additional A records
@                   IN      A       192.0.2.3
www                 IN      A       192.0.2.3

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

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

در این مرحله فایل مشابهی برای zone معکوس خود ایجاد می‌کنیم. به یاد داشته باشید که این مورد تنها در حالتی ضرورت دارد که مسئولیت نگاشت معکوس یک بلوک از آدرس‌ها به شما واگذار شده باشد. فایل zone معکوس که در فایل nsd.conf به آن اشاره کردیم را ایجاد کرده و آن را با دسترسی sudo در ویرایشگر متنی باز کنید:

sudo nano /etc/nsd/192.0.2.zone

سپس با تعریف کردن پارامترهای $ORIGIN و $TTL کار خود را آغاز می‌کنیم. این بار به یاد داشته باشید که origin را به زیردامنه in-addr.arpa در zone خود تعیین کنید. بدین ترتیب فایل به صورت زیر در خواهد آمد:

$ORIGIN 2.0.192.in-addr.arpa.

$TTL 1800

سپس باید رکوردهای SOA را مانند مورد قبل تعیین کنیم. می‌توان دقیقاً از همان مقادیر در این فایل استفاده کرد و همان ایمیل و سرور نام معتبر برای هر دو zone مسئول خواهند بود. به علاوه مقادیر عددی باید در این نمونه نیز کار بکنند. به یاد داشته باشید که شماره سری را هر بار که تغییری ایجاد می‌کنید، تغییر دهید:

@       IN      SOA     ns1.example.com.      admin.example.com. (
                        2014070201        ; serial number
                        3600                    ; refresh
                        900                     ; retry
                        1209600                 ; expire
                        1800                    ; ttl
                        )

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

                        IN      NS      ns1.example.com.
                        IN      NS      ns2.example.com.

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

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

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

$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
@       IN      SOA     ns1.example.com.      admin.example.com. (
                        2014070201        ; serial number
                        3600                    ; refresh
                        900                     ; retry
                        1209600                 ; expire
                        1800                    ; 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 ما پیکربندی شده است، می‌توانیم پیش‌تر برویم و فایل پیکربندی خود را تست کرده و تغییرات را پیاده‌سازی کنیم.

فیلم آموزش مقدماتی مدیریت سرور لینوکس Linux CentOS در فرادرس

کلیک کنید

ساختار فایل پیکربندی اصلی را می‌توان با استفاده از ابزار nsd-checkconf بررسی کرد. کافی است این فایل پیکربندی اصلی خود را به این ابزار معرفی کنید:

sudo nsd-checkconf /etc/nsd/nsd.conf

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

sudo service nsd restart

بدین ترتیب daemon برای NSD متوقف شده و مجدداً آغاز می‌شود. اینک می‌توانید پیام زیر را در فایل‌های لاگ مشاهده کنید:

sudo tail -f /var/log/nsd.log

ممکن است چند خطا به صورت زیر مشاهده کنید:

...

[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: received notify response error NAME ERROR from 192.0.2.2

[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: max notify send count reached, 192.0.2.2 unreachable

دلیل این خطاها آن است که NSD تلاش می‌کند تا zone را به سرور slave انتقال دهد که هنوز پیکربندی نشده است.

پیکربندی NSD برای سرور slave

اکنون با به راه افتادن سرور master می‌توانیم سرور slave را نیز پیکربندی کنیم. در این مورد نیز باید اطمینان پیدا کنیم که گواهی‌های SSL و کلیدهای ما همگی ایجاد شده و در دسترس هستند. بدین منظور باید از دستور زیر استفاده کنیم:

sudo nsd-control-setup

این مسئله تضمین می‌کند که همه فایل‌های احراز هویت مورد نیاز برای کنترل Daemon دردسترس ما هستند.

پیکربندی فایل nsd.conf

فایل nsd.conf برای سرور slave به طور عمده شبیه فایل سرور master است. تنها چند مورد هستند که باید تغییر دهیم. ابتدا فایل etc/nsd/nsd.conf/ را از سرور master به فایل etc/nsd/nsd.conf/ سرور slave کپی می‌کنیم. اینک فایل سرور slave باید به صورت زیر باشد:

server:
    do-ip4: yes
    port: 53
    username: nsd
    zonesdir: "/etc/nsd"
    logfile: "/var/log/nsd.log"
    pidfile: "/run/nsd/nsd.pid"
remote-control:
    control-enable: yes
    control-interface: 127.0.0.1
    control-port: 8952
    server-key-file: "/etc/nsd/nsd_server.key"
    server-cert-file: "/etc/nsd/nsd_server.pem"
    control-key-file: "/etc/nsd/nsd_control.key"
    control-cert-file: "/etc/nsd/nsd_control.pem"
key:
    name: "demokey"
    algorithm: hmac-sha256
    secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
pattern:
    name: "toslave"
    notify: 192.0.2.2 demokey
   provide-xfr: 192.0.2.2 demokey
zone:
    name: "example.com"
    zonefile: "example.com.zone"
    include-pattern: "toslave"
zone:
    name: "2.0.192.in-addr.arpa"
    zonefile: "192.0.2.zone"
    include-pattern: "toslave"

این دقیقاً همان چیزی است که نیاز داریم. بخش‌های server، remote-control و key از قبل به صورت کامل پیکربندی شده‌اند. مقدار secret در بخش key باید با مقدار موجود در سرور master یکی باشد از این رو محتوای فایل کامل را کپی می‌کنیم تا این شرایط را تأمین کنیم. نخستین چیزی که باید اصلاح کنیم در بخش pattern قرار دارد. این بخش که کپی کرده‌ایم خاص سرور master است و از این رو باید آن را اصلاح کنیم تا با مشخصات سرور slave همخوانی داشته باشد.

ابتدا نام آن را به چیزی تغییر می‌دهیم که مناسب سرور slave باشد. از همان منطقی که قبلاً استفاده کردیم بهره می‌جوییم و آن را frommaster می‌نامیم. همچنین باید مقادیر متغیرهای این بخش را تغییر دهیم. به جای پارامتر notify در سرورهای slave پارامتری به نام allow-notify وجود دارد که تعیین می‌کند این سرورها قبلاً اطلاع‌رسانی شده‌اند یا نه. در این مورد نیز از همان کلید استفاده می‌کنیم و از این رو نام و آدرس IP مناسب را تغییر می‌دهیم. به روش مشابه باید پارامتر provide-xfr را به request-xfr تغییر دهیم. قالب این پارامتر اندکی فرق دارد. بخش pattern در انتها چیزی شبیه زیر خواهد بود:

pattern:
    name: "frommaster"
    allow-notify: 192.0.2.1 demokey
    request-xfr: AXFR 192.0.2.1@53 demokey

در بخش zone تنها چیزی که باید اصلاح کنیم include-pattern است که با الگویی که اخیراً ایجاد کردیم مطابقت داشته باشد:

zone:
    name: "example.com"
    zonefile: "example.com.zone"
    include-pattern: "frommaster"
zone:
    name: "2.0.192.in-addr.arpa"
    zonefile: "192.0.2.zone"
   include-pattern: "frommaster"

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

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

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

sudo nsd-checkconf /etc/nsd/nsd.conf

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

sudo service nsd restart

لاگ‌ها را بررسی کنید تا مطمئن شوید که همه چیز به طور صحیحی پیش رفته است:

sudo tail -f /var/log/nsd.log

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

اینک سرورهای NSD با پیکربندی authoritative-only آماده شده‌اند و می‌توانند اطلاعات DNS دامنه شما را ارائه دهند. اما باید دامنه را نیز چنان پیکربندی کنیم که سرورهای نام را شناسایی کند.

فیلم آموزش تغییر سریع DNS در ویندوز با نرم افزار دی ان اس جامپر در فرادرس

کلیک کنید

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

زمانی که یک زیردامنه مانند example.com از دامنه com واگذار می‌شوند، باید سرورهای نامی که برای آن دامنه مسئول هستند ذکر شوند. اگر سرورهای نام درون خود دامنه باشند، می‌بایست رکورد glue نیز تعین شود. رکورد gule صرفاً یک رکورد A برای هر سرور نام است که مسئول zone واگذار شده است.

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

محلی که شرکت‌های ثبت‌کننده مختلف برای تعیین سرورهای نام دارند متفاوت است اما از آنجایی که در ایران پژوهشگاه بنیادی علوم نظری مسئول ثبت دامنه‌های ir است. روش تنظیم رکوردهای مربوطه را در وب‌سایت این سازمان توضیح داده‌ایم. در مورد مرجع ثبت دامنه‌های ir در ایران که وب‌سایت nic.ir است، باید در صفحه اصلی از منوی فوقانی به بخش دامنه‌ها> دامنه‌های من مراجعه کنید:

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

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

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

سخن پایانی

در این راهنما آموختیم که چگونه سرورهای master و slave برای سرورهای DNS به صورت authoritative-only راه‌اندازی کنیم که اطلاعات DNS را در مورد دامنه‌های ما عرضه کنند. برخلاف Bind، نرم‌افزار NSD برای ارائه رفتار authoritative با عملکرد بالا بهینه‌سازی شده است و از این رو چون به طور خاص برای نیازهای ما طراحی شده، عموماً می‌تواند عملکرد بالاتری ارائه دهد.

فیلم مجموعه آموزش مهارت های کاربردی کامپیوتر ICDL – جامع و کاربردی در فرادرس

کلیک کنید

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

• مفاهیم DNS و انواع سرورهای آن — راهنمای جامع
• مجموعه آموزش‌های مهندسی نرم افزار
• پیکربندی Bind به عنوان یک سرور کش یا فوروارد DNS روی اوبونتو — از صفر تا صد
• آموزش های شبکه های کامپیوتری
• پیکربندی Bind به عنوان سرور DNS برای درخواست های Authoritative-Only — به زبان ساده

==