در این آموزش نحوه راه اندازی Authoritative only DNS را با استفاده از Bind9 را مرور خواهیم کرد. برای آشنایی بیشتر با DNS و ساختار آن می توانید به این مقاله در ویکی پدیا مراجعه نمائید.
آماده سازی DNS سرورها
در این آموزش من قصد دارم از دو سرور استفاده کنم. یکی برای ایفای نقش DNS اصلی یا master و دیگری برای ایفای نقش سرور ثانویه یا Slave استفاده خواهد شد. سروری که نقش Slave را ایفا خواهد کرد، اطلاعات مربوط به زون ها را از طریق Zone Transfer در یافت خواهد کرد و در نبود سرور Master می تواند پاسخگوی درخواست های ورودی باشد.
بر خلاف DNS های Forwarder یا Cash DNS ها، DNS ها Authoritative DNS تنها به درخواست های iterative پاسخ می دهد که برای آنها جوابی داشته باشد. به این معنی که این نوع DNS ها تنها در صورتی پاسخگو خواهند بود که برای دامنه مربوطه Zone ی موجود داشته باشد و در آن Zone رکوردی مرتبط ثبت شده باشد.
از انجایی که این نوع سرور ها تنها در مقابل دامنه ها (zone) های موجود در خود وظیفه پاسخگویی دارند، معمولا دارای بار کمی خواهند بود.
در ادامه برای ایجاد DNS سرور های مورد نظر، از دامنه maaleki.com به عنوان مثال استفاده خواهد شد.
| IP Address | نام سرور | نقش سرور |
| 172.20.1.10 | Ns1.maaleki.ir | Master Name Server |
| 172.20.1.11 | Ns2.maaleki.ir | Slave Name Server |
قبل از شروع آموزش نیاز است تا Hostname هر سرور را به درستی تنظیم کنیم.
فایل Hosts را از مسیر /etc/hosts با یکی از ویرایشگر های مورد علاقه باز میکنیم. محتویات فایل باید به شکل زیر باشد.
127.0.0.1 localhost 127.0.0.1 ns1 ns1
که می بایست خط دوم آن را به شکل زیر ویرایش نمائیم تا بیانگر نام هاست و دامنه آن برای IP باشد. برای سرور Master ما خط دوم را به شکل زیر ویرایش میکنیم.
127.0.0.1 localhost 172.20.1.10 ns1.maaleki.com ns1
پس از ذخیره کردن تغییرات بالا نیاز است تا فایل /etc/hostname نیز ویرایش گردد.
sudo nano /etc/hostname ns1
برای اعمال تغییرات نیز از دستور زیر استفاده می کنیم.
hostname -F /etc/hostname
همین مراحل باید برای سرور Slave نیز طی شود با این تفاوت که به جای ns1 از ns2 استفاده میکنیم.
نصب Bind
در ادامه کار نیاز است تا Bind بر روی هر دو سرور نصب گردد. پکیج های مربوطه به Bind معمولا در repository پیش فرض توزیع های مختلف وجود دارد بنابراین بدون مشکل نسبت به نصب آن ها از طریق Repository پیش فرض و با دستور زیر بر روی هر دو سرور اقدام میکنیم.
yum install bind bind-utils
پس از این که بسته ها نصب گردیدند پیکربندی سرور ns1 یا همان master را با مراحل زیر انجام خواهیم داد. که شامل چندید فایل است از فایل اصلی یعنی named.conf آدرس دهی خواهند شد. این فایل ها تنظیمات اصلی DNS بودهو با نام named شروع خواهند شد این نام گذاری به این علت است که پروسس اصلی که Bind اجرا خواهد کرد named نام دارد.در مرحله اول نیاز است که فایلnamed.conf را که در میسر /etc/named.conf قرار دارد را ویرایش کنیم و Option های عنوان شده را به شکل زیر تغییر دهیم. .
options {
listen-on port 53 {any;};
listen-on-v6 port 53 {any;};
recursion no;
notify yes;
also-notify { 172.20.1.11; };
allow-transfer { 172.20.1.11; };
که در آن listen-on port 53 و listen-on-v6 port 53 به جهت پاسخگویی به تمامی درخواست های ورودی به صورت any خواهد بود.
از آنجایی که قصد نداریم تا DNS به درخواست های Recursive پاسخ دهد، recursion را برابر با no قرار می دهیم.
Notify نیز به جهت ارسال Notification به سرور Slave برای آگاه سازی آن از تغیرات Zone ها برابر با yse خواهد بود.
در also-notify و allow-transfer نیز آدرس سرور یا سرور های slave را که معرفی می کنیم.
جهت امنیت بیشتر و جلوگیری از دریافت اطلاعات اضافی از ورژن bind توسط کاربران نیز خط زیر را نیز اضافه کنید. در این صورت کاربران با کوئری گرفتن از ورژن bind پیغام مورد نظر شما را دریافت خواهند کرد.
version "Not available";
در انتهای فایل نیز نیاز است خط زیر اضافه شود.
include "/etc/named/named.conf.local";
در ادامه وارد فایل named.conf.local در مسیر /etc/named/named.conf.local می شویم و Zone مورد نظر را به شکل زیر ایجاد میکنیم.
zone "maaleki.com" {
type master;
file /etc/named/zones/db.maaleki.com";
allow-transfer { 172.20.1.11; };
};
تصور کنید ما رنجی از IP نیز دارین که میخواهیم برای آنها PTR رکورد نیز داشته باشیم تا امکان Reverse query نیز فراهم باشد.
پس zone مربوط به آن را نیز به شکل زیر در همین فایل اضافه میکنیم.
zone "1.168.192.in-addr.arpa" {
type master;
file /etc/named/zones/db.1.168.192.in-addr.arpa";
allow-transfer { 172.20.1.11; };
};
در انتها پس از معرفی زون های مورد نظر فایل را ذخیره می کنیم و به سراغ ایجاد دیتابیس هر زون می رویم.
برای ایجاد زون maaleki.com و معرفی رکورد های آن به سراغ ایجاد فایل db.maaleki.com می رویم. از این پس سرور با دریافت درخواست های ورودی مرتبط با دامنه فرضی ما(مثل mail.maaleki.com)، در این فایل به دنبال رکورد های مرتبط خواهد گشت.
ما در فایل named.conf.local مسیر /etc/named/zones را به عنوان دیتابیس هر دو زون تعریف شده عنوان کرده ایم در صورتی که این مسیر در حال حاضر وجود ندارد. لذا در ابتدا نیاز است این مسیر را ایجاد کنیم.
برای این کار از دستورات زیر استفاده می کنیم.
sudo chmod 755 /etc/named sudo mkdir /etc/named/zones
فایل زون مرتبط با maaleki.com را با دستور و شکل عنوان شده در زیر ایجاد میکنیم.
sudo vi /etc/named/zones/db.maaleki.com
در فایل مذکور ابتدا باید رکورد SOA یا Server of Authority را معرفی نمود. با هر بار ویرایش این فایل، برای این که بتوان سرویس را از تغییرات آپاه کرد نیاز است تا شماره سریال زون به روز رسانی شود. در واقع حداقل یک واحد به مقدار آن افزوده شود. به طور معمول نحوه وارد کردن شماره سریال به صورت زیر است.
YYYYMMDDNN
یعنی تاریخ و شماره تغییر مانند 2018010112 که به معنی ویرایش دوازدهم در تاریخ یکم ژانویه 2018 می باشد.
در نهایت با افزودن رکورد های مورد نظر فایل شما باید به صورت زیر باشد.
$TTL 2d @ IN SOA ns1.maaleki.com. admin.maaleki.com. ( 2018010201 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; name servers - NS records IN NS ns1.maaleki.com. IN NS ns2.maaleki.com. ; name servers - A records ns1. maaleki.com. IN A 10.128.10.11 ns2. maaleki.com. IN A 10.128.20.12 ; A records host1.maaleki.com. IN A 192.16.10.10 host2 IN A 192.168.10.15 mail IN A 172.17.15.20
ساخت Revers Zone
در Revers زون ها رکورد های PTR معرفی می شوند که بیانگر نام معادل هر IP آدرس می باشد. وجود اینگونه رکورد ها برای برخی سرویس ها مانند Mail Server ها الزامی می باشد.
به ازای هر زونی که در فایل named.conf.local معرفی کرده اید می بایست یک Zone ایجاد نمائید. در اینجا آدرس فرضی ما 192.168.1.0/24 است که زون آن را به صورت زیر ایجاد می کنیم.
sudo vi /etc/named/zones/ db.1.168.192.in-addr.arpa
و پیکر بندی را به صورت زیر انجام می دهیم.
$TTL 604800
@ IN SOA ns1.maaleki.com. admin.maaleki.com. (
2018010112 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.maaleki.com.
; PTR Records
10 IN PTR host10.maaleki.com.
12 IN PTR host11.maaleki.com.
101 IN PTR mail.maaleki.com.
102 IN PTR dl.maaleki.com.
نکته: در تعریف رکورد ها با نام کامل چه در Forward Zone و چه درReverse zone فراموش نکنید تا در انتهای اسم هر رکورد “.” قرار داشته باشد. این dot بیانگر top Level رکورد می باشد. در صورتی که فراموش کنید در انتهای رکوردی dot قرار دهید عملا رکوردی اشتباه ثبت کرده اید که در Froward Zone پاسخی به آن داده نخواهد شد و در Reverse Zone سرور به درخواست به شکل زیر پاسخ خواهد داد.
بررسی صحت پیکربندی
برای بررسی صحت پیکربندی و صحت تعریف زون ها می توان از ابزار های خود bind استفاده کرد. دستور زیر صحت پیکربندی سرویس را بررسی خواهد کرد.
sudo named-checkconf
توجه داشته باشید که ما در انتهای فایل named.conf در خطی به named.conf.local اشاره می کنیم. این در صورتی که خطایی در پیکربندی این فایل وجود داشته باشد با اجرای دستور فوق خطاهای احتمالی فایل مذکور نیز نمایش داده می شود. به عنوان نمونه خطایی عمدی در پیکربندی فایل named.conf.local ایجاد میکنیم تا خروجی دستور را مشاهده کنید.
جهت بررسی صحت تنظیمات زون فایل
با استفاده از دستور named-checkzone می توان صحت زون فایل را بررسی نمود در پس این دستور می بایست ابتدا نام زون و سپس آدرس فایل آن را وارد نمائید. مانند شکل زیر
در صورتی که در هیچکدام از زون ها و فایل های پیکربندی با دستورات پیغام خطایی مشاهده نشد، میتوان سرویس را راه اندازی کرد.
راه اندازی سرویس bind
برای راه اندازی سرویس bind از دستور زیر استفاده می کنیم.
sudo systemctl start named
پس از راه اندازی سرویس برای این که سرویس در هر بار راه اندازی، به صورت خودکار راه اندازی شود از دستور زیر استفاده می کنیم.
sudo systemctl enable named
پیکربندی سرویس اصلی به اتمام رسید حال میتوان صحت عملکرد سرویس را بررسی نمود.
در اینجا با استفاده از nslookup در ویندوز صحت عملکرد سرویس را بررسی خواهیم کرد. برای این کار در محیط command prompt می شویم و دستور nslookup را وارد می کنیم.
در محیط nslookup دستور زیر را وارد میکنیم. با وارد کردن این دستور درخواست ها از سرور مورد نظر سوال خواهد شد نه از DNS پیش فرض سیستم.
C:\Users\hamed >nslookup >server 172.20.1.10 Default Server: [172.20.1.10] Address: 172.20.1.10
پیکربندی سرور دوم یا Slave
در اکثر محیط های عملیاتی، از دو سرور جهت پاسخ دهی به درخواسته ای DNS استفاده می شود. تا در صورت از دسترس خارج شدن سرور اول، سرور جایگزینی برای پاسخگویی به درخواست ها وجود داشته باشد.
در سرور دوم وارد فایل named.conf شده و پیکر بندی آن را همانند سرور اصلی انجام می دهیم با این تفاوت که به در این سرور گزینه allow transfer می بایست none باشد.
sudo vi /etc/named.conf
فراموش نکنید که خط زیر را نیز در انتهای فایل قرار دهید.
include "/etc/named/named.conf.local";
حال نیاز است همانند سرور اول فایل named.conf.local را ایجاد کرده و زون ها را در آن تعریف کرد.
sudo chmod 755 /etc/named
sudo vi /etc/named/named.conf.local
تفاوتی که این فایل با سرور اصلی دارد در این است که نوع زون ها در این سرور slave خواهد بودو مسیری به عنوان دیتابیس زون به آن معرفی نمی گردد. و سرور master که مسئولیت زون را دارد نیز به آن معرفی گردد.
توجه داشته باشید که تنها زون هایی بین دو سرور تبادل می شوند که در فایل named.local معرفی شده باشند.
zone "maaleki.com" {
type slave;
file "slaves/db.maaleki.com";
masters { 172.20.1.10; }; # ns1 private IP
};
zone "1.168.192.in-addr.arpa" {
type slave;
file "slaves/db.1.168.192.in-addr.arpa ";
masters { 172.20.1.10; }; # ns1 private IP
};
پس از ذخیره سازی تغییرات نیاز است در این سرور هم همانند سرور اول صحت پیکربندی را بررسی کنیم.
sudo named-checkconf
در صورتی که خطایی وجود نداشت میتوانیم سرویس را start کنیم.
sudo systemctl start named
همانند سرور اول، در این سرور نیز باید سرویس به صورت اتوماتیک در هر بار بوت شروع به کار نماید.
sudo systemctl enable named
هر دو سرور ما آماده فعالیت می باشند. از پس اگر قصد اضافه کردن زونی را دارید، ابتدا می بایست آن را در فایل named.conf.local هر ماشین معرفی نمائید. سپس فایل دیتابیس ان را در ماشین اصلی ایجاد نمائید. در اولین transfer محتویات فایل به صورت اتوماتیک به سرور دوم نیز منتقل می شود. البته میتوان این عملیات را به صورت دستی نیز انجام داد تا مدت زمان انتظار برای اگاهی سرور دوم از تغییرات سرور اصلی کاسته شود.
در صورتی که زون جدیدی اضافه شد با دستور زیر سرویس مجددا فایل های پیکربندی خود را خوانده و از تغییرات آگاه خواهد شد.
rndc reconfig
در صورتی که رکورد جدیدی به هر زون اضافه گردید می بایست شماره سریال آن زون را افزایش داد چرا تشخیص این که زون دچار تغییری شده است بر اساس این شماره سریال خواهد بود. سرور دوم نیز با چک کردن این شماره سریال و مقایسه آن با شماره سریال زون دریافت شده در قبل است که تشخیص می دهد تغییری در زون ایجاد شده است یا خیر. اگر شماره سریال تغییری نداشته باشد فرض بر این می شود که زون نیز تغییری نکرده است.
پس از به روز رسانی زون، با استفاده از دستور زیر سرویس مجددا اطلاعات زون را خواهد خواند در نتیجه از تغییرات اعمال شده اگاه خواهد شد.
rndc reload maaleki.com
با استفاده از دستور زیر نیز سیستم اجبار خواهد شد تا نسبت به آگاه سازی سرور دوم از تغییرات اقدام نماید.
rndc notify maaleki.com
امیدوارم مفید واقع شود.
