پیکربندی Bind به عنوان یک سرور کش یا فوروارد DNS روی اوبونتو — از صفر تا صد

۲۹۷ بازدید
آخرین به‌روزرسانی: ۲۲ شهریور ۱۴۰۲
زمان مطالعه: ۱۲ دقیقه
پیکربندی Bind به عنوان یک سرور کش یا فوروارد DNS روی اوبونتو — از صفر تا صد

DNS یا «سیستم نام دامنه» غالباً جزو اجزایی محسوب می‌شود که یادگیری آن هنگام پیکربندی وب‌سایت‌ها و سرورها دشوار است. با این که اغلب مرم احتمالاً دوست دارند از سرورهای DNS ارائه شده از شرکت‌های هاستینگ یا ثبت کننده دامنه‌شان استفاده کنند؛ اما ایجاد سرورهای DNS شخصی نیز مزایای زیادی دارد.

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

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

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

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

برای این که در این راهنما بتوانید با ما همراه باشید باید به دو رایانه (که دست‌کم یکی از آن‌ها سرور اوبونتو است) دسترسی داشته باشید. یکی از این سرورها به عنوان کلاینت عمل می‌کنند و دیگری به صورت سرور DNS پیکربندی شده است. جزییات پیکربندی نمونه ما به صورت زیر است:

نقشآدرس IP
DNS Server192.0.2.1
Client192.0.2.100

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

سرور کش DNS

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

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

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

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

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

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

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

نصب Bind روی سرور DNS

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

sudo apt-get update

sudo apt-get install bind9 bind9utils bind9-doc

پس از نصب اجزای Bind می‌توانیم شروع به پیکربندی سرور بکنیم. سرور فوروارد از پیکربندی سرور کش به عنوان نقطه شروع استفاده می‌کند، بنابراین صرف نظر از هدف نهایی، پیکربندی سرور در ابتدا به عنوان یک سرور کش صورت می‌گیرد.

پیکربندی به صورت یک سرور کش

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

فایل‌های پیکربندی Bind در یک دایرکتوری پیش‌فرض در مسیر /etc/bind قرار دارند. آن‌ها را به دایرکتوری زیر انتقال دهید:

cd /etc/bind

اغلب فایل‌هایی که در این دایرکتوری قرار دارند، ربطی به این راهنما ندارند. فایل اصلی پیکربندی named.conf نام دارد (در واقع named و bind دو نام برای یک اپلیکیشن واحد هستند.) این فایل صرفاً منبعی برای فایل‌های named.conf.options، named.conf.local و named.conf.default-zones محسوب می‌شود.

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

sudo nano named.conf.options

کامنت ها برای خوانایی بیشتر حذف شده‌اند و بدین ترتیب فایل فوق به صورت زیر باید باشد:

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

       dnssec-validation auto;

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

برای پیکربندی کش، گام نخست راه‌اندازی یک فهرست کنترل دسترسی یا ACL به معنی (access control list) است.

از آنجا که سرور DNS به منظور resolve کردن کوئری‌های بازگشتی استفاده می‌شود، نمی‌خواهیم کاربران خرابکار از آن سوء استفاده بکنند. یک حمله به نام «حمله DNS amplification» به طور خاص بسیار دردسرساز است، زیرا می‌تواند باعث شود سرور شما در حمله‌های توزیع یافته انکار سرویس DDOS مشارکت داشته باشد.

حمله DNS amplification یکی از روش‌هایی است که کاربران خرابکار به وسیله آن سرورها یا سایت‌های روی اینترنت را از کار می‌اندازند. آن‌ها بدین منظور به دنبال سرورهای DNS ی می‌گردند که کوئری‌های بازگشتی را resolve کنند. آن‌ها آدرس IP قربانی را مورد سوء استفاده قرار می‌دهند و یک درخواست کوئری می‌کنند که پاسخ بزرگی به سرور DNS باز می‌گرداند. بدین ترتیب سرور DNS به درخواست‌های کوچک با پاسخ‌هایی با حجم بالا پاسخ می‌دهد که به سمت سرور قربانی هدایت شده‌اند و به طرز مؤثری پهنای باند موجود حمله کننده را تقویت می‌کنند.

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

در بالاتر از بلوک Options یک بلوک جدید به نام acl ایجاد کنید. یک نام برای آن گروه ACL که می‌خواهید پیکربندی کنید ایجاد نمایید. در این راهنما گروه خود را goodclients می‌نامیم.

