بخش مهمی از بحث مدیریت پیکربندی سرور شامل تأمین روشی آسان برای بررسی رابط‌های شبکه و آدرس‌های IP بر اساس نام از طریق راه‌اندازی یک «سیستم نام دامنه» (DNS) مناسب است. استفاده از نام‌های دامنه جامع‌الشرایط (FQDN) به جای آدرس‌های IP برای اشاره به آدرس‌های داخل شبکه باعث می‌شود که پیکربندی سرویس‌ها و اپلیکیشن‌ها آسان‌تر شده و قابلیت نگهداری فایل‌های پیکربندی افزایش یابد. راه‌اندازی DNS شخصی برای شبکه خصوصی روشی عالی برای بهبود مدیریت سرورها محسوب می‌شود.

در این راهنما به بررسی شیوه راه‌اندازی سرور DNS داخلی با استفاده از نرم‌افزار سرور نام (BIND (BIND9 روی اوبونتو 18.04 می‌پردازیم. این سرور نام می‌تواند از سوی سرورهای کلاینت شما برای resolve کردن نام‌های میزبانی و آدرس‌های IP خصوصی مورد استفاده قرار گیرد. بدین ترتیب روشی متمرکز برای مدیریت نام‌های میزبانی داخلی و آدرس‌های IP خصوصی فراهم می‌شود که هنگام نیاز به گسترش محیط کاری به بیش از چند میزبان امری کاملاً ضروری به حساب می‌آید.

پیش‌نیازها

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

  • یک سرور با نسخه تازه نصب شده اوبونتو 18.04 به عنوان سرور DNS اولیه به نام ns1
  • (توصیه شده) سرور اوبونتو 18.04 دوم به عنوان سرور DNS ثانویه به نام ns2
  • سرورهای دیگر در همان دیتاسنتر که از سرورهای DNS استفاده خواهند کرد.

روی هر یک از این سرورهای اضافی باید دسترسی‌های مدیریتی از طریق کاربر sudo پیکربندی شده باشد و از یک فایروال نیز استفاده شود.

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

زیرساخت‌ها و اهداف نمونه

با توجه به اهداف این مقاله، موارد زیر جزو فرضیه‌های ما هستند:

  • ما دو سرور داریم که به عنوان سرورهای نام ما استفاده خواهند شد. در این راهنما، این سرورها را ns1 و ns2 خواهیم نامید.
  • دو سرور کلاینت دیگر نیز داریم که از زیرساخت DNS که ایجاد می‌کنیم، استفاده خواهند کرد. این سرورها را host1 و host2 می‌نامیم. البته شما می‌توانید هر تعداد سرور که دوست دارید به این زیرساخت اضافه کنید.
  • همه این سرورها در یک دیتاسنتر قرار دارند. ما فرض می‌کنیم که نام این دیتاسنتر nyc3 است.
  • همه این سرورها دارای شبکه‌بندی خصوصی هستند و در subnet 10.128.0.0./16 قرار دارند. البته شما باید این موارد را بنا به مشخصات سرورهای خودتان تغییر دهید.
  • همه سرورها به پروژه‌ای که روی دامنه «example.com» قرار دارد اتصال یافته‌اند. از آنجا که سیستم DNS ما به طور کامل داخلی و خصوصی است، نیازی به خرید یک نام دامنه نیست. با این حال استفاده از یک دامنه می‌تواند به جلوگیری از بروز تداخل با دامنه‌های قابل مسیریابی عمومی کمک کند.

با فرضیات فوق بدیهی است که طرح نام‌گذاری به نام «nyc3.example.com» برای اشاره به subnet یا zone خصوصی مناسب خواهد بود. از این رو FQDN برای host1 به صورت host1.nyc3.example.com خواهد بود. در جدول زیر جزییات مربوطه به طور کامل ارائه شده است:

میزبان نقش FQDN خصوصی آدرس IP خصوصی
ns1 Primary DNS Server ns1.nyc3.example.com 10.128.10.11
ns2 Secondary DNS Server ns2.nyc3.example.com 10.128.20.12
host1 Generic Host 1 host1.nyc3.example.com 10.128.100.101
host2 Generic Host 2 host2.nyc3.example.com 10.128.200.102

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

در انتهای این راهنما ما یک سرور DNS اصلی به نام ns1 و یک سرور DNS اختیاری ثانویه به نام ns2 خواهیم داشت که به عنوان پشتیبان عمل می‌کند. کار خود را با نصب سرور DNS اصلی آغاز می‌کنیم.

نصب BIND روی سرورهای DNS

دقت کنید مواردی که به رنگ قرمز هایلایت شده‌اند، در اغلب موارد متغیرهایی هستند که شما باید مقادیرشان را بر اساس مشخصات سرورهای خودتان جایگزین نمایید. برای نمونه اگر متغیری را به صورت host1.nyc3.example.com دیدید، باید به جای آن FQDN سرور خود را وارد کنید. به طور مشابه به جای host1_private_IP آدرس IP سرور خودتان را جایگزین کنید.

روی هر دو سرور DNS به نام‌های ns1 و ns2، بسته apt را با وارد کردن دستور زیر به‌روزرسانی کنید:

اینک BIND را نصب می‌کنیم:

تنظیم BIND در حالت IPv4

پیش از ادامه مراحل باید BIND را به حالت IPv4 تنظیم کنیم، چون شبکه‌بندی خصوصی ما به طور انحصاری از IPv4 استفاده می‌کند. روی هر دو سرور تنظیمات پیش‌فرض bind9 را با وارد کردن دستور زیر ویرایش می‌کنیم:

مقدار «4-» را به انتهای پارامتر OPTIONS اضافه می‌کنیم. بدین ترتیب به صورت زیر در می‌آید:

هنگام پایان کار، فایل را ذخیره کرده و ببندید. سپس BIND را ری‌استارت کنید تا تغییرات اعمال شوند:

اینک که BIND نصب شده است می‌توانیم سرور DNS اصلی را پیکربندی کنیم.

پیکربندی سرور DNS اصلی

پیکربندی BIND شامل چندین فایل است که همه آن‌ها در فایل پیکربندی اصلی به نام named.conf گنجانده شده‌اند. نام این فایل‌ها با named آغاز می‌شود، زیرا این نام پروسسی است که BIND اجرا می‌کند (اختصاری برای «domain name daemon» محسوب می‌شود). ما کار خود را با پیکربندی فایل options آغاز می‌کنیم.

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

روی سرور ns1 فایل named.conf.options را برای ویرایش باز کنید:

در بالاتر از بلوک options یک ACL جدید به نام «trusted» ایجاد کنید. ACL، اختصاری برای عبارت «لیست کنترل دسترسی» (access control list) است.

این همان جایی است که لیستی از کلاینت‌هایی را تعریف می‌کنیم که اجازه کوئری بازگشتی DNS را دارند. این لیست شامل سرورهای متعلق به شما در همان دیتاسنتر ns1 است. با استفاده از آدرس‌های IP خصوصی نمونه‌ای که قبلاً معرفی کردیم، ns1، ns2، host1 و hst2 را به لیست کلاینت‌های مورد اعتماد خود اضافه می‌کنیم:

اینک که لیست کلاینت‌های DNS مورد اعتماد خود را ایجاد کردیم، باید بلوک options را ویرایش کنیم. در حال حاضر آغاز بلوک مانند زیر است:

زیر دایرکتیو directory خطوط پیکربندی هایلایت شده را اضافه کنید و آدرس‌های IP سرور ns1 خود را جایگزین کنید. بدین ترتیب چیزی مانند زیر خواهد بود:

زمانی که کارتان پایان یافت، فایل named.conf.options را ذخیره کرده و ببندید. پیکربندی فوق تعیین می‌کند که صرفاً سرورهای متعلق به شما (یعنی سرورهای trusted) می‌توانند به سرورهای DNS در مورد دامنه‌های خارجی کوئری بزنند.

در ادامه فایل محلی را نیز پیکربندی می‌کنیم تا zone های DNS را تعیین کنیم.

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

روی سرور ns1 فایل named.conf.local را برای ویرایش باز کنید:

این فایل به جز چند کامنت باید چیز دیگری نداشته باشد. در این فایل زون‌های فوروارد و معکوس خود را تعیین می‌کنیم. زون‌های دی‌ان‌اس حوزه خاصی را برای مدیریت و تعریف رکوردهای DNS اختصاص می‌دهند. از آنجا که دامنه‌های ما درون زیردامنه «nyc3.example.com» قرار دارند، ما از آن به عنوان زون فوروارد خود استفاده خواهیم کرد. از آنجا که آدرس‌های IP خصوصی همگی در فضای IP 10.128.0.0/16 قرار دارند، یک زون معکوس راه‌اندازی می‌کنیم تا جستجوهای معکوس درون این محدوده را تعریف کنیم.

زون فوروارد را با خطوط زیر اضافه می‌کنیم. دقت کنید که نام‌های زون خود را جایگزین کنید و آدرس‌های IP خصوصی سرور DNS ثانویه را در دایرکتیو allow-transfer اضافه کنید:

با فرض این که subnet خصوصی به صورت 10.128.0.0/16 است، زون معکوس را با افزودن خطوط زیر می‌توانید ایجاد کنید. دقت کنید که نام‌های زون معکوس ما با 128.10 آغاز می‌شود که معکوس 10.128 است:

اگر سرورهای شما روی چند subnet گسترش یافته‌اند؛ اما همگی روی یک دیتاسنتر هستند؛ باید اطمینان حاصل کنید که یک زون اضافی و همچنین فایل زون برای هر subnet متمایز ایجاد کرده‌اید. زمانی که ویرایش همه زون‌های مطلوب پایان یافت، فایل named.conf.local را ذخیره کرده و ببندید.

اینک که زون‌ها در BIND مشخص شدند، باید فایل‌های زون فوروارد و معکوس متناظر را ایجاد کنیم.

ایجاد فایل forward zone

فایل زون فوروارد جایی است که رکوردهای DNS برای بررسی‌های دی‌ان‌اس فوروارد ذخیره می‌شوند. یعنی برای مثال هنگامی که DNS یک کوئری نام برای «host1.nyc3.example.com» دریافت می‌کند، در فایل زون فوروارد به دنبال آدرس IP متناظر برای resolve کردن host1 می‌گردد.

ابتدا یک دایرکتوری ایجاد می‌کنیم تا فایل‌های زون خود را درون آن قرار دهیم. بر اساس پیکربندی named.conf.local، این مکان باید etc/bind/zones/ باشد:

اینک فایل زون فوروارد خود را بر اساس فایل زون نمونه db.local طراحی می‌کنیم. آن را بر اساس دستورهای زیر به مکان مناسبی کپی کنید:

اینک فایل فوروارد خود را ویرایش می‌کنیم:

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

در اولین گام باید رکورد SOA را ویرایش کنیم. بنابراین FQDN سرور ns1 را به جای localhost قرار می‌دهیم و سپس root.localhost را با admin.nyc3.example.com جایگزین می‌کنیم. هر زمان که یک فایل زون را ویرایش می‌کنید، باید شماره سریال آن را پیش از ری‌استارت کردن پروسس named افزایش دهید. ما این مقدار را به 3 افزایش می‌دهیم و بنابراین به صورت زیر در می‌آید:

سپس سه رکورد انتهای فایل (پس از SOA) را حذف می‌کنیم. اگر مطمئن نیستید که کدام خط‌ها را باید حذف کنید، دقت کنید که در بخش فوق آن‌ها را با «delete this line» مشخص ساخته‌ایم.

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

اینک رکورد A را به میزبان‌هایی که به این زون تعلق دارند اضافه کنید. این مورد شامل همه سرورهایی است که می‌خواهیم نام آن‌ها با «nyc3.example.com» خاتمه یابد. دقت کنید که باید نام‌ها و آدرس‌های IP خصوصی مورد نظر خودتان را جایگزین کنید. رکوردهای A را برای ns1، ns2، host1 و host2 با استفاده از نام‌ها و آدرس‌های IP خصوصی مورد نظر این راهنما، به صورت زیر اضافه کرده‌ایم:

فایل db.nyc3.example.com را ذخیره کرده و خارج شوید. فایل زون فوروارد نمونه نهایی در انتها به صورت زیر خواهد بود:

اینک به پیکربندی فایل‌(های) زون معکوس می‌پردازیم:

ایجاد فایل(های) Reverse Zone

زون معکوس که رکوردهای DNS PTR در آن تعریف می‌شود، به منظور پاسخ‌دهی به جستجوهای DNS معکوس هست. یعنی هنگامی که DNS یک کوئری برای مثال بر اساس آدرس 10.128.100.101 دریافت می‌کند به فایل (های) زون معکوس نگاه می‌کند تا FQDN متناظر را که در این مورد «host1.nyc3.example.com» است، بیابد.

روی سرور ns1 برای هر زون معکوس که در فایل named.conf.local تعیین شده است، یک فایل زون معکوس ایجاد می‌کنیم. فایل (های) زون معکوس بر اساس فایل زون نمونه db.127 ایجاد می‌شوند. آن را با دستور زیر به مکان مناسبی کپی کنید. دقت کنید که فایل زون معکوس خود را طوری نام‌گذاری کنید که متناسب با تعریف زون معکوس شما باشد:

فایل زون معکوس را که متناظر با زون (های) معکوس تعریف شده در named.conf.local است ویرایش می‌کنیم:

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

همانند روش ویرایش فایل زون فوروارد باید رکورد SOA را تغییر داده و مقدار سریال را یک واحد افزایش دهیم. بدین ترتیب فایل به صورت زیر در می‌آید:

اینک دو رکورد انتهای فایل (پس از رکورد SOA) را ویرایش می‌کنیم. اگر مطمئن نیستید که کدام خط‌ها باید حذف شوند؛ این خطوط با کامنت «delete this line» در بخش فوق مشخص شده‌اند.

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

سپس رکوردهای PTR را برای همه سرورهایی که آدرس IP آن‌ها در subnet فایل زون مورد ویرایش قرار دارد، اضافه کنید. در مثالی که ما بررسی می‌کنیم این موارد شامل همه میزبان‌ها می‌شوند، زیرا همه آن‌ها در subnet با آدرس 10.128.0.0/16 قرار دارند. توجه داشته باشید که ستون نخست شامل دست‌کم دو بخش از آدرس IP خصوصی سرور به طور معکوس است. مطمئن شوید که تام‌ها و آدرس IP خصوصی خودتان را جایگزین می‌کنید:

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

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

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

بررسی ساختار پیکربندی BIND

دستور زیر را برای بررسی ساختار فایل‌های named.conf* اجرا کنید:

اگر فایل‌های پیکربندی named شما دارای خطاهای ساختاری نباشند، بدون مشاهده هیچ گونه خطایی به خط اعلان فرمان باز می‌گردید. اما اگر مشکلاتی در فایل‌های پیکربندی وجود داشته باشند، باید پیام خطا را بررسی کرده و به بخش «پیکربندی سرور DNS اصلی» این راهنما بازگشته و پس از رفع خطا مجدداً دستور named-checkconf را اجرا کنید.

دستور named-checkzone برای بررسی صحیح بودن فایل‌های زون اجرا می‌شود. آرگومان نخست این دستور نام یک زون است و آرگومان دوم نیز فایل زون متناظر با آن خواهد بود که هر دو باید در فایل named.conf.local تعریف شده باشند.

برای نمونه جهت بررسی پیکربندی زون فوروارد «nyc3.example.com»، دستور زیر را اجرا کنید. دقت کنید که موارد هایلایت شده را با مشخصات سرورهای خودتان جایگزین کنید:

برای بررسی پیکربندی زون معکوس «128.10.in-addr.arpa»، دستور زیر را اجرا کنید. عددها را تغییر دهید تا متناظر با زون معکوس و فایل شما باشند:

زمانی که مطمئن شدید همه فایل‌های پیکربندی و زون بدون خطا هستند، آماده هستید تا سرویس BIND را ری‌استارت کنید.

ری‌استارت کردن BIND

با دستور زیر BIND را ری‌استارت کنید:

اگر فایروال UFW را فعال کرده‌اید، دسترسی به BIND را با دستور زیر باز کنید:

سرور DNS اصلی شما اینک راه‌اندازی شده و به کوئری‌های DNS پاسخ می‌دهد. پس در ادامه به پیکربندی و راه‌اندازی سرور DNS ثانویه می‌پردازیم.

پیکربندی سرور DNS ثانویه

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

روی سرور ns2 فایل named.conf.options را باز کنید:

در ابتدای فایل، ACL را با آدرس‌های IP خصوص همه سرورهای مورد اعتماد ایجاد کنید:

زیر دایرکتیو directory خطوط زیر را اضافه کنید:

فایل named.conf.options را ذخیره کرده و ببندید. اینک این فایل باید دقیقاً مانند فایل named.conf.options روی سرور ns1 باشد، به جز این که طوری پیکربندی شده است تا به آدرس IP خصوصی ns2 گوش دهد. سپس فایل named.conf.local را باز کنید:

زون‌هایی که متناظر با زون‌های master روی سرور DNS اصلی هستند تعریف کنید. توجه داشته باشید که در این مورد نوع برابر با «slave» خواهد بود و بنابراین فایل شامل مسیر نیست و دایرکتیوهای masters وجود دارند که باید برابر با آدرس IP خصوصی DNS اصلی تنظیم شوند. اگر چندین زون معکوس در سرور DNS اصلی تعریف کرده‌اید، باید مطمئن شوید که همه آن‌ها را در این جا اضافه کرده‌اید:

اینک فایل named.conf.local را ذخیره کرده و ببندید. دستور زیر را برای بررسی درستی فایل‌های پیکربندی اجرا کنید:

زمانی که بررسی پایان یافت، BIND را ری‌استارت کنید:

با تغییر دادن فایروال UFW به صورت زیر به اتصال DNS اجازه عبور بدهید:

اینک سرورهای DNS اصلی و ثانویه برای resolve کردن شبکه خصوصی و آدرس‌های IP مربوطه پیکربندی شده است. در ادامه سرورهای کلاینت را برای استفاده از سرورهای DNS خصوصی پیکربندی می‌کنیم.

پیکربندی کلاینت‌های DNS

پیش از آن که همه سرورهای موجود در ACL به نام «trusted» بتوانند به سرورهای ACL کوئری بزنند، باید هر یک از آن‌ها را برای استفاده از ns1 و ns2 به عنوان سرورهای نام پیکربندی کنیم. این فرایند به نوع سیستم عامل بستگی دارد؛ اما در مورد اغلب توزیع‌های لینوکس شامل افزودن سرورهای نام به فایل /etc/resolv.conf است.

کلاینت‌های اوبونتو 18.04

شبکه‌بندی روی سیستم عامل اوبونتو 18.04 با استفاده از Netplan پیکربندی می‌شود که امکان نوشتن پیکربندی شبکه استاندارد شده و اِعمال آن در مورد نرم‌افزار شبکه‌بندی ناسازگار بک‌اند (backend) را می‌دهد. برای پیکربندی DNS، باید فایل پیکربندی Netplan را ویرایش کنیم.

ابتدا دایرکتیو مرتبط با شبکه خصوصی خود را با کوئری کردن subnet خصوصی با دستور ip address بیابید:

خروجی

در این مثال، رابط خصوصی eth1 نام دارد. سپس فایلی به نام 00-private-nameservers.yaml در مسیر /etc/netplan ایجاد می‌کنیم:

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

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

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

خروجی

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

اینک resolver DNS سیستم را بررسی کنید تا مشخص شود که آیا پیکربندی DNS اعمال شده است یا نه:

به سمت پایین اسکرول کنید تا بخشی که به رابط شبکه خصوصی شما مربوط است را ببینید. احتمالاً آدرس‌های IP خصوصی سرورهای DNS در ابتدا فهرست شده‌اند و سپس مقادیر fallback آماده است. دامنه شما باید در بخش «DNS Domain» مشاهده شود:

خروجی

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

کلاینت‌های اوبونتو 16.04 و دبیان

روی سرورهای لینوکس اوبونتو 16.04 و دبیان، شما باید فایل /etc/network/interfaces را ویرایش کنید:

درون این فایل خط dns-nameservers را یافته و سرورهای نام خود را به ابتدای فهرست اضافه کنید. زیر این خط یک گزینه dns-search اضافه کنید که به دامنه اصلی زیر ساخت شما اشاره می‌کند. در مورد این راهنما این گزینه برابر با «nyc3.example.com» است:

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

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

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

خروجی

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

دران بخش باید سرورهای نام و همچنین دامنه جستجوی خود را در فایل /etc/resolv.conf ببینید:

خروجی

اینک کلاینت شما طوری پیکربندی شده است که از سرورهای DNS استفاده کند.

کلاینت‌های CentOS

روی سرورهایی که توزیع‌های CentOS، RedHat و Fedora را اجرا می‌کنند باید فایل /etc/sysconfig/network-scripts/ifcfg-eth0 را ویرایش کنید. دقت کنید که به جای eth0 باید نام رابط شبکه خصوصی خود را وارد کنید:

به دنبال گزینه‌های DNS1 و DNS2 بگردید و آن‌ها را برابر با آدرس‌های IP خصوصی سرورهای نام اصلی و ثانویه خود تعیین کنید. یک پارامتر DOMAIN اضافه کنید که به دامنه اصلی زیر ساخت شما اشاره می‌کند. در این راهنما ما از مقدار «nyc3.example.com» استفاده می‌کنیم:

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

این دستور ممکن است چند ثانیه معلق بماند؛ اما پس از مدت اندکی به اعلان باز می‌گردید. در این مرحله با وارد کردن دستور زیر بررسی کنید که تغییرات اعمال شده است یا نه:

در خروجی باید سرورهای نام و دامنه جستجو را مشاهده کنید:

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

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

با استفاده از nslookup می‌توانید بررسی کنید که کلاینت‌ها قادر به کوئری زدن به سرورهای نام هستند یا نه. این وضعیت را روی همه کلاینت‌هایی که در ACL با نام «trusted» ذکر شده‌اند بررسی کنید. در مورد کلاینت‌های CentOS، باید این ابزار را نصب کنید:

ابتدا با یک جستجوی فوروارد آغاز می‌کنیم

برای نمونه ما می‌توانیم با دستور زیر یک جستجوی فوروارد برای بازیابی آدرس IP نام host1.nyc3.example.com اجرا کنیم:

کوئری کردن host1 به host1.nyc3.example.com بسط می‌یابد، زیرا گزینه search به زیردامنه خصوصی شما تعیین شده است و کوئری‌های DNS تلاش می‌کنند تا زیردامنه را پیش از گشتن جاهای دیگر بررسی کنند. خروجی دستور فوق به صورت زیر خواهد بود:

خروجی

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

برای تست کردن Reverse Lookup باید آدرس IP خصوصی host1 را کوئری کنیم:

در خروجی دستور فوق چیزی مانند زیر را باید مشاهده کنید:

خروجی

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

اینک شما موفق شده‌اید سرورهای DNS داخلی را به طرز صحیحی راه‌اندازی کنید. در ادامه مواردی در خصوص مبحث نگهداری رکوردهای زون را ارائه می‌کنیم.

نگهداری رکوردهای DNS

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

افزودن میزبان به DNS

هر زمان که یک میزبان را به محیط خود (در همان دیتاسنتر) اضافه می‌کنید باید آن را به DNS نیز اضافه کنید. فهرستی از مراحل این کار را در ادامه می‌بینید:

سرور نام اصلی

  • فایل زون فوروارد: یک رکورد A برای میزبان جدید اضافه کنید و مقدار سریال را افزایش دهید.
  • فایل زون معکوس: یک مقدار PTR برای میزبان جدید اضافه کنید و مقدار سریال را افزایش دهید.
  • آدرس IP خصوصی میزبان جدید را به ACL با عنوان «trusted» اضافه کنید (named.conf.options).

در نهایت فایل‌های پیکربندی را تست کنید:

سپس BIND را مجدداً بارگذاری نمایید:

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

سرور نام ثانویه

آدرس IP خصوصی میزبان جدید را به ACL با عنوان «trusted» اضافه کنید (named.conf.options).

ساختار پیکربندی را بررسی کنید:

سپس BIND را مجدداً بارگذاری کنید:

اینک سرور ثانویه اتصال‌ها از میزبان جدید را می‌پذیرد.

پیکربندی میزبان جدید برای استفاده از DNS

  • فایل etc/resolv.conf/ را طوری پیکربندی کنید تا از سرورهای DNS استفاده کند.
  • با استفاده از nslookup تست کنید.

حذف میزبان از DNS

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

سخن پایانی

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

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

اگر این مطلب برایتان مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

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

بر اساس رای 4 نفر

آیا این مطلب برای شما مفید بود؟

یک نظر ثبت شده در “پیکربندی BIND به عنوان سرور DNS خصوصی روی اوبونتو — راهنمای جامع

  • جناب لطفی مقاله خیلی مفصل و کاملی بود
    من دو روز در اینترنت دنبال مقاله ی خوبی در مورد تنظیم dns می گشتم که به مقاله شما برخوردم. واقعا مقاله خوب و مفیدی بود و خوب نوشته شده بود.

    موفق و پیروز باشید

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *