تا 60% تخفیف
برای 6 نفر
به همراه صدور مدرک
مانده تا پایان تخفیف ها
کاملترین آموزش راه اندازی DNS Server مایکروسافت | مفاهیم و نکات
یکی از سرویس های پرکاربرد مخصوصاً در دنیای اینترنت! منظورم سرویس DNS یا Domain Name System است که در این آموزش میخواهیم با این سرویس پرکاربرد، نحوه راه اندازی و مفاهیم و نکات استفاده از آن به صورت کامل آشنا شویم.
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
- DNS چیست؟
- ارتباطات DNS چگونه است؟
- DNS Server Caching چیست؟
- مفهوم Forwarder در DNS چیست؟
- Reverse Name Resolution چیست؟
- نکات مهم در نصب DNS سرور
- آموزش ساخت Zone در DNS
- بررسی AD Integrated Zones در DNS
- معرفی انواع رکورد در DNS
- آموزش عیب یابی DNS سرور
- معرفی انواع Zone در DNS
- Zone Delegation چیست؟
- مفهوم Stub Zone و GlobalNames
DNS چیست؟
DNS یک سرویس ضروری برای اینترنت و ارتباطات Active Directory محسوب می شود . همه ارتباطات TCP/IP بر پایه آدرس IP می باشد . هر کامپیوتر در شبکه حداقل یک کارت شبکه دارد که یک " هاست " نامیده می شود . و در اتصال TCP\IP هر هاست دارای یک ادرس IP می باشد که در شبکه یکتا است ، هر پکیتی در شبکه مبتنی بر TCP\IP شامل IP ادرس فرستنده و IP ادرس گیرنده می باشد انتشار می یابد
هنگامی که شما دسترسی به فولدر های اشتراک شده را روی شبکه یا یک وب سایت از روی اینترنت فراخوانی می کنید در واقع با انتخاب یا تعیین کردن یک " نام هاست " انجام می شود . چون نام خیلی راحت به یاد می ماند تا اینکه بخواهیم اعداد طولانی IP را به خاطر بسپاریم .
DNS چگونه کار می کند؟
در سیستم های TCP\IP برای اینکه از نام " هاست " های آشنا استفاده کنند ، باید راهی داشته باشند تا آدرس های IP را به نام های خاص آن " هاست " ارتباط دهند . در آغاز شبکه های TCP\IP با لیستی از نام ها به همراه معادل ادرس های IP آن ها به نام " Host Table " نامیده می شدند .
در ان زمان تعداد کامپیوتر هایی که در اینترنت بودند محدود بود و هنوز اینترنت خیلی نو پا بود . امروزه میلیون ها کامپیوتر و ... در اینترنت وجود دارد کهفکر نگهداری از فایلی که نام ها را شامل شود و همینطور پخش آنها بسیار ازار دهنده است . به جای اینکه از Host Table استفاده شود در شبکه های TCP\IP امروزه از سرور های DNS برای تبدیل " نام هاست " به ادرس های IP استفاده می کنند . این پروسه را به اصطلاح " Name Resolution " می نامند . DNS از سه جزئ تشکیل شده است :
- فضای نام گذاری ( Namespace ) DNS : استاندارد های DNS ، یک فضای نام گذاری سه ساختاری که در هر شاخه ای یک Domain را شناسایی می کند ، تعریف می کنند ، هر دومین شامل یک جمعی از رکورد های منبع می شود که شامل " نام هاست " ، آدرس های IP ، و دیگر اطلاعات است . عملیات درخواست ( کوئری ) می خواهد رکورد های منبع مشخص را از یک Domain مشخص بازیابی کند
- Name Servers : سرور DNS برنامه ای است که روی یک کامپیوتر سرور راه اندازی می شود که اطلاعات در مورد ساختار درختی " Domain " موثق بوده و در یک یا بیشتر " Domain" ها مشخص می شود و در این ساختار قرار دارند . این قابلیت " کوئری " دیگر دامین ها را پاسخ می دهد به شرط انکه ساختار درختی داشته باشند .
- Resolvers : یک Resolvers یک برنامه کلاینتی است که " کوئری " های DNS را ایجاد می کند و آن ها را برای اجرا به یک سرور DNS می فرستد . یک Resolver دسترسی مستقیم به حداقل یک سرور DNS را دارد و همچنین می تواند مستقیماً به " کوئری " های خود در دیگر سرور ها زمانی که نیاز دارد دسترسی داشته باشند . در بیشتر موارد پروسه DNS name resolution شامل ارائه درخواست name resolution از طریق resolver به سرور DNS معین شده خود می باشد . زمانی که یک سرور هیچ اطلاعاتی در مورد " نام درخواست شده " ندارد ، DNS درخواست را به یک DNS دیگر روی شبکه می فرستد . سرور دوم یک جواب که شامل آدرس IP " نام درخواست شده " می شود را به سرور اول می فرستد ، و سرور اول اطلاعات را به Resolver بر می گرداند .
ارتباطات DNS چگونه است؟
اگر چه تمامی برنامه های اینترنت از DNS برای پیدا کردن نام های هاست ها به IP استفاده می کنند ، این پروسه Name resolution خیلی ساده است زمانی که شما از یک جستجوگر وب برای دسترسی به یک سایت در اینترنت استفاده می کنید . زمانی که شما یک Url که شامل نام DNS ( مانند www.tosinso.com ) می باشد داخل محل ادرس جستجوگر تایپ می کنید و Enter را می زنید اگر دقت کنید خیلی سریع یک یک پیام مانند " Finding Site : www.tosinso.com " را می بینید .
سپس چند ثانیه بعد شما ممکن است پیامی مانند " connect to " و یا یک آدرس IP که می آید رو ببینید ، این عملیات در زمان پروسه DNS name resolution اتفاق می افتد . از دید کلاینت این کار در زمان کوتاهی انجام می شود وقتی که ادرس وب سایت فرستاده می شود و به سرور می رسد و جوتب آن با یک IP ادرس داده می شود . برای اینکه رابطه سرور های DNS برای Domain های مختلف را در فضای نامگذاری بهتر متوجه شوید ، از روشی که به نام پروسه Internet name resolution هست استفاده می کنیم :
- یک کاربر در یک سیستم کلاینت در روی بستر اینترنت با جستجوگر ادرس وبی را انتخاب می کند این جستجوگر یک Application Programming interface ( API) ایجاد می کند تا Resolver را به سیستم کلاینت فراخوانی کند و Resolver یک پیام " درخواست بازگشتی " یا همان ( Recursive Query ) که شامل نام سرور می باشد می سازد و این پیام به سرور DNS که در تنظیمات TCP\IP تعیین شده است انتقال پیدا می کند ، شکل زیر نمایی اط این فرایند را نشان می دهد :
- DNS کلاینت ، بعد از دریافت درخواست ، رکورد های منبع را چک می کند تا بفهمد که این منبع برای هر Zero که حامل نام سرور درخواست شده است ، معتبر است یا خیر . اگر معتبر نبود ، سرور DNS یک درخواست تکراری ( iterative query ) می سازد و ان را به یکی از سرور های ریشه یا همان " Root " ارسال می کند ، سرور Root هم رایزنی برای یافتن رکورد معتبر را در نام Domain سطح بالا ( Top-Level ) جستجو می کند بعد از شناسایی سرور root یک جواب به DNS کلاینت که شامل یک ارجاع به ادرس سرور Domain سطح بالا می باشد ، ارسال می کند .
- سرور DNS کلاینت ، که الان آدرس سرور سطح بالای Domain برای " نام درخواست شده " را دارد ، یک درخواست تکراری بوجود می اورد و ان را به سرور سطح بالای Domain ارسال کرده و حالا ارجاع ادرس سرور های معتبر برای domain سطح بالا برای DNS کلاینت فرستاده می شود .
توجه : پروسه name resolution فقط پیدا کردن نام در اولین و دومین سطح Domain در مراحل جداگانه رو توضیح می دهد ، اما همیشه مسئله این نیست . بیشتر اوقات Domain های سطح بالاتر مانند .com - .net و ... به کار برده می شوند که در واقع برای سرور های root می باشند ، بنابراین اگر یک ارجاع برای name resolution باشد یکی از root ها پاک می شود
- سرور DNS کلاینت یک درخواست تکراری دیگر ایجاد و ان را به دومین سرور سطح Domain ارسال می کند اگر دومین سرور سطح Domain دارای Zone حامل نام درخواست شده باشد ، با رکورد های منبع خود تماس گرفته تا ادرس IP سیستم درخواست شده را تعیین کند و آن را در یک پیام به سرور DNS کلاینت ، ارسال کند .
- سرور DNS کلاینت جوابی از سرور معتبر دریافت می کند و ادرس IP را به resolver روی سیستم کلاینت بر می گرداند این resolver ادرس را پخش می کند و بعد ارتباط سیستم کاربر با IP ادرس مشخص شده شروع می شود .
اگر مراحل با خطا همراه باشد و عملیات تبدیل اسم به IP ادرس شکست بخورد در واقع پروسه name resolution با شکست مواجه می شود پس همیشه نباید به موفق بودن این عملیات امیدوار باشیم
DNS Server Caching چیست؟
پروسه Name Resolution به نظر طوانی و پیچیده می آید اما در بیشتر مواقع نیازی نیست که کلاینت های سرور DNS ، کوئری ها را به هر Domain که نام مورد درخواست مربوط به آن است ، بفرستد . چون سرور های DNS قابلیت نگهداری اطلاعاتی که در مورد فضای نام گذاری DNS، زمانی که در حال انجام مراحل Name Resolution خود می باشند ، یاد می گیرند و انها این اطلاعات را در یک حافظ نهان " Cache " در درایو محلی ذخیره می کنند .
DNS سروریی که در خواست ها را از کلاینت دریافت می کند ، برای مثال آدرس هایی که DNS ، از سیستم در خواست کرده را در حافظه نهان خود ذخیره می کند دقیقاً مانند آدرس هایی است که در سرور های معتبر Domain های خاص قرار دارد . در مرحله بعدی که یک کلاینت نامی که قبلاً پیدا شده بود را در خواست کند سرور می تواند به سرعتاطلاعات را از حاظه نهان خود بیرون بیاورد و به کلاینت پاسخ دهد .
به علاوه ، اگر یک کلاینت نامی را در خواست کند که در یکی از Domain ها است ، سرور می تواند یک درخواست به طور مستقیم به یک سرور معتبر برای Domain ها مشخص می فرستد نه به یک سرور Root، نام هایی که در Domain ها در دسترس هستند خیلی سریع پیدا می شوند چون یکی از سرور ها در این مسیر اطلاعاتی در مورد Domain در حافظه نهان خود دارد . در حالی که پیدا کردن نام ها در این Domain ها زمان زیادی می برد چون پروسه درخواست کامل نام را می طلبد .
Caching در ساختار DNS خیلی حیاتی می باشد به دلیل اینکه Caching تعداد زیادی از درخواست هایی که به Root و سپس به سرور های سطح بالا در Domain فرستاده می شوند که در نوک ساختار درختی DNS قرار دارند ، را کم می کند . چون این در خواست ها از گلوگاه کل سیستم را تنگ می کند و باعث اختلال در شبکه می شوند .
به هر حال اطلاعاتی که در حافظه نهان قرار دارند باید باید سرانجام خالی شوند ، به دلیل اینکه در اینجا ارتباط خوبی بین Caching مور و ناکارآمدی وجود دارد. به دلیل اینکه سرور های DNS رکورد های منبع را در کش خود نگهداری می کنند ، چندین ساعت یا حتی روز طول می کشد تا تغییرات ایجاد شده در یک سرور معتبر در سرتاسر اینترنت پخش می شود .
در طول این دوره ، ممکن است کاربران اطلاعات غلطی را در جواب یک درخواست ، بدست اوردند . اگر اطلاعات مدت زما زیادی در کش بمانند ، آن وقت تغییراتی که مدیران می خواهد برای سرور های DNS انجام دهند خیلی زمان می برد تا در سرتاسر اینترنت پخش شود .
اگر کش ها خیلی سریع پاک شوند ، سپس تعداد در خواست هایی که به Root و سرور های سطح بالای Domain ارسال می شوند خیلی زیاد می شود و باعث اختلال و کندی شبکه می شود . مقدار زمانی که دیتای DNS در یک سرور کش شده باقی می ماند ( TTL ) Time To Live نامیده می شود .
این TTL توسط اطلاعات کش می شوند نه به وسیله مدیران شبکه روی سرور ، همچنین مدیران سرور ها DNS باید تعیین کنند که تا چه مدت زمانی دیتای رکورد های منبع یا Zone ها باید در سرور ها جایی که دیتا کش شده است ، نگداری شوند . این کار به مدیران اجازه می دهد تا مقدار TTL که براساس Volatility ( تعداد رکورد هایی که از یک سیستم کامپیوتری در مقایسه با کل اعداد ذخیره شده ، حذف می شوند ) دیتای سرور خود می باشد را تعیین کنند .
در شبکه ای که تغییرات مربوط به IP ادرس ها یا تعداد رکورد های منبع ، زیاد می باشد ، با کاهش TTL ، احتمال این که کلاینت ها دیتای جاری را دریافت کنند ، افزایش می دهد . در شبکه ای که تغییرات به ندرت صورت می گیرد ، شما می توانید مقدار TTL زیاد کنید و تعداد درخواست های فرستاده شده به سرور های Parent در Domain یا Zane خود را به حداقل برسانید . برای اصلاح مقدار TTL برای یک Zone در ویندوز سرور 2012 ، روی Zone راست کلیک کرده و از Properties روی تب " SOA " - Start Of Authorithy کلیک کنید . در این تب می توانید TTL این رکورد را در مقدار پیش فرض یک ساعت اصلاح کنید .
مفهوم Forwarder در DNS چیست؟
پروسه ای که یک سرور DNS یک درخواست name resolution به سرور DNS دیگر ارسال می کند Referral ( ارجاع ) نامیده می شود . ممکن است فکر کنید DNS کلاینت ، اصلاً در پروسه Name Resolution درگیر نشده است ، به جز اینکه یک درخواست فرستاده و یک جواب دریافت کرده است ، در حالی که سرور DNS ممکن است مجبور باشد چندین ارجاع به چندین سرور قبل از دریافت کردن یک جواب که به آن نیاز دارد ، ارسال کند . سرور های DNS دو نوع از درخواست های name Resolution را مدیریت می کنند :
- درخواست بازگشتی ( Recursive Query ) در درخواست بازگشتی ، DNS هایی که درخواست Name Resolution را دریافت می کند مسئولیت زیادی برای پیدا کردن " نام " دارد ، اگر سرور اطلاعاتی در مورد " نام درخواست شده " داشته باشد ، سریعاً به DNS سرور های دیگر جواب می دهد تا به جوابی که می خواهند برسند . Resolver های کلاینت TCP همیشه درخواسته ای بازگشتی را به DNS سرورهای تعیین شده ، ارسال می کنند .
- درخواست تکراری ( Iterative query ) : درخواست تکراری ، سروری که درخواست Name Resolution را دریافت می کند سریعاً با بهترین اطلاعاتی که در آن لحظه دارد پاسخ می دهد . DNS سرور ها از " درخواست تکرار شونده " زمانی که در حال ارتباط با یکدیگر می باشند استفاده می کنند . در بیشتر موارد ، تنظیم یک DNS سرور برای ارسال یک " درخواست تکراری " به دیگر DNS سرورها مناسب نمی باشد . تنها زمانی یک DNS سرور یک " درخواست تکراری " را به دیگر DNS سرور ها ارسال می کند که یک نوع خاصی از سرور به نام Forwarder باشد که به طور خاصی برای ارتباط با دیگر سرور ها در این مسیر تنظیم شده است
کاربرد DNS Forwarders چیست؟
یکی از عملکرد هایی که DNS سرور ها " درخواست تکراری " را به دیگر سرور ها ارسال می کند زمانی است که به عنوان یک Forwarder تنظیم شده باشد . در شبکه ای که چندین DNS سرور دارد . شما نمی خواهید همه سرور ها درخواست ها را به DNS سرور های دیگر روی اینترنت ارسال کنند .
اگر شبکه شما ارتباط کندی با اینترنت دارد ، برای مثال چندین سرور که درخواست های تکراری را ارسال می کنند ممکن است پهنای باند زیادی استفاده کنند که سرعت پایین می آورد . برای جلوگیری از این اتفاق ، بیشتر اجراهای DNS به شما امکان می دهند تا سرور را به عنوان Forwarder برای همه درخواست های اینترنتی که به وسیله دیگر سرور ها روی شبکه ایجاد شده اند ، تنظیم کنید .
هر زمانی که یک سرور مجبور باشد نام DNS را از یک سیستم اینترنتی پیدا کند و در پیدا کردن نام در Cach خود شکست بخورد ، یک " درخواست بازگشتی " به forwarder ارسال می کند ، که forwarder در حال حاضر مسئول ارسال " درخواست تکراری " خود روی اینترنت می باشد .
زمانی که Forwarder یک نام را پیدا کند ، یک جواب بازگشتی به DNS سرور اصلی بر می گرداند که این سرور جواب را به کلاینت می فرستد . برای تنظیم forwarder ها روی DNS سرور ویندوزی مثلاً ویندوز سرور 2012 روی نود Sercer راست کلیک کنید و Properties زده و روی تب Forwardes کلیک کنید و حالا می توانید نام و IP سرور هایی که می خواهید سرور شما به عنوان Forwarder از انها استفاده کند را وارد می کنید :
Reverse Name Resolution چیست؟
پروسه Reserve Name Resolution همانطوری که در درس های قبلی گفته شد به تبدیل DNS Name به آدرس های IP می باشد ، اما یک کامپیوتر در شرایطی نیاز دارد که تا یک IP را به یک DNS names تبدیل کند . به این پروسه Reserve Name Resolution می گوییم .
از آنجاییکه ساختار سلسله مراتبی تحت تاثیر نام های Domain به هم ریخته است ، هیچ مسیر مشخصی برای پیدا کردن یک IP به یک نام با استفاده از " درخواست های تکراری " وجود ندارد به جز اینکه درخواست Reserve Name Resolution را به همه DNS سرور ها روی اینترنت برای جستجوی آدرس درخواست شده ارسال کنیم که مسلماً این روش هیچ کاربردی ندارد .
برای حل این مشکل توسعه دهندگان DNS ، یک Domain خاص به نام in-addr.arpa ایجاد کرده اند که تنها برای Reserve Name Resolution طراحی شده است . دومین سطح محدوده in-addr.arpa شامل چهار سطح اضافی است که Subdomain ( زیر مجموعه domain ) هستند ، هر کدام از این 4 سطح شامل Subdomain هایی هستند که با اعداد 0 تا 255 نامگذاری شده اند .
برای مثال ، زیر محدوده Domain 256- in-add-arpa سطح سوم وجود دارد که دارای نام رنج in-addr.arpa 0 تا 255.in.addr.arpa می باشند . هر کدام از Domain 256 سطح سوم در زیر سطح خود دارای Domain 256 سطح چهارم است ، و هر کدام از 0 تا 256 شماره گذاری شده اند که هر Domain سطح چهارم دارای Domain 256 در سطح پنجم می باشند . هر کدام از Domain های سطح پنجم می توانند تا host 254 داشته باشند که هر هاست از 0 - 256 شماره گذاری شدع اند . شکل زیر را دقت کنید :
بنابراین از ساختار زیر Domain هایی in-addr-arpa برای پیدا کردن IP به نام استفاده می شود . زمانی که IP برای پیدا کردن نام فرستاده می شود به جای اینکه از چپ به راست خوانده شود از راست به چپ خوانده می شود . زمانی که آدرس از چپ به راست خوانده می شود ، Net ID ادرس IP ، سه Octed اول IP می باشد و اطلاعات خاص آن که همان قسمت Host آن است که در آخرین Octed نوشته می شود .
به این دلیل ترتیب آکتد های IP باید زمانی که در حال ساختن ساختار درختی In-Addr-Arpa می باشد معکوس شود یعنی باید از راست به چپ خوانده شود . در آخر ، ساختار درختی in-addr-arpa به یک نوع از رکورد های منبع ( Resource Record ) به نام PTR نیاز دارد .
برای مثال با استفاده از ساب دومین ها های سلسله مراتبی می توان توضیح داد که سه بایت اول یک IP به عنوان DNS domain name کاربرد دارد و چهارمین بایت در پنجمین سطح دومین به عنوان یک رکورد منبع شناخته می شود . برای پیدا کردن 192.168.89.34 به نام ، DNS سرور یک دومین که به نام 89.168.192.in-addr.arpa خوانده می شود و محتوای رکورد که 34 ( host ) نام دارد را در دومین مدنظر می خواند .
نکات مهم در نصب DNS سرور
هدف آموزش های سرویس DNS مایکروسافت آموزش نصب این سرویس نیست چون مراحل نصب خیلی ساده است و اکثراً هنگام نصب سرویس اکتیودایرکتوری آن را نصب می کنند ( نصب DNS در زمان نصب اکتیو دایرکتوری اجباری است ) اگر هم در معرفی موضوع از واژه نصب استفاده شده منظور هدف از نصب و راه اندازی سرویس DNS است :
- بعد نصب سرویس DNS سیستم به صورت خودکار ری استارت می شود
- همراه نصب سرویس DNS یک کنسول به نام DNS manager نصب می شود که تنظیمات امکاناتی که در DNS سرور وجود دارد را ممکن می سازد
Zone چیست؟ بررسی مفهوم Zone در DNS سرور
یک Zone یک نهاد امنیتی است که روی یک DNS سرور برای اجرای یک قسمت مجزا فضای نام گذاری DNS ایجاد می شود ، مدیران شبکه از فضای نام گذاری DNS در Zone برای سرور های مختلف و واگذاری مدیریت آنها به افراد مختلف استفاده می کنند ( این یک نکته ) بعدی هم Zone ها همیشه شامل Domain ها یا Subdomain های یکپارچه می شوند . شما می توانید یک Zone که شامل چندین Domain می شود را تا زمانی که Domain ها به فضای نام گذاری DNS وابسته است
ایجاد کنید ( اینم نکته دوم ) ! مثلاً شما می توانید یک Zone که شامل یک Parent Domain و Child داشته باشید چون به صورت مستقیم به هم وابسته هستند ، اما شما نمی توانید یک Zone شامل دو تا Child Domain ایجاد کنید بدون اینکه شامل parent ها آن شود برای اینکه Child ها به طور مستقیم به هم وصل نیستند و از طریق Parent های خود با هم ارتباط برقرار می کنند به شکل زیر توجه کنید :
شما می توانید فضای نامگذاری DNS را به چندین Zone تقسیم کنید و اگر بخواهید آنها را در یک DNS سرور مجزا قرار دهید . ویندوز سرور 2012 می تواند 200.000 Zone را ساپورت کند !! هر Zone شامل یک پایگاه داده است که رکورد های منبع RR برای Domain ها در آن Zone قرار دارد ، در ویندوز سرور هایی مانند 2012 سه نوع Zone تعریف شده است :
- Primary Zone : در واقع کپی از پایگاه داده اصلی Zone است که آن را primary master zone هم می نامند ، جایی که مدیران شبکه همه تغییرات رکورد های منبع Zone را در آن انجام می دهند . اگر گزینه Store The in Active Directory ( تنها زمانی کار می کند که DNS سرور برای یک DC باشد ) تیک نخورده باشد ، سرور یک فایل پایگاه داده primary master zone را در درایو محلی می سازد ، این پایگاه داده یک فایل Text ساده می باشد که با بیشتر اجراهای غیر ویندوز سرور DNS سازگار است .
- Secondary Zone : یک Zone ثانویه از Primary Zone می سازد ، Zone ثانویه شامل یک کپی Back up از فایل پایگاه داده primary master zone ایجاد می کند و این کپی را به عنوان یک فایل Text که با primary zone یکسان است روی درایو محلی ذخیره می کند . اطلاعات این Zone به صورت امنیتی ذخیره و می تواند یک نسخه از اطلاعات primary DNS که برای آن تعریف شده در خود داشته باشد . این Zone در اکتیو دایرکتوری ذخیره نمی شود ( این یک نکته کلیدی است ) شما فقط می توانید رکورد های منبع را در یک Zone ثانویه به وسیله عمل Replication با فایل پیگاه داده primary zone به روز رسانی کنید و به پروسه ای که این عمل را انجام می دهد Zone Transfer گفته می شود . اگر اطلاعات primary zone را از دست بدیم می توانیم از اطلاعات ذخیره شده در Zone ثانویه استفاده کنیم
- Stub Zone : یک کپی از primary zone که شامل رکورد های منبع اصلی می باشد را ایجاد می کند و سرور های معتبر برای Zone را معرفی می کند . اطلاعات و رکورد های این Zone فقط شامل DNS سرور های تعیین شده ( NS ) برای آن است . Stub Zone درخواست ها را یا ارجاع می دهد یا Forward می کند . زمانی که شما یک Stub zone ایجاد می کنید ، Stub zone را با ادرس IP سروریی تنظیم می کنید که دارای یک Zone است که شما Stub را از آن ایجاد کرده اید . هنگامی که سروری که دارای Stub هست یک درخواست برای نام در Zone دریافت می کند ، این سرور یا درخواست را به سرور دارای Forward Zone برده و یا با یک ارجاع به سرور جواب می دهد و این بستگی به این دارد که درخواست بازگشتی باشد یا تکراری . به دلیل اینکه این Zone فایل های رکورد کاربران را در خود نگه نمی دارد در نتیجه امنیت کمتری نسبت به 2 نوع قبلی دارد ( این یک نکته کلیدی است )
DNS خیلی قبل تر از Active Directory ایجاد شده ، بنابراین بیشتر اینترنت به Zone های Primary و Secondary اعتماد دارند چون دارای فایل پایگاه داده ای می باشند که بر اساس Text است . بیشتر پایگاه های داده روی اینترنت بر اساس برنامه UNIX هستند .
نکته : زمانی که شما سرویس AD را نصب می کنید با سرویس DNS یک primary zone ساخته می شود و وقتی Zone در AD DS ذخیره شود نیازی نیست که Zone های ثانویه ایجاد کنید یا عمل Zone Transfer انجام دهید چون AِD DS مسئولیت Replication اطلاعات را بر عهده دارد هر روش بک آپ گیری که شما در Active directory بکار ببرید اط اطلاعات DNS هم محافظت می کند .
آموزش ساخت Zone در DNS
اولین Zoneکه نصب می شود Primary Zone است . هدف از این مقاله قط آشنایی با سرویس DNS و اجزای آن در سرور های مایکروسافتی است بنابراین مراحل نصب و راه اندازی آن هدف این مقاله نیست ! یک نام دلخواه را برای Zone قرار می دهیم مثلاً tosinso.com و پایگاه داده ها در DNS مسیری است به آدرس %Windir%\system32\dns\ ذخیره می شود . دقت کنید در پایگاه ذخیره شده اگر Zone را پاک کرده باشید با ساخت Zone جدید ان Zone قبلی نیز مجدداً ساخته می شود . بعد از مراحل نصب حالا دو رکورد ایجاد می شود :
- (SOA ) Start Of Authorithy : مانند شناسنامه Zone می باشد و اطلاعات اصلی را دارا می باشد
- ( NS ) Name Server : مشخص کننده نام و آدرس DNS سرور هایی که این Zone روی آنها قرار دارد .
ساختن Secondary Zone
باید توجه کنیم که این Zone فقط بعد از نصب Primary Zone نصب می شود چرا که Name Server نیاز داریم و تنظیمات لازم برای Transfer شدن اطلاعات انجام می دهیم . شکل زیر غیر فعال بودن Zone Transfer را نشان می دهد :
ابتدا این گزینه را فعال می کنیم و روی یکی از موارد زیر قرار می دهیم :
- To any server : اطلاعات این Zone با هر سروری که درخواست تبادل اطلاعات داد ، مبادله شود ( این گزینه از لحاظ امنیتی مشکل ایجاد می کند )
- Only to listed on the name server tab : با انتخاب این گزینه ، اطلاعات این Zone فقط با سرور هایی مبادله می شود که تب name servers آنها را Add کرده باشیم ( این گزینه بهترین انتخاب است )
- Only the following servers : با انتخاب این گزینه می توان ادرس IP سرور های مورد نظر را در لیستی که زیر این گزینه وجود دارد اضافه کرد اما این کار نیز از لحاظ امنیتی درست نیست زیرا هر سرور می تواند IP آدرس خود را به این آدرس ها تغییر دهد و این اطلاعات را دریافت کند :
سپس وارد تب Name server می شویم و سرور مورد نظر را با انتخاب گزینه ی Add و وارد کردن FQDN و IP در این قسمت اضافه کنیم ، حالا روی سروری که می خواهید Secondry Zone داشته باشید رفته و وارد کنسول مدیریت DNS شوید و اقدام به ساخت Secondry Zone کنید . بعد پایان مراحل نصب برای صحت درستی کار این Zone وارد ان شده و راست کلیک می کنید و Propertise می کنیم تب General را در قسمت Master server و ادرس IP مربوط به Primary server را وارد می کنیم تا اطلاعات Zone را از ان دریافت کند :
حالا روی Secondry Zone مربوطه راست کلسک کرده و گزینه ی Transfer from master را انتخاب می کنیم :
ساخت Stub Zone هم مراحلی شبیه به Secondary Zone دارد !!!
بررسی AD Integrated Zones در DNS
زمانی که شما سرویس DNS را روی یک کامپیوتر در یک Active Directory Domain Services domain controller راه اندازی می کنید زمانی که Zone می خواهید بسازید اگر از گزینه Store The Zone In Active Directory ( Available Only if DNS server Is A domain controller ) استفاده کنید فایل پایگاه داده Zone ساخته نمی شود و آن را در رکورد های منابع در پایگاه AD DS ذخیره می کند .
ذخیره این پایگاه در این بخش مزیت هایی را دارد که می توان به بالا بردن امنیت و حفظ پهنای باند شبکه و اسان تر شدن مدیریت اشاره کرد . حالا در Zone های Active Directory -integrated پایگاه داده ی Zone در کنار دیگر اطلاعات مربوط به Active Directory ( AD ) به طور خودکار بین DC ها Replicate می شود .
AD برای اینکه کپی های پایگاه داده روی تمام DC ها در Domain به روز شود از چند سیستم Master replication استفاده می کند شما می توانید رکورد های منبع DNS را روی هر DC که یک کپی از پایگاه داده ی Zone را دارد اصلاح کنید و AD تمام DC های دیگر را به طور خودکار به روز می کند . نیازی نیست که Zone های ثاونیه ایجاد کنید یا عمل Zone transfer را به طور دستی انجام دهید ، چون AD تمام عملیات مربوط به Replication پایگاه داده را انجام می دهد .
همچنین می توانید یک ناحیه سفارش سازی Replication Scope را ایجاد کنید پایگاه داده ی Zone را به هر DC یی که بخواهید کپی کنید . AD از پهنای باند شبکه به وسیله Replicate کردن و فشرده سازی اطلاعات DNS سروری که از اخرین Replication تغییر کرده است ، محافظت می کند . Zone replication ها از بالاترین سطح امنیت AD که خیلی ایمن تر از Zone Transfer می باشد ، استفاده می کنند .
آموزش ساخت Active Directory Zone در DNS
برای ساختن باید سرور شما یک AD DS باشد بعد وارد کنسول DNS می شوید و روی Server کلیک و روی فولدر Forward lookup zones راست کلیک کنید و New Zone را انتخاب می کنید حالا Next می کنید و سپس Primary Zone و گزینه ( Available Only if DNS server Is A domain controller ) Store the Zone In Active Directory را انتخاب کنید :
حالا حوزه Replication این Zone ها را در دومین معین می کنیم که :
- در سطح کل Forest
- فقط در یک DNS Server روی یک دومین
- تمام DNS Server روی این Domain
در اینجا انتخاب گزینه اول رو پیشنهاد میده مایکروسافت :
معرفی انواع رکورد در DNS
زمانی که شما DNS خود را راه اندازی می کنید برای هر Host Name یک رکورد منبع ایجاد می کنید که می خواهید تمام شبکه از آنها استفاده کنند . چند نوع رکورد منبع وجود دارد که به وسیله DNS سرور ها استفاده می شوند از جمله مهترین آنها عبارتند از :
- SOA ( Start of Authority ) : مشخص می کند که سرور بهترین منبع معتبر برای دیتای مربوط به Zone می باشد . هر Zone باید یک SOA رکورد داشته باشد و فقط یک رکورد SOA می تواند در یک Zone باشد .
- NS ( Name Server ) : یک DNS سرور را شناسایی می کند که برای Zone معتبر می باشد . هر DNS سرور در Zone چه primary و چه Secondary باید به وسیله یک رکورد NS بیان شود .
- A ( Address ) : یک طرح پیاده سازی می کند که یک نام را به یک آدرس مشخص می کند و برای DNS name خاص یک ادرس از نوع IPv4 اختصاص می دهد . این نوع عملیات اصلی DNS را اجرا می کند و نام ها را به ادرس تبدیل می کند .
- AAAA (Address ) : یک طرح پیاده سازی می کند که یک نام را به ادرس اختصاص می دهد ولی یک DNS name را به IPv6 می دهد . عملیات اصلی DNS را انجام می دهد و نام ها را به ادرس تبدیل می کند .
- PTR ( Pointer ) : یک آدرس را به یک نام تخصیص می دهد و برای ادرس خاص در in-addr-arpa یک DNS name اختصاص می دهد . این رکورد معکوس رکورد A می باشد که فقط برای reverse lookup کاربرد دارد .
- CNAME ( canonical Name ) : یک اسم مستعار که به یک اسم واقعی اشاره می کند و این اسم واقعی یک host می باشد که به وسیله یک رکورد A شناسایی می شود . مدیران شبکه رکورد Cname برای اماده کردن نام های متغیر که به وسیله سیستم ها قابل شناسایی می باشد ، استفاده می کنند .
- MX ( Mail Exchanger ) : یک سیستم را شناسایی می کند که ترافیک ایمیل مستقیم را به یک ادرس در Domain برای گیرنده مجزا ، یک mail gateway یا هر سرور mail دیگری ارسال می کند .
آموزش انجام تنظیمات اولیه DNS سرور
وقتی DNS سرور نصب و Zone ها و رکورد های منبع را در ان ایجاد کردید ، تنظیمات زیادی وجود دارد که می توانید برای تغییرات انجام دهید . یکی از این تنظیمات ایجاد Active Directory DNS Replication است که برای ایجاد تغییرات در حوزه Replication در یک Active directory - Integrated Zone در کنسول DNS صفحه Zone properties را باز می کنید و از Zone مورد نظر properties می گیریم :
می توانیم گزینه ها متفاوت برای تغییر در حوزه Replication را مشاهده کنیم و هر کدام را بر حسب نیاز انتخاب کنیم :
آموزش انجام تنظیمات Root-Hints در DNS سرور
هر DNS سرور باید بتواند برای انجام فرایند Name Resolution با سرورهای Root که در اینترنت قرار دارند ارتباط برقرار کند . بیشتر اوقات DNS سرور مایکروسافت با نما ها و ادرس های سرورهای root تنظیم شده اند . به این root سرور ها root hint می گویند .
دارای 13 نام root سرور در یک Domain قرار گرفته اند که root-server.net نامیده می شود .با حروف الفبا نام گذاری می شود . سرور ها در سرتاسر دنیا در Subnet های متفاوت برای تحمل خطا پراکنده شده اند . برای ایجاد Root hint ها بر روی نود Server کلیک راست کنید و Properties را بزنید تب root hint را بزنید .
آموزش عیب یابی DNS سرور
وجود سرویس DNS برای اجرای Active Directory Domain Services ضروری و لازم است ، برای تطبیق سرویس های Directory مانند AD DS یک رکورد مخصوص در DNS ساخته می شود و به کلاینت ها این امکان را می دهد که DomainController و سایر سرویس های وابسته به AD DS را مکان یابی و با آنها در ارتباط می باشد . زمانی که یک ( DC ) Domain controller جدید راه اندازی می شود یکی از مهمترین کارهای لازم این است که سرور DC روی سرور DNS ثبت شود .
برای ثبت خودکار این سرور در DNS باید ویژگی Dynamic Update باشد .اگر فرایند ثبت DNS شکست بخورد کامپیوتر های درون شبکه نمی توانند DC را پیدا کنند و این مشکل خیلی مهم است چون کامپیوتر ها نمی توانند از DC استفاده کنند و عضو Domain شوند و اعضای Domain نیز نمی توانند لاگین کنند و سایر DC نمی توانند با آن Replicate داشته باشند .
مشکلات DNS در بیشتر موارد ناشی از نواقص کلی در شبکه و یا خطاهای تنظیمات کلاینت ها می باشد . اولین راه Ping کردن و چک درست بودن TCP کلاینت ها است و اینکه از یک ادرس درست برای DNS سرور استفاده شده است . برای کسب اطمینان از اینکه Domain Controller به درستی در DNS ثبت شده است می توانیم خط دستور زیر را در CMD اجرا کنیم :
dcdiag test:registerindns dnsdomain:>Domain Name < /V
معرفی انواع Zone در DNS
در مباحث قبلی درباره تاثیر Active directory بر روی سرویس DNS زده شد ، درباره عمل Replication هم بحثی انجام شد ، گاهی ممکن است مدیر شبکه بخواهد عمل Replicate را به تعداد معدودی DC انجام دهد ، در هنگام ساخت Zone گزینه Active Directory-Integrated انتخاب می شود ، برای این منظور باید Directory Partition را ایجاد کرد ، این گزینه مانند شکل زیر غیر فعال است :
برای این کار از دستور زیر استفاده می شود که پس از سوئیچ Name می توان یک نام برای آن تعریف کرد :
حالا گزینه Directory Partition فعال می شود :
توجه داشته باشید که ماهیت Active directory integrated zone می تواند با یک Read-only domain controller یا همان RODC عمل Replicate را انجام دهد اما Zone فقط خواندنی است و عمل بروزرسانی روی آن انجام نمی شود زیرا این عمل توسط Writable Domain Controller که می توانند اطلاعات جدید و تغییرات روی خود را درج کنند .
Reverse lookup zones چیست؟
این Zone تقریباً بر عکس وظیفه DNS را انجام می دهد ، آدرس IP را به نام FQDN تفسیر می کند . می توان برای هر دو نوع Ip ( 4-6 ) آن را استفاده کرد . انها می توانند از نوع Active Directory Integrated نیز باشند و همچنین می توانند از نوع Standard Primary و Secondary و Stub Zone باشند . به صورت خودکار DC ها یک Reverse lookup zone برای IP ادرس مربوط به اولین DC که در سازمان وجود داشته می سازد .
این نوع Zone ها به Network ID مربوط به بازه ی IP آدرس بستگی دارد ، یعنی Reverse lookup zone هایی که از نوع IPV4 هستند فقط می توانند از نوع 8 و 16 و 24 باشند و نمی توان از Subnet هایی که در هیچکدام از این سه دسته نیستند استفاده کرد . بنابراین کوچکترین Reverse lookup zone که می توان ساخت در سابنت 24 قرار دارد .
Zone Delegation چیست؟
کاربرد Zone Delegation زمانی است که بخواهیم برای یک FQDN خاص که در DNS برای آن Zone ساخته شده است یک لایه پایینتر به عنوان Child نیز بسازیم ازین قابلیت استفاده می شود تا یک ساختار سلسله مراتبی بین Child ها و Parent ها ایجاد شود . مثلاً Zone به نام Itpto.ir ساختیم حالا می خواهیم Zone جداگانه به نام A.tosinso.com بسازیم با استفاده از این قابلیت می توانیم کاری کنیم که تمام DNS server های مربوط به Zone با نام Itpro.ir به DNS server های مربوط به A.tosinso.com اشاره کنند .
- توجه : باساخت یک Domain ، در آن Zone مربوط به DNS server هم به صورت خودکار ساخته می شود ، هنگامی که در یک Forest یک Child domain جدید نیز ساخته می شود به صورت اتوماتیک Zone delegation مربوط به آن هم ساخته می شود .
تفاوت Forwarder و Conditional Forwarder در چیست؟
یکی از مباحث مهم در بخش DNS در مایکروسافت را Forwarder و Conditional Forwarder می توان دانست ، زمانی که کلاینت درخواستی را برای پیدا کردن DNS ارسال می کند و اگر سرور DNS در Zone های خود و حتی در Cache خود پاسخی برای Query که از طرف کلاینت فرستاده شده است پیدا نکند ، بنابراین درخواست ها به سمت Root DNS Server می رود تا پاسخی دریافت کند
اما انجام این کار مشکلاتی را دارد مثلاً ، معمولاً اتصال به سرور Root DNS از طریق WAN صورت می گیرد پس احتمال اینکه قطع شود بیشتر است یا اینکه چون سرور آن از سر های لوکال ما دور است درخواست هایی که به سمت آن ارسال می شود زیاد است ، پس خیلی کند می تواند پاسخ ها را ارسال کند ، بنابراین بهتر است که ما یکسری DNS از طریق LAN که با آنها اتصال داریم یا در WAN برای درخواست های کلاینت ها در zone های آن سرور DNS مربوط می شود را در Local dns server تعیین کنیم که اگر جواب یک درخواست را نداشت این درخواست را به این DNS server های تعیین شده هدایت کند . برای همین منظور قابلیت های Forwarder و Conditional Forwarder ایجاد شده است .
Forwarder در DNS چیست؟
ممکن است نیاز باشد که یک DNS سرور خواست را به DNS server local معرفی کنید تا درخواست های کلاینت ها که در DNS server local هست قادر به پاسخگویی نبود به سمت این DNS server خاص که می تواند اینترنت باشد هدایت شود تا پاسخ را دریافت کند . برای مثال DNS server مربوط به یک ISP که برای اتصال به اینترنت از ان استفاده می کنیم را به عنوان یک Forwarder در تنظیمات DNS server local اضافه می کنیم تا تمام درخواست هایی که بدون پاسخ هستند به ان فرستاده شود تا پاسخ داده شده و تحویل کلاینت شود .
Conditional Forwarder در DNS چیست؟
مانند Forwarder کار می کند با این قابلیت که برای ارسال درخواست ها به DNS server هایی که در قسمت Conditional Forwarder تعیین کرده ایم یک شرط مهم بررسی شود و آن هم Domain Suffix مربوط به درخواست ها یا همان نام دامنه ی درخواست هایی است که از طرف کلاینت ها ارسال شوند است .
در واقع وقتی درخواست کلاینت در سرور لوکال DNS شبکه ما ارسال شود وقتی به جوابی نرسید طبق شرایطی که در Conditional Forwarder هایی که در سرور لوکال DNS تعریف شده سازگار و یکسان باشد این درخواست به DNS سروری که در Conditional Forwarder ادرس آن را مشخص کرده ایم ارسال می شود .
قابلیت Conditional Forwarder زمانی کاربرد دارد که بین سازمان ما ( Itpro.ir ) با یک سازمان دیگر ( It.com ) رابطه Trust برقرار باشد ، در این صورت سرور DNS به سازمان Itpro.ir یک Conditional Forwarder تعریف می کنیم و آدرس Dns سرور مربوط به It.com را همراه با نام همین سازمان ( It.com ) می سازیم تا زمانی که کلاینت های سازمان Itpro.ir یک درخواست با پسوند it.com به سرور DNS خود فرستاده اند این درخواست ها مستقیماً به DNS سرور سازمان It.com هدایت شود . پاسخ را به کلاینت بازگرداند .
مزیت Conditional Forwarder نسبت به Forwarder در چیست؟
فرض کنید در سرور DNS دامنه ای به نام Itpro.ir داریم و به ترتیب اولویت سرورهایی با نام های Microsoft.com و yahoo.com و google.com به عنوان Forwarder تعریف شده است . حالا اگر درخواست Gmail.google.com را به سرور DNS مربوط به دامنه Itpro.ir ارسال شود و پاسخ در کش سرور DNS موجود نباشد . در این حالت برای گرفتن پاسخ ، درخواست به سرور Microsoft.com ارسال می شود و پاسخ نگیرد به سمت Yahoo.com و همینطور در نهایت به سمت Google.com ارسال می شود و پاسخ خود را دریافت می کند .
حالا فرض کنید با همین ترتیب سرور ها با Conditional Forwarder تنظیم شده باشد درخواست Gmail.googl.com به همان ترتیب اولویت به عنوان Conditional Forwarder تعیین شده باشند و درخواست Gmail.google.com به DNS ارسال شود در این حالت سرور DNS ابتدا با بررسی پسوند درخواست و Conditional Forwarder های موجود در لیست درخواست را بدون ارسال به دو سرور اول موجود در لیست ( Yahoo.com - Microsoft.com ) مستقیم به سرور Google.com ارسال می کند . چون پسوند دامنه درخواستی با Google.com تطابق دارد .
مفهوم Stub Zone و GlobalNames
معایبی در کاربرد Conditional Forward وجود دارد ، فرض کنید ما سرور DNS مربوط به دامنه Itpro.ir را در لیست Conditional Forward ها قرار دادیم و سپس ادرس IP مربوط به تمام Secondary DNS Server های این دامنه را هم به آن اضافه کردیم مانند تصویر زیر :
در این حالت مشکلی که وجود دارد این است که اگر درخواستی برای ABC.ir ارسال می شود . همه درخواست ها از اولین سروری که IP آن اضافه شده پرسیده می شود ( در اینجا DNS با آدرس 172.16.2.2 ) . و این باعث Overload بالا بر روی اولین DNS server می شود که مربوط به ABC.ir است .
مشکل بعدی Conditional Forward ها این است که ممکن است به طور مثال شبکه ی ABC.ir ما به عنوان Conditional Forward آن را معرفی کردیم ، مدام در حال تغییر در ساختار DNS خود باشد در اینصورت شبکه ی Itpro.ir که ABC.ir را به عنوان Conditional Forward در لیست خود اضافه کرده باشد باید مدام به صورت دستی این تغییرات را اعمال کند چون Conditional Forward فاقد قابلیت به روزرسانی خودکار است .
کاربرد Stub Zone در DNS چیست؟
برای حل مشکلاتی که در Conditional Forward ها ایجاد می کردند قابلیتی به نام Stub Zone ارایه شده است . برای استفاده از این امکان سرور It.com را به عنوان Conditional Forward معرفی نمی کنیم ( در مباحث قبلی به عنوان مثال زده شده است ) بلکه به عنوان Stub Zone در شبکه خودمان ITpro.ir اضافه کنیم . در واقع کاری که Stub zone انجام می دهد این است که یک کپی از موارد زیر از تنظیمات DNS شبکه ی ABC.ir می گیرد و در شبکه Itpro.ir نگهداری می کند .
- یک کپی از SOA Record
- کپی NS record های تمام Name server ها
- کپی A record های تمام سرور ها
پس A و SRV و Cname و رکورد Host ها را ندارد . Stub zone برای حل مشکلاتی که در Conditional Forward وجود داشت دو کار را انجام می دهد ، اول اینکه یک کپی از SOA Record نگه می دارد ، همانطور که میدانید در SOA تمام تنظیمات مربوط به زمان های آپدیت رکورد ها نگهداری می شود ، پس از طریق Stub zone می توان تشخیص داد که چه زمانی باید DNS server شبکه ی ABC.ir مراجعه کرد و اطلاعات خود را اپدیت کند ، پس مشکلات بروزرسانی در اینجا حل شد .
دومین مزیت Stub zone این است که یک کپی از NS record ها نگه می دارد از این طریق تعداد و ادرس تمام NAME SERVER های موجود در ABC.ir مطلع است و می تواند درخواست ها را بین این Name server ها به صورت متعادل پخش کند .
در این صورت Overload زیادی را روی یک سرور تیجاد نمی کند و مشکلی که در Conditional Forward ها وجود داشت حل شود . اگر Stub zone روی یک Writable domain controller ( DC که قابلیت تغییر در آن وجود دارد ) ساخته شود در active directory نیز ذخیره می شود و با سایر Domain Controller ها Replica می شود .
- نکته : برای ساخت Stub zone دقت کنید که هر سروری که می خواهیم به عنوان Stub zone اضافه کنیم ، نباید در لیست Forwarder ها و Conditional Forward هم موجود باشد
نکته : ممکن است Stub Zone ما را به اشتباه بیندازد و Stub zone را نوعی Secondary Zone بپنداریم . اما این یک اشتباه رایج است . Stub zone نوعی Conditional Forward پیشرفته است که داری قابلیت بروز شدن خودکار و ایجاد Load Balancing ( پخش متعادل درخواست ها بین سرورها برای جلوگیری از بار زیاد ) است .
کاربرد Wins و GlobalNames در DNS چیست؟
خیلی کوتاه توضیحی می دهیم درواقع برای عملیات Name resolution ( تبدیل نام به IP ) روی سیستم های قدیمی کاربرد دارد که نمی توانند با اسامی FQDN همان اسامی که مثلاً به صورت A.Itpro.ir نوشته می شود و یک Single-Label هستند کارایی دارد از ویندوز سرور NT4.0 تا امروز هنوز در ویندوز سرور کار می کند . در ویندوز سرور ها به Wins server دارای رول نصب و ایجاد است . می توان به جای آن از Global Name استفاده کرد و اسامی Single - Label را به DNS اعمال نمود ، این قابلیت از ویندوز سرور 2008 به بعد ایجاد شد . در شرایطی که :
- سازمان از Ipv6 استفاده کند بنابراین WINS دیگر کارایی ندارد
- در خواست Resolve کردن نام های Single - label فقط برای تعداد کمی از سرور ها نیاز باشد ، چون Global Names باید به صورت دستی آپدیت شود .
نکته : حوزه کاری Global name به صورت FOREST بوده و حتماً نام Zone آن باید Globalnames باشد
نکته : دستور زیر باید بعد از اتمام ساخت این Zone انجام شود که در power shell باید انجام دهیم :
سپس برای تمام رکورد هایی که می خواهیم از این طریق بتوانند Resolve شوند باید یک CNAME ساخت . برای ساخت هم روی Zone که به نام Globalnames ساختیم راست کلیک باید کنیم و گزینه ی New Alias ( CNAME ) را انتخاب می کنیم . تمامی ساختار این Zone هم باید مانند شکل زیر باشد :
این قابلیت ها برای کاهش وجود Resource record های قدیمی در Primary DNS zone هستند ، منظور از رکورد های قدیمی رکورد هایی است که Update نشده اند و فغالیتی نداشته اند ، به طور مثال سازمان شما طوری است که کاربران و کامپیوتر ها سیال از آن استفاده می کنند مانند تبلیت ها و لپ تاپ ها ، ممکن است که Zone ها از تعداد زیادی Resource record های قدیمی که مربوط به آن کامپیوتر ها است انباشته شوند . این موضوع مشکلات زیادی را در پی خواهد داشت :
- درخواست هایی که از طرف کلاینت ها به سرور DNS فرستاده می شوند به طور ناصحیح اطلاعات قدیمی را دریافت می کنند
- با وجود این انباشتگی ، حجم Zone ها به طور کاذب زیاد می شود و در اجرای DNS سرور اختلال بوجود می آید
- ممکن است نام یکی این رکورد های تاریخ گذشته به یک Device دیگر داده شده باشد
- زمان دقیق ساخته شدن یک Resource record در یک Primary Zone ثبت شود ( حتما داینامیکی ساخته شده باشد نه دستی چرا که پشتیبانی نمی شود ) با فعال کردن قابلیت Aging and Scavenging این کار صورت می گیرد .
1- عمر یک رکورد به یک مدت زمان برای Refresh شدن بستگی دارد
2- زمان پاکسازی یک Resource record که تاریخ مصرف آن گذشته است و Refresh نشده است را تعیین کرد
- نکته : ماکروسافت پیشنهاد می کند که اگر شبکه بزرگی دارید زمان های این عملیات را کمتر از 6 ساعت و بیشتر از 10 روز قرار ندهید
شکل زیر عملیات Scaveging را در 72 ساعت تنظیم شده است را نشان می دهد :
-
دی ان اس | DNS چیست؟
دی ان اس | DNS یا Domain Naming System یا Domain Naming Service یک سرویس است که آدرس های IP را به اسم های دومین و برعکس تبدیل می کند و کار حفظ کردن آدرس ها را برای ما ساده می کند. در ساده ترین تعریف از DNS می توان گفت DNS سرور در نقش دفترچه تلفن برای آدرس های IP عمل می کند و شما دیگر نیازی به حفظ کردن آدرس های IP نخواهید بود. -
آیا مکانیزم کاری DNS سرورهای ویندوز و لینوکس تفاوت دارد؟
خیر ، سیستم کاری DNS سرور در همه سیستم عامل ها یکسان است اما نحوه پیاده سازی آنها کمی متفاوت ، در واقع مفاهیمی مثل Zone ، Record ، Forward Lookup و Reverse Lookup و ... در همه سرویس ها مشترک است ، در ویندوز بصورت گرافیکی و در لینوکس بصورت دستوری با سرویس BIND پیاده سازی می شوند -
آیا راه اندازی DNS سرور عمومی با DNS سرور داخلی متفاوت است؟
خیر ، تقریبا 99 درصد کار یکسان است و تفاوت اصلی در استفاده کردن از آدرس های IP عمومی در سرویس های عمومی است.