acl goodclients {
};
options {
...

درون این بلوک فهرست آدرس‌های IP یا شبکه‌هایی که باید اجازه استفاده از سرور DNS را داشته باشند ذکر می‌کنیم. از آنجا که هم سرور ما و هم کلاینت درون یک زیرشبکه 24/ کار می‌کنند، می‌توانیم مثال خود را به همین شبکه محدود کنیم. همچنین localhost و localnets را که تلاش می‌کنند این کار را به طور خودکار انجام دهند اضافه می‌کنیم.

acl goodclients {
   192.0.2.0/24
   localhost;
   localnets;
};
options {
   ...

اینک که یک ACL از کلاینت‌هایی داریم که می‌خواهیم درخواست را برایشان resolve کنیم می‌توانیم آن قابلیت‌هایی که در بلوک Options قرار دارند را پیکربندی نماییم. درون این بلوک خطوط زیر را اضافه می‌کنیم.

options {
       directory "/var/cache/bind";
       recursion yes;
      allow-query { goodclients; };
       ...

ما به طور خاص امکان «کوئری بازگشتی» را باز گذاشته‌ایم و سپس پارامتر allow-query را برای استفاده از سوی ACL خودمان پیکربندی می‌کنیم. البته می‌توانستیم از پارامترهای دیگری مانند allow-recursion برای ارجاع به گروه ACL خودمان نیز استفاده کنیم. اگر این امکان موجود و کوئری بازگشتی نیز فعال باشد در این صورت allow-recursion فهرستی از کلاینت‌ها را باز می‌گرداند که می‌توانند از سرویس‌های بازگشتی استفاده کنند.

با این حال اگر allow -recursion تعین نشده باشد، در این صورت Bind به فهرست allow-query-cache و سپس llow-query باز می‌گردد و در نهایت تنها گزینه‌های localnets و localhost پیش‌فرض باقی خواهد ماند. از آنجا که ما یک سرور کش DNS را پیکربندی می‌کنیم (این سرور منطقه‌های معتبر یعنی authoritative برای خود دارد و درخواست‌ها را فوروارد نمی‌کند) بنابراین فهرست allow-query همواره تنها برای کوئری‌های بازگشتی استفاده می‌شود. ما به این دلیل از آن استفاده می‌کنیم که عمومی‌ترین روش برای تعیین ACL است. زمانی که انجام این تغییرات پایان یافت، فایل را ذخیره کرده و ببندید.

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

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

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

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

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-query { goodclients; };
 
        dnssec-validation auto;
        auth-nxdomain no; # conform to RFC1035
        listen-on-v6 { any; };
};

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

بدین منظور لازم نیست مقدار recursion با برابر با no قرار دهیم. سرور فوروارد همچنان سرویس‌های بازگشتی را با پاسخ دادن به منطقه‌هایی که برای آن‌ها معتبر (authoritative) است اجرا می‌کند. در عوض ما باید فهرستی از سرورهای کش داشته باشیم که درخواست‌هایمان را به آن‌ها فوروارد کنیم.

این کار درون بلوک options {} صورت می‌گیرد. ابتدا یک بلوک درون آن ایجاد می‌کنیم که آن را forwarders می‌نامیم. این بلوک شامل آدرس‌های IP سرورهای نام بازگشتی است که می‌خواهیم درخواست‌های خود را به آن‌ها فوروارد کنیم. در این راهنما از سرورهای DNS عمومی گوگل (8.8.8.8 و 8.8.4.4) استفاده می‌کنیم.

...
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-query { goodclients; };
        forwarders {
               8.8.8.8;
               8.8.4.4;
        };
         ...

پس از آن باید مقدار forward را برابر با «only» قرار دهیم، چون این سرور همه درخواست‌ها را فوروارد می‌کند و نباید خودش اقدام به resolve کردن درخواست‌ها بکند.

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

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};
options {
        directory "/var/cache/bind";
       recursion yes;
       allow-query { goodclients; };
       forwarders {
              8.8.8.8;
              8.8.4.4;
       };
       forward only;
 
       dnssec-validation auto;
       auth-nxdomain no; # conform to RFC1035
       listen-on-v6 { any; };
};

یک تغییر نهایی که باید انجام دهیم مربوط به پارامترهای dnssec است. در پیکربندی حاضر بسته به این که کدام سرورهای DNS برای فوروارد انتخاب شده باشند، ممکن است خطاهایی به صورت زیر را در لاگ های خود مشاهده کنید:

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53

Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

برای اجتناب از این خطاها باید مقدار dnssec-validation را به صورت yes تنظیم کنید تا dnssec به طور صریح فعال شود:

...
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
...

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

تست پیکربندی و ری‌استارت کردن Bind

اینک که سرور Bind به سورت یک سرور کش DNS یا یک سرور فوروارد DNS پیکربندی شد، آماده هستیم تا تغییرات را پیاده‌سازی کنیم.

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

این کار از طریق وارد کردن دستور زیر ممکن است:

sudo named-checkconf

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

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

وقتی که فایل‌های پیکربندی خود را تأیید کردید و هیچ خطای ساختاری وجود نداشت می‌توانید Daemon مربوط به Bind را ری‌استارت کنید تا تغییرات پیاده‌سازی شوند:

sudo service bind9 restart

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

sudo tail -f /var/log/syslog

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

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

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

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

می‌بایست فایل etc/resolv.conf/ را ویرایش کنیم تا سرور ما به سرور نام اشاره کند. تغییراتی که در این فایل ایجاد می‌کنیم صرفاً تا زمان راه‌اندازی مجدد سیستم اعمال می‌شوند که برای تست کردن مناسب است. اگر از نتایج تست خود راضی بودیم، می‌توانیم تغییرات را به صورت دائمی درمی‌آوریم.

فایل را با دسترسی sudo در یک ویرایشگر متنی باز کنید.

sudo nano /etc/resolv.conf

در این فایل فهرستی از سرورهای DNS وجود دارد که برای resolve کردن کوئری‌ها با استفاده از سرور نام استفاده می‌شود. همه مدخل‌های کنونی را با کامنت غیر فعال کنید و یک nameserver اضافه کنید که به سرور DNS شما اشاره کند:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

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

اینک می‌توانید آن را با استفاده از ابزارهای متداول تست کنید تا مطمئن شوید که کوئری‌ها به طرز صحیحی resolve می‌شوند. می‌توانید از ping برای تست این که امکان اتصال به دامنه وجود دارد استفاده کنید:

ping -c 1 google.com

خروجی

PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

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

dig linuxfoundation.org

خروجی

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.          IN           A

;; ANSWER SECTION:
linuxfoundation.org.           6017           IN           A           140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE rcvd: 64

می‌بینید که کوئری در طی 36 میلی‌ثانیه پاسخ داده است. اگر دوباره این درخواست را ایجاد کنیم سرور باید اطلاعات را از کش خود بخواند و این زمان پاسخ‌دهی کاهش یابد.

dig linuxfoundation.org

خروجی

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org. IN A
;; ANSWER SECTION:
linuxfoundation.org. 6012 IN A 140.211.169.4
;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE rcvd: 64

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

می‌توانیم فرایند جستجوی معکوس (reverse lookup) را با استفاده از آدرس IP که یافته‌ایم (140.211.169.4) به وسیله گزینه x– در دستور dig اجرا کنیم:

dig -x 140.211.169.4

خروجی

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa. IN PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME 4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE rcvd: 117

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

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

...
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

این خروجی نشان می‌دهد که سرور تلاش کرده است تا اطلاعات IPv6 را resolve کند؛ اما سرور ما برای IPv6 پیکربندی نشده است. این وضعیت را می‌توانید با تنظیم Bind فقط برای resolve کردن IPv4 حل کنید. برای انجام این کار فایل etc/default/bind9/ را با دسترسی‌های sudo باز کنید:

sudo nano /etc/default/bind9

در این فایل پارامتر OPTIONS را ویرایش کنید تا فلگ -4 باعث شود سرور تنها نسخه IPv4 را تحلیل کند:

OPTIONS="-u bind -4"

فایل را ذخیره کرده و ببندید و سرور را ری‌استارت کنید:

sudo service bind9 restart

اینک دیگر خطای فوق را در لاگ ها نخواهید دید.

دائمی ساختن تنظیمات DNS کلاینت

همان طور که قبلاً اشاره کردیم، تنظیمات etc/resolv.conf/ که باعث می‌شود رایانه کلاینت به سرور DNS ما اشاره کند پس از راه‌اندازی مجدد حفظ نمی‌شود. برای این که این تغییرات دائمی شوند، باید فایل‌هایی که برای ایجاد این فایل استفاده شده‌اند، ویرایش شوند.

اگر رایانه کلاینت دارای سیستم عامل دبیان یا اوبونتو باشد، باید فایل /etc/network/interfaces را با دسترسی sudo باز کنید.

sudo nano /etc/network/interfaces

به دنبال پارامتر dns-nameservers بگردید. می‌توانید مدخل‌های موجود را حذف کنید و آن‌ها را با سرور DNS خودتان عوض کنید یا این که سرور DNS خودتان را به عنوان یکی از گزینه‌ها تعیین کنید:

...
iface eth0 inet static
     address 111.111.111.111
     netmask 255.255.255.0
     gateway 111.111.0.1
     dns-nameservers 192.0.2.1
...

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

اگر روی کلاینت سیستم عامل CentOS یا فدورا وجود داشته باشد باید فایل /etc/sysconfig/network/network-scripts/ifcfg-eth0 را باز کنید:

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

درون این فایل به دنبال خطی بگردید که با عبارت DNS آغاز می‌شود. مقدار DNS1 را به سرور DNS خودتان تغییر دهید. اگر می‌خواهید از سرورهای DNS استفاده کنید باید مدخل‌های زیر را حذف کنید:

DNS1=192.0.2.1

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

نتیجه‌گیری

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

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

اگر این نوشته مورد توجه شما قرار گرفته است، موارد زیر نیز احتمالاً مورد علاقه شما خواهند بود:

==

بر اساس رای ۰ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
digitalocean
نظر شما چیست؟

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