آشنایی با DNS- [ اموزشـــی ]

[بانو . ./]

.

فهرست . .






.

[بانو . ./]

آشنایی با DNS- قسمت اول



همانطور که می دانید؛ DNS یک الگوی نام گذاری سلسله مراتبی فراهم می کند. اطلاعات مربوط به فضای نامی (Name Space) در یک Data Store ذخیره می شوند. هر node در شبکه به عنوان یک ورودی (Entry) در DNS Data Store ذخیره می شود. به هر یک از این ورودی ها یک رکورد (Record) گفته می شود. این رکورد ها دارای انواعی هستند که نوع host را معین می کند. به عنوان مثال با استفاده از انواع رکورد می توان متوجه شد، که این رکورد مربوط به یک DNS Server، Mail Server و… است. در DNS Data Store اطلاعات بر اساس نام دسته بندی می شوند پس هر فضا باید دارای یک نام باشد. زمانی که یک Domain فرزند ایجاد می شود، نام والد به فرزند اضافه می شود. نتیجه آنکه نام Domain مکان سلسه مراتبی آن را مشخص می کند. بدیهی است در هر سطح لازم است این نام یکتا باشد. به محدوده ی فرزند Subdomain گفته می شود.

تذکر: واژه Domain به کاربرده شده در این قسمت ، دقیقا مطابق با واژه ای که در Active Directory به کار می رود نیست. در آنجا منظور از Domain گروهی از کامپیوتر ها هستند که توسط یک مدیریت مرکزی ، مدیریت می شوند اما در اینجا به یک فضای نامی در یک محدوده ی معین گفته می شود. در Active Directory آن مدیریت روی فضای نامی که در اینجا مطرح می شود اعمال می شود. Active Directory برای مکانیسم تحلیل نام از DNS استفاده می کند.
بخش های یک نام DNS

یک نام DNS شامل سه بخش اصلی است که عبارت اند از:
Root Domain

بالاترین مرتبه در ساختار سلسله مراتبی Domain گفته می شود که با یک نقطه نمایش داده می شود. می تواند یک رشته تهی نیز باشد.
Top Level Domains

دو،سه،چهار حرفی هایی هستند که بر اساس نوع فعالیت و یا مکان جغرافیایی مشخص می شوند.این نامگذاری توسط Internet Corporation for Assigned Names and Numbers یا ICANN روی اینترنت کنترل می شود.جدول زیر نمونه هایی از Top Level Domain را معرفی می کند:
Top Level Domain کاربرد
com سازمان های تجاری
gov سازمان های دولتی
edu موسسه های آموزشی
org سازمان های غیر تجاری
au مخصوص کشور استرالیا
ir مخصوص کشور ایران

از لحاظ مفهومی اینترنت به بیش از ۲۰۰ دامنه Top Level تقسیم می شوند که Top Level Domain ها خود دارای دو بخش هستند، دامنه های کشور ها و دامنه های عمومی. به دامنه های عمومی، دامنه های سازمانی و به دامنه های کشور ها، دامنه های جغرافیایی نیز گفته می شود. به غیر از این دو گروه، گروهی دیگر به عنوان رزرو شده وجود دارند که in-addr-arpa گفته می شوند. این گروه برای تبدیل آدرس IP به نام سلسله مراتبی DNS مورد استفاده قرار می گیرند. به تبدیل IP آدرس به نام Reverse Lookup گفته می شود. امروزه این پسوند ها تنوع بسیار بیشتری نسبت به گذشته پیدا کرده اند.

همچنین از اکتبر ۲۰۰۹، ICANN امکان استفاده از الفبای غیر انگلیسی را برای حوزه های جغرافیای محلی ایجاد کرد. به این اسامی internationalized domain name یا با اختصار IDN گفته می شود.
Second-Level Domains

هرفرد حقیقی و یا حقوقی می تواند یک Second Level Domain ثبت کند . این کار توسط شرکت های مختلفی روی اینترنت انجام می شود. بدیهی است که نام در این قسمت باید در والد خود یعنی top-Level Domain خود یکتا باشد. به عنوان مثال:
Second-Level Domains توضیح
Microsoft.com Microsoft corp
w3.org کنسرسیوم World Wide Web (www)
pm.gov.au نخست وزیر استرالیا
ErfanTaheri.com عرفان طاهری!



توجه داشته باشید که با توجه به آنکه DNS یک نام سلسه مراتبی است، هر حوزه بالا تر وظیفه مدیریت حوزه پایین تر خود را بر عهده دارد. به عنوان مثال حوزه ir وظیفه مدیریت second-Leve Domains خود را بر عهده دارد.
Sub-Domains

به تمامی سلسله مراتب های پس از Second-Level Domain گفته می شود. به عنوان مثال، Files.erfantaheri.com دامینی است که فایل های ضمیمه شده به مطالب در آن قرار می گیرد. مدیریت این Sub-Domain در اختیار حوزه ErfanTaheri.com یعنی حوزه parent خود است.
Host Name

به یک کامپیوتر روی اینترنت و یا یک شبکه خصوصی دلالت می کند. این قسمت سمت چت ترین بخش در آدرسی است که به آن fully qualified domain name یا FQDN گفته می شود. FQDN یک اسم کامل DNS است که از root domain آغاز شده و به یک host name ختم می شود.

Private Domain Namespace

به غیر از Domain روی اینترنت، سازمان ها می توانند به صورت داخلی و غیر مرتبط به اینترنت فضای نامی مختص خود را داشته باشند، و خود آن را مدیریت کنند. این اسامی روی اینترنت قابل Resolve نخواهند بود. همانند MyCompany.Local




راهنمای Domain Name

- تعداد سطوح در ساختار سلسله مراتبی را محدود کنید.مثلا ۴ سطح و سطح پنجمی وجود نداشته باشد. تعداد سطوح وظایف مدیریتی را افزایش می دهند و دسترسی ها را برای کاربران دشوار می کند.
- هر sub domain ای نسبت به parent والد خود باید دارای یک اسم یکتا داشته باشد.
- از انتخاب نام های طولانی پرهیز کنید. طول کلی یک FQDN نمی تواند از ۲۵۵ کاراکتر تجاوز کند ( با احتساب . ها )
- از اسم های ساده که راحت به یاد می مانند استفاده کنید.
- ویندوز سرور ۲۰۰۰ و ۲۰۰۳ از استاندارد RFC 1035 پیروی می کنند یعنی a-z , 0-9 و – (hyphen).
- DNS Service همچنین از Unicode پشتیبانی می کند,unicode شامل حروفی است که در ASCII (American Standard Code for Information Interchange ) موجود نیست .برای اطلاعات بیشتر به RFC 2044 مراجعه کنید.
- با آنکه هر دو سیستم نامی DNS و NetBIOS می توانند استفاده شوند، این کار اکیدا توصیه نمی شود و فقط استفاده از DNS به تنهایی توصیه می شود.
Zone ها

یک Zone نمایش یک Domain Namespace گسسته است. از zone های چندگانه جهت تقسیم وظایف مدیریتی به کار می رود. اطلاعات name-to-IP address در Database همان zone نگه داری می شود . مثلا name-to-IP address در خصوص Microsoft و Sales در Zone1 Database file ذخیره می شود. یک سرور می تواند مسئول چند Zone باشد و هر کدام از Zone ها حاوی یک یا چند Sub Domain باشند. به عنوان مثال یک سرور می تواند مسئول نگه داری Zone های Microsoft.com و ErfanTaheri.com باشد که هر کدام دارای Subdomain هایی هستند. با استفاده از فرآیند Delegation دو دامین a.contoso.com و b.contoso.com می توانند به صورت جداگانه مدیریت شوند.




انواع ZONE

یک دامین می تواند شامل تعدادی Zone باشد. هر Zone در هر دامین یک نوع نقش را ایفا می کند. نقش ها سه دسته اند:

۱) Primary: رکورد های موجود در این نوع منبع اصلی اطلاعات هستند. برای ایجاد پشتیبان از نوع Secondary استفاده می شود. این نسخه خواندنی – نوشتنی است.

۲) Secondary: یک نسخه معتبر از اطلاعات Primary هستند. این نسخه فقط خواندی است.

۳) Stub: یک کپی از رکورد های لازم برای شناسایی سرور های DNS معتبر برای آن Zone اصلی. این نوع Zone ها برای نگه داری نام DNS Serverهای معتبر برایZoneهای Delegate شده استفاده می شوند. این نسخه فقط خواندی است.
Name Server ها

یک DNS name server وظیفه ذخیره zone database file را بر عهده دارد.Name Server ها می توانند اطلاعات مربوط به یک یا چند zone را ذخیره کنند. یک DNS Client که به آن Resolver هم گفته می شود برای یافتن IP Address مربوط به یک Server به یک DNS Server مراجعه می کند.
مقدمه ای بر Name Resolution

Name Resolution به فرآیندی گفته می شود که طی آن IP آدرس نظیر اسم پیدا می شود یا بر عکس. به عنوان مثال زمانی که قصد دیدن وب سایت مایکروسافت را داریم از [ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ] استفاده می کنیم. در این فرآیند، IP address مربوط به web server درخواست شده یافت می شود.

عملیات Name Resolution دو نوع است:

forward lookup query : پیدا کردن IP از روی نام
reverse lookup query : پیدا کردن نام از روی IP

بدیهی است یک DNS server در zone ای می تواند کار کند که در آن اختیار دارد. معمولا چنانچه یک Name Server نتواند جستجو را پاسخ دهد ، جستجو را به Name server دیگری که می تواند آن را پاسخ دهد می فرستد. Name server ها نتیجه جستجو ها را cache می کنند تا ترافیک در شبکه کمتر شود.

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



- یک FQDN.

- نوع پرسش که مشخص کننده نوع رکورد دخواستی یا حالت خاصی از عمل پرسش دارد.





- تعیین کلاس نام DNS

به عنوان مثال یک Resolver یا DNS Client از Name Server یا DNS Serverسوال می کند: “آیا شما رکوردی از نوع A برای کامپیوتر Hostname.example.contoso.com دارید؟”

پرسش ها به روش های متفاوتی تحلیل می شود. در یک سناریوی ساده، یک کلاینت با DNS Server ارتباط برقرار می کند و سپس آن سرور در اطلاعات داخلی خود را (Local) بررسی می کند که آیا پاسخ سوال را دارد یا خیر. روش دیگر می تواند این باشد که DNS Server جهت پاسخ به کلاینت به DNS های دیگر مراجعه کرده و FQDN مورد نظر کلاینت را از آن ها پرسش می کند. به این روش Recursion می گوییم. در این روش در واقع، DNS Server خود تبدیل به یک DNS Client شده و از DNS Server های دیگری، پرسش می کند. روش دیگری که به ذهن می رسد آن است که کلاینت برای یافتن پاسخ سوال خود با کمک اطلاعاتی که از DNS Server ی که از آن پرسش کرده، خودش از DNS Server های مجددا پرسش کند. به این روش Iterative گفته می شود. به دلیل سرعت بخشیدن به عملیات، می توان اطلاعات به دست آمده را در هر مرحله به صورت موقت و برای مدتی کوتاه نگه داری کرد. به عنوان مثال می توان، روی Client اطلاعاتی که پرسش کرده را برای مدتی ذخیره کرد تا لازم نباشد هر بار از Server پرسش کند. همچنین در یک Server می توان اطلاعاتی که از Server های دیگر به دست آمده را نگه داری کرد تا لازم نباشد پرسش مجددا صورت گیرد. به فضای نگه داری این اطلاعات Cache گفته می شود.
مراحل پرسش از DNS

بخش ۱: یک کلاینت اگر نتواند در Cache داخلی خود نام مورد نظر را Resolve کند، یک پرسش به سمت DNS سرور می فرستد. در تصویر زیر سوالات با نمادQ و پاسخ ها با نماد A مشخص شده است. در مثال زیر نوع پاسخ دهی Recursion است.

فضای Cache داخل هر کامپیوتر ممکن است اطلاعات را به دو صورت به دست آورد:

۱) اگر فایل Hosts داخل کامپیوتر تنظیم شده باشد، همه نام ها و آدرس های IP مربوط به آن ها در زمانی که سرویس DNS Client شروع به کار می کند و در زمان به روز رسانی فایل آن اطلاعات به داخل Cache بارگذاری می شوند.

۲) رکورد هایی که طی پرسش های قبلی از DNS Server پاسخ داده شده است برای مدتی در Cache باقی می مانند.

بخش ۲: پرسش از یکی از Name Serverها به این صورت که ابتدا از Preferred DNS Server سوال می شود و چنانچه در دسترس نبود از Alternate DNS Servers.

بخش ۳: زمانی که یک سرور یک Query (پرسش) را دریافت می کنند، ابتدا آن را با رکورد های Database خود مقایسه می کند، اگر رکوردی متناسب یافت نشده، سپس Query را با حافظه Cache خود مقایسه می کند. چناچه جواب مناسبی یافت نشد، مراحل پرس و جو نام با توجه به تنظیمات سرور انجام می شود.





انواع Query

Iterative Query: در این روش، DNS Client با توجه به Root DNS Server، خود عملیات یافتن پاسخ Query را در صورتی که Local DNS Server از آن آگاه نبود انجام می دهد.

Recursive Query: در این روش، DNS Server خود مسئولیت پاسخ به Query را برعهده می گیرید و Client را در گیر نمی کند. این روش برتری های زیادی از جمله امکان Cache کردن پاسخ Query را دارد.

Reverse Query: در این نوع Query یک آدرس IP به یک نام DNS تبدیل می شود.

۱) Client یک Forward lookup query برای Local name server ارسال می کند.

۲) Local name server ابتدا اطلاعات خود را چک می کند. چون در Microsoft.com توانایی ندارد و در Cache خود اطلاعات مربوطه را ندارد؛ یک query برای یکی از DNS root server ها ارسال می کند.DNS root server یک جواب به Local name server ارسال می کند که آن را به Com name server ارجاع می دهد.

۳) Local Name Server یک query به Com Name server ارسال می کند و Com Name server آن را به Microsoft name server ارجاع می دهد.

۴) Local Name Server یک query به Microsoft Name server ارسال می کند . از آنجا که Microsoft Name server توانایی در آن قسمت شبکه را داراست ، IP آدرس [ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ] را بر می گرداند.

۵) Local Name server آدرس IP را به Client ارسال می کند.

۶) Name Resolution تمام شده و Client می تواند به [ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ] دسترسی پیدا کند.
انواع پاسخ

بر اساس حادثه ای که برای یافتن پرسش اتفاق می افتد، DNS Client ممکن است جواب های متفاوتی را از DNS Server دریافت کند:

- پاسخ معتبر: پاسخ داده شده توسط سروری است که مسئول مستقیم دامنه پرسش شده است و رکورد ها را در DB خود دارد.(Authoritative Answer)

- پاسخ مثبت: پاسخ مثبت شامل رکوردی است که پاسخ کلاینت است.(Positive Answer)

- پاسخ ارجاعی: این پاسخ مربوط به زمانی است که Recursion در سرور غیر فعال باشد. این رکورد ها به عنوان منبعی برای عمل Iteration است. (Referral Answer)

- پاسخ منفی: نشانگر آن است که نام پرسش شده در Domain مورد نظر وجود ندارد و یا نوع رکورد درخواست شده برای آن نام مناسب نیست. (Negative Answer)



Root Hints

برای انجام Recursion به صورت صحیح لازم است یک DNS Server بداند جستجو را از کجا آغاز کند. روی اینترنت، برای این منظور ۱۳ سرور اصلی که اطلاعات مقدماتی برای تحلیل نام را دارند در ویندوز به صورت پیش فرض وجود دارد. این فایل در System32\DNS است. این Root Hint اغلب برای نرم افزار Name Server خود از BIND (Berkeley Internet Name Domain) استفاده می کنند که توسط چهار دانشجوی دانشگاه کالیفرنیا، برکلی برنامه نویسی شده. در اغلب نسخه های Unix از این سرویس برای DNS استفاده می شود و فرمت انتقال پر سرعت (Fast Transfer Format) اطلاعات Zone با استفاده از فشرده سازی و انتقال همزمان چند رکور در یک Packet از مهمترین ویژگی های آن است. در ویندوز نیز از Fast Transfer Format پشیتبانی به عمل می آید به صورت پیش فرض مورد استفاده قرار می گیرد. به نحوی حیات شبکه اینترنت امروز وابسته به آن ۱۳ Name Server است. هرچند این تعداد قابل توسعه دادن است. در زیر مکان فیزیکی و اطلاعات این Name Server ها را مشاهده می کنید.آدرس DNS این Name Server ها به صورت Letter.root-servers.net است که letter با حرف نظیر آن در جدول جایگزین می شود. توجه داشته باشید که این به معنی یک سرور فیزیکی نیست و تجهیزاتی منحصر به فرد و قابل اطمینان استفاده می شود تا بتوانند ترافیک بسیار را بر عهده بگیرند. همچنین ۹ Name Server از ۱۳ تا، از تکنولوژی Anycast استفاده می کنند که باعث می شود ترافیک در شعبه های مختلف در مناطق جغرافیایی مختلف پخش گردد. همچنین این Name Server ها از لحاظ نظامی، سوانح طبیعی و… به خوبی حفاظت می شوند.





Caching

هم کلاینت و هم سرور نتایج به دست آمده از Query ها را برای بهبود عملکرد و کاهش ترافیک برای مدتی Cache می کنند. این Cache به صورت مستقل و جداگانه در سرور و کلاینت قرار دارد.
Name Resolver Caching

این Cache روی کلاینت صورت می گیرد و در Windows\System32\drivers\etc قابل مشاهده است. برای خالی کردن Cache از دستورات IP Configuration می توان استفاده کرد: ipconfig /flushdns
Name Server Caching

زمانی که یک Name server می خواهد یک query را جواب دهد ، ممکن است query های متعددی بفرستد تا بتواند جواب را پیدا کند.به طوری که هر query به یک name server دیگری را که در قسمتی از Domain namespace توانایی دارد ارجاع می دهد. با ذخیره کردن جواب query ها ، ترافیک در شبکه ها کاهش پیدا می کند و عملکرد بهبود می یابد. برای خالی کردن Cache سرور از دستورات DNS می توان استفاده کرد، dnscmd /clearcache

زمانی که یک name server یک query دریافت می کند اتفاقات زیر روی می دهند:

۱) سرور، query را برای مدت زمان خاصی cache می کند که Time To Live یا TTL گفته می شود. به صورت پیش فرض ۶۰ دقیقه
۲) سپس یک شمارنده معکوس فعال می شود.
۳) پس از آنکه شمارش به انتها رسید ، query را از cache پاک می کند.

بدیهی است که TTL بالا باعث می شود چنانچه تغییرات احتمالی رخ داده باشد ، کاربر تغییرات را از دست دهد تا زمانی که TTL به پایان رسد.اگر TTL کم باشد ، نتیجه آن خواهد بود که ترافیک افزایش می یابد زیرا TTL زودتر پایان می پذیرد و دوباره query ارسال می شود.
Negative Caching

به غیر از query های جواب داده شده ، سرور ها می توانند جواب منفی پیدا نشدن جواب یک query را نیز cache کنند تا به این ترتیب ضمن کم کردن ترافیک جواب query را زودتر client دریافت می کند.Negative Caching در RFC 1034 و ۲۳۰۸ تعریف شده است.




انواع سرور ها

سرور های اصلی

وقتی یک ZONE اصلی به یک سرور اضافه می شود، در واقع آن یک سرور اصلی برای آن ZONE است. سرور اصلی یک مقطه مرکزی برای به روز رسانی اطلاعات آن ZONE است. ZONE هایی که اولین بار ایجاد می شوند نیز همواره از این نوع اند.

۱) Standard Primary Zones: برای این Zone ها فقط یک Server می تواند نسخه اصلی را داشته باشد و سرور های دیگر نمی توانند تغییراتی روی اطلاعات اعمال کنند. از این رو این Zoneها بسیار آسیب پذیر اند.

۲) Active Directory Integrated Zone: استفاده از این نوع سبب می شود تا تمام نسخه ها قابل ویرایش باشند. برای استفاده از این نوع لازم است که Zone روی یک DC راه اندازی شود. اطلاعات این Zone ها در Application Directory ذخیره می شود و از مکانیستم Replication در Active Directory بهره خواهند برد.



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

استاندارد طراحی بیان می کند که حداقل دو سرور DNS برای هر Zone مورد نیاز است تا اگر یک سرور از دسترس خارج شد، سرور جایگزینی وجود داشته باشد. همچنین وجود سرور دوم، می توان به عنوان راهی برای کاهش ترافیک نیز به کار رود. سرور هایی که سرور های ثانویه اطلاعات را از آن ها به دست می آورد Masters گفته می شود که می تواند یک سرور اصلی یا یک سرور ثانویه باشد. سرور های ثانویه لازم است در نزدیک ترین فاصله ممکن به کلاینت هایی که بیشترین نیاز به نام های موجود در آن حوزه را دارند قرار گیرن. همچنین ممکن است محل سرور ها ثانویه را کنار Routers در Subnet دیگری یا در لبه ارتباط با WAN قرار دهند. این روش پیاده سازی موثر برای سرور های ثانویه به عنوان پشتیبان، در هنگام خرابی بخشی از شبکه یا سرور اصلی است. توجه داشته باشید که سرور ثانویه نباید به مستقیما به همان زیر ساخت سرور اصلی متصل باشد تا در صورت بروز مشکل در آن زیرساخت، سرور ثانویه در دسترس باشد.


سرور های Stub

سرور های Stub حاوی Zone های Stub هستند. یعنی حاوی یک نسخه ساده شده از اطلاعات Zone که فقط شامل لیستی از DNS Sever ها معتبر برای Master Zone خودش است. یک Stub برای پاسخ گویی به Query ها از آن لیست استفاده می کند. بنابراین یک سرور Stub فقط حاوی رکورد های NS از Master خود هستند. مزایای آن بهبود کیفیت تحلیل نام به دلیل آنکه نیاز نیست Recursion از root اتفاق افتد. مدیریت یک سرور stub ساده تر است و رکورد های NS به روز هستند.
سرور های Chaching-Only

این نوع سرور ها هیچ Zoneای را در DB خودنگه داری نمی کنند و فقط اطلاعات آن ها وابسته به Cache های Query های قبلی آن ها است. اطلاعات در طول سرویس دهی و بر اساس سرویس دهی به Queryها کسب می شوند. اگر بین سایت ها یک ارتباط کم سرعت وجود داشته باشد، استفاده از این سرور ایده آل است چرا که با ساختن Cache ترافیک روی لینک با سرعت کم کاهش پیدا می کند. همچنین اگر ترافیک هزینه زیادی داشته باشد، Caching-Only Server می تواند هزینه ها تا حدی کاهش دهد. از طرفی دیگر پاسخ Queryها با استفاده از این سرور سریع تر داده می شود و Performance کلی بهبود می یابد. از آنجایی که Caching-Only Server ترافیک انتقال اطلاعات Zone را ندارند، ترافیک نرمالی دارند و به سخت افزار خاصی نیاز ندارند.







.

[بانو . ./]

آشتایی با DNS- قسمت دوم



ایجاد یک Zone

برای ایجاد یک Zone کافی است در کنسول DNS Manager، روی یکی از قسمت های Forward Lookup Zone یا Reverse Lookup Zone بر اساس نوع Zone مورد نظر، کلیک راست کرده و گزینه New Zone را بزنید. سپس با زدن Next، بر اساس Type مورد نظر، Zone Type را انتخاب می کنیم. با زدن Next در مرحله بعدی نام Zone که معرف DNS Namespace است را وارد می کنیم. به عنوان مثال Contoso.com.

در مرحله بعدی تعیین می کنیم یک فایل جدید برای نگه داری رکورد ها ایجاد شود یا از یک فایل موجود استفاده شود. سپس در مرحله بعدی وضعیت DDNS را تعین می کنیم. و سپس با زدن Finish، Zone مورد نظر ساخته می شود.





Forwarder ها

Forwarders این امکان را فراهم می آورند تا یک سرور DNS پرسش های دریافت شده از کلاینت های داخلی را به یک سرور بالا تر بفرستد. در برخی موارد مدیران شبکه تمایل ندارد که سرور های شبکه داخلی مستقیما با سرور های خارجی در ارتباط باشند. برای مثال اگر در سازمانی از طریق یک لینک کم سرعت به اینترنت متصل است، برای کارایی بهتر می توان فقط از یک DNS Server برای ارتباط خارجی استفاده کرد. البته این موضوع به قیمت به وجود آمدن Single Point of Failure تمام می شود.

یک نوع دیگر استفاده متداول از Forwarding این است که کلاینت ها و سرور های شبکه داخلی که پشت Firewall هستند نام های مورد نظر خود را به صورت Secure به سرور های خارجی ارسال کنند. بنابراین باید Port های مورد نیاز به سمت خارج باز باشد. حال اگر یک DNS Server برای ارتباطات خارجی در سمت خارج Firewall قرار دهیم، تنها کافی است Port ها برای یک مقصد باز باشد.

در نهایت استفاده ی دیگر از Forwarders در یک Forest سلسله مراتبی Active Directory است. در ساختار سلسله مراتبی Active Directory به دلیل Delegation کلاینت های دامین والد قادر خواهند بود که نام کلاینت های فرزند را به تحلیل کنند، اما بدون وجود Forwarders هیچ مکانیسمی برای تحلیل نام کلاینت های والد برای کلاینت های فرزند وجود ندارد. با استفاده از تنظیم Forwarder به Root DNS Server در Forest این امکان پدید می آید.






Conditional Forwarders

واژه Conditional Forwarding توصیف کننده ی تنظیمی روی DNS Server است که Query ها برای یک دامین معین به یک سرور معین Forward می شود.یکی از ده ها سناریوی متداول آن است که دو کمپانی مجزا، با یک دیگر ملحق می شوند. به عنوان مثال Fabrikam و Contoso دو شبکه مجزا با Active Directory و یک لینک ۱۲۸kbps دارند. برای آنکه هر کلاینت در یک کمپانی بتواند نام کلاینت در کمپانی دیگر را تحلیل کند، در دو DNS Server در Conditional Forwarding تعریف می گردد. اکنون تمام Queryهای کمپانی Contoso به غیر از Fabrikam.com به DNS Server در ISP هدایت می شود و Queryهای مربوط به Fabrikam به DNS Server مربوطه Forward می شود. البته راه حل دیگر نگه داری یک Secondry Zone برای دامین طرف دیگر در هر کمپانی است. معمولا این روش به دلیل افزایش ترافیک، احتیاط های امنیتی و بیشتر به روز بودن اطلاعات استفاده نمی شود و Conditional Forwarding متداول تر است.

برای تعریف Conditional Forwarder روی Container به نام Conditional Forwarders کلیک راست کرده و new را بزنید. سپس DNS Namespace و IP Address های مربوط به DNS Server های Domain را وارد کنید. اگر در محیط Active Direcotry هستید، می توانید تعیین کنید اطلاعات این Forwarding در محیط Replicate شود. همچنین زمان timeout قابل تنظیم است. توجه داشته باشید، به صورت پیش فرض ۵ ثانیه است.چنانچه Reverse Lookup Zone به طرز صحیح ساخته نشده باشد، تبدیل IP به نام سرور ها در اینجا انجام نمی شود.






انواع رکورد ها

همانطور که گفته شده DNS Server دارای یک Database است که از رکورد تشکیل شده است. این رکورد ها انواع بسیاری دارند که در اینجا تنها متداول ترین انواع را مورد بررسی قرار می دهیم. با این رکورد ها Resource Record نیز گفته می شود.

Host Record – A: این نوع رکورد بیشترین تعداد در هر DBای را دارد و برای ارتباط نام یک Host به IP address آن به کار برده می شود. اگر با یک host با استفاده از IP Address ارتباط دارید ولی با DNS Name نمی توانید، اگر تنظیمات DNS صحیح باشد، ممکن است رکورد مورد نظر وجود نداشته باشد. برای ساخته شده اتوماتیک این رکورد در قسمت DHCP توضیح داده شد.

AAAA: این رکورد مشابه رکورد A برای IPv6 است. (Quad A خوانده می شود.)

Alias – Cname: این رکورد ها در واقع اسم مستعاری برای یک host هستند. رکورد های سرویس های مهم در شبکه اغلب از نوع Cname یا canonical name است که علاوه بر داشتن یک یک رکورد A یک Cname نیز دارند. اغلب رکورد های www و یا FTP از این نوع ساخته می شود.

DName: رکورد Delegation Name رکوردی است مشابه Cname است با این تمایز که در بر گیرنده ی subdomain خود نمی باشد.

MX: رکورد MX یا Mail eXchanger توسط Application های ایمیل برای شناسایی Mail Server در Domain به کار می رود. اغلب چندین record از این نوع در یک Domain برای سرور های مختلفی با اولویت های متمایز تعریف می شود تا در دسترس بودن سرویس گارانتی شود. هرچه عدد اولویت کوچکتر باشد، اولویت بیشتری دارد.

جهت ساختن یکی از انواع رکورد های فوق، در دامین مطلوب، کلیک راست کنید و گزینه مناسب را انتخاب کنید.

چنانچه نوع رکورد مورد نظر از بین انواع لیست شده نمی باشد، کافی است گزینه Other New Records را بزنید.

PTR: رکورد PTR یا PoinTeR فقط در Reverse Zone امکان ساخت دارد. برای تبدیل یک IP Address به FQDN استفاده می شود. اضافه کردن رکورد های PTR به صورت اتوماتیک در قسمت DHCP توضیح داده شده است.

SRV: رکورد های SRV یا Service Location برای پیدا کردن محل یک سرویس معین در Domain به کار می روند. به عنوان مثال سرویس NetLogon در Active Directory با استفاده از رکورد های SRV مربوط به LDAP می تواند محل DCها را پیدا کند. این رکورد ها به صورت خودکار معمولا ساخته می شوند.

SOA: زمانی که Zone جدید ایجاد می شود دو رکورد به صورت خودکار ساخته می شوند. رکورد های SOA و NS. رکورد SOA یا Start Of Authority اطلاعات اولیه ای در خصوص Zone را معین می کند. این تنظیمات در خصوص نحوه انتقال اطلاعات بین سرور اصلی با سرور های ثانویه است. بازه زمانی به روز رسانی به صورت پیش فرض ۱۵ دقیقه یک بار است و در صورت عدم موفقیت هر ۱۰دقیقه یک بار تلاش مجدد صورت می گیرد. بدون پاسخ گویی یک سرور اصلی به صورت پیش فرض یک سرور ثانویه تا ۱ روز اطلاعات نسبتا معتبری دارد و به Queryها پاسخ می دهد. TTL مربوط به عمر رکورد ها در DNS Cache می شود و ارتباطی به عمر رکورد های Zoneندارد. TTL for this record مربوط به TTL رکورد SOA می شود. TTLها در اینجا به صورت پیش فرض ۱ ساعت هستند.

NS: رکورد های NS یا Name Server سرور های DNS در یک Zone تعیین می شوند.

برای ویرایش رکورد های NS و SOA روی Zone مورد نظر کلیک راست کنید و properties را بزنید و یا از طریق خود رکورد وارد قسمت تنظیمات شوید.

RP:رکورد Responsible Person معرف شخصی است که مسئولیت Zone را بر عهده دارد. در Name Server ها مختلف معمولا به جای علامت @ از . استفاده شده است و به صورت پیش فرض نام hostmaster قرار می گیرد. در نظر داشته باشید که این اسم باید با یک . به اتمام برسد.

TXT: رکورد های Text رکورد هایی هستند که برای قرار دادن متن قابل خواندن توسط انسان ساخته شدند. امروزه ابزار های ماشین همانند Sender Policy Framework (SPF) و DomainKeys Signed Mail (DKIM) از این رکورد برای تایید هویت استفاده می کنند.

چنانچه از یک Active Directory Intergrated Zone استفاده نشود، اطلاعات رکورد ها در یک فایل متنی ذخیره می شود.






.

[بانو . ./]

.

آشنایی با DNS – قسمت سوم



Aging و Scavenging

Aging به فرآیندی گفته می شود که در آن با استفاده از Timestamp، طول عمر Resource Record هایی که به صورت Dynamic در DNS اضافه شده اند معین می گردد. Scavenging به فرآیندی گفته می شود که در آن Resource Record هایی که عمر آن ها سپری شده است، حذف می گردند. بدیهی است Scavenging زمانی می تواند عمل کند که Aging عمل می کند. این فرآیند سبب می شود تا Resouce Record ها دارای تعداد مدیریت شده ای باشند زیرا نود هایی که از شبکه خارج شده اند پس از مدتی Resource Record های مربوط به آن ها حذف می شود و حجم داده های DNS Server نیز مدیریت می شود.

برای فعال کردن Aging در یک Zone لازم است ابتدا Aging در سطح سرور و سپس در سطح Zone فعال گردد. برای فعال کردن Aging در سطح سرور، روی سرور مورد نظر در کنسول DNS کلیک راست کنید و گزینه ی Set Agiing/Scavenging For All Zones را بزنید. سپس از Dialog Box باز شده،گزینه ی Scavenge Stale Resource Records را فعال کنید. با آنکه این گزینه Scavenging را برای تمام Zone ها فعال می کند، Zone های Active Directory Intergrated مستثنی هستند. پس از زدن دکمه OK یک Dialog Box دیگر جهت تایید فعال سازی در آن Zone ها نمایش داده می شود.

برای فعال کردن Aging و Scavenging در سطح Zone روی Zone مورد نظر کلیک راست کنید در Properties را بزنید. در زبانه general دکمه Aging را بزنید. اکنون با فعال کردن Scavenge Stale Resource Records، این قابلیت در آن Zone فعال می گردد.




Timestamping

همانطور که گفته شد، Aging وابسته به Timestamp هایی است که Resource Record ها با خود در DNS ثبت می کند. Active Directory Intergrated Zone ها، به صورت پیش فرض، حتی در صورتی که Scavenging غیر فعال باشد، Timestamping را برای تمام Resouce Record هایی که Dynamic ثبت شده اند، انجام می دهند. تمام Resource Record هایی که در هر نوع Zone ساخته می شوند دارای Timestamp=0 هستند و Aging در خصوص آن ها کار نمی کند.
Non-refresh interval

بازه زمانی است که در آن، DNS Server روی Timestamp یک Resouce Record معین Update انجام نمی دهد. با استفاده از گزینه از پروسه و ترافیک های غیر ضروری جلوگیری به عمل می آید.
Refresh interval

بازه زمانی پس Non-refresh interval است که در آن، Update ها روی Timestamp پذیرفته می شود اما تا پایان آن عملیات Scavenge برای یک Resource Record معین صورت نمی گیرد.

با تنظیمات پیش فرض هر دو گزینه ۷ روز می باشند بنابراین، حداقل مدت زمانی که یک Resouce Record می تواند Scavenge گردد ۱۴ روز خواهد بود.





انجام Scavenge

این پروسه می تواند دستی و یا خودکار انجام شود. برای انجام خودکار آن، در DNS Server Configuration به زبانه ی Advanced رفته و گزینه Enable Automatic Scavenging for stale Record را فعال کنید. و برای انجام آن به صورت دستی کافی است روی گره Server در کنسول DNS کلیک راست کنید و گزینه ی Scavenge Stale Resouce Record را بزنید. فراموش نکنید، برای انجام Scavenge باید مراحل فعال سازی آن را که پیش تر گفته شد نیز انجام دهید.





Netmask Ordering

با استفاده از این متد اگر از یک رکورد A چند رکورد موجود باشد در ابتدایی ترین رکورد، رکوردی به DNS Client داده می شود که در Subnet خودش باشد. این قابلیت به صورت پیش فرض فعال است و جهت ویرایش آن به زبانه Advanced در Server Properties مراجعه کنید.
Round Robin

با استفاده از این متد، بار روی سرور ها توسط DNS Server تقسیم می شود به این صورت که اگر برای یک سرور چند رکورد A موجود باشد، در ابتدایی ترین رکورد، رکوردی به DNS Client داده می شود که به DNS Client قبلی داده نشده است. این قابلیت به صورت پیش فرض فعال است و جهت ویرایش آن به زبانه Advanced در Server Properties مراجعه کنید. توجه داشته باشید، Netmask Ordering بر Round Robin در اولویت است.
Zone Replication

Zone Replication به فرایند همسان سازی اطلاعات دو Active Directory IntegratedZone روی دو سرور متمایز گفته می شود. یک Active Directory Integrated Zone علاون بر ویژگی های منحصر به فردی که یک Microsoft DNS Zone دارد، دارای قابلیت هایی همچون Secure Dynamic Update و قرارگیری Resource Record ها در دایرکتوری و Replicate شدن آن ها به عنوان یک Application Directory Partition به آن Zone اضافه می شود.

به صورت پیش فرض، در زمان نصب Active Directory دو Application Directory Partition به صورت خودکار به نام های DomainDnsZones و ForestDnsZones ایجاد می شود که به ترتیب بین تمام Domain Controller ها در Domain و Forest آن ها Replicate می شود. جهت کسب اطلاعات بیشتر در خصوص Application Directory Partition مراجعه شوند به “Application Directory Partition”

هر دو Application Directory Partition دارای دو Subdomain جدا برای دسترسی هستند. به عنوان مثال برای دامین port80.erfantaheri.com با Forest Root به erfantaheri.com دو Subdomain به صورت DomainDnsZones.port80.erfantaheri.com و ForestDnsZones.erfantaheri.com وجود خواهد داشت.

Replication Scope

همانطور که گفته شد، اطلاعات Application Directory مربوط به DNS فقط به دامین کنترلر هایی Replicate می شود که دارای نقش DNS Server باشند. این تنظیم در زمان ایجاد Zone جدید قابل تغییر است. برای ویرایش آن پس از ساخت Zone کافی است روی Zone مورد نظر کلیک راست کنید و گزینه properties را بزنید سپس در زبانه general در قسمت Replication دکمه Change را بزنید. در Dialog Box باز شده، گزینه مطلوب را انتخاب کنید.

این امکان وجود دارد که یک Application Directory Partition را به صورت دستی بسازید و تنظیمات آن را به نحوی انجام دهید که حاوی اطلاعات یک DNS Zone باشد.






Zone Transfer

Zone Transfer به پروسه همسان سازی اطلاعات بین دو Primary Zone و Master Zone گفته می شود. اگر DNS Server روی سروری نصب شود که دامین کنترلر نباشد، امکان ساخت Active Directory IntegratedZone وجود ندارد. در این صورت قابلیت Zone Replication برای آن سرور در دسترس نخواهد بود. پروسه Zone Transfer توسط یک Secondary Zone آغاز می گردد و اطلاعات مربوط به Zone را از یک Master Zone می گیرد. Master Zone می تواند یک Primary Zone و یا Secondary Zone دیگر باشد. همانطور که گفته شد، در برخی از سناریو ها ممکن است به جای Conditional Forwarding از یک Secondary Zone استفاده شود هر چند این مسئله ایده مناسبی نمی باشد.





Zone Transfer Initiation

هر کدام از سه عامل زیر می تواند سبب آغاز فرآیند Zone Transfer باشد:

۱) زمانی که یک سرور ثانویه (Secondary Server) فعال می شود.
۲) زمانی که مقدار Refresh Interval از رکورد SOA سپرش شود.
۳) هنگامی که تغییراتی روی Primary Server انجام شود و روی سرور تعیین شده باشد تغییرات را به Secondary Servers اعلام کند.

زمانی Zone Initiation آغاز می شود، Secondary Server یک All Zone Transfer Query به اختصار AXFR یا Incremental Zone Transfer Query به اختصار IXFR از سرور Master می گیرد. طی یک IXFR Query فقط تغییرات منتقل می شوند اما با استفاده از AXFR Query تمام اطلاعات Zone را منتقل می کند. ویندوز سرور ۲۰۰۰ به بعد به صورت پیش فرض از IXFR Query استفاده می کند اما ویندوز NT از IXFR Query پشتیبانی نمی کند.

جهت فعال سازی Zone Transfer به Zone Properties رفته و در زبانه Zone Transfer گزینه مطلوب را انتخاب کنید. توجه داشته باشید، گزینه To any server دارای ریسک امنیتی است و اطلاعات DNS Server در این حالت می تواند در اختیار هر DNS Server دیگری قرار گیرد. در صورت انتخاب گزینه only to servers listed in the Name Server tab نیاز به آن دارد که Secondary Server ها دارای رکورد NS پیش از عملیات Zone Transfer باشند.






Notification

از آنجایی که عملیات Zone Transfer توسط Secondary Zone آغاز می شود، این امکان وجود ندارد تا در صورت به روز شدن اطلاعات آن ها را مستقیما در اختیار Secondary Zone ها قرار داد. برای این منظور از Notification استفاده می گردد تا در صورت بروز تغییری Secondary Zone ها را باخبر ساخته و آن ها عملیات Zone Transfer را شروع کنند. برای تنظیمات Notification در زبانه Zone Transfer در Zone Properties رفته و دکمه notify را بزنید.




Zone Delegations

مدیریت یک Namespace بزرگ همانند اینترنت کار بسیار بسیار دشواری است. لذا باید مدیریت دامنه ها به اجزایی واگذار شود. هنگامی که مسئولیت یک sub domain در یک DNS namespace به یک شخص سوم واگذار می شود، به این فرآیند Delegation گفته می شود. به عنوان مثال مدیریت DNS در دامنه ی Microsoft.com به Microsoft corporation واگذار شده است و مایکروسافت می تواند خود رکورد ها و namespace مربوط به خود یعنی Microsoft.com را مدیریت کند. به عنوان مثال وظیفه ایجاد subdomainای به نام mydomain.microsoft.com را خود بر عهده می گیرد. توجه داشته باشید، Delegation بر Forwarder در پاسخ Query ها اولویت دارد.

Parent Domain دارای دو رکورد از نوع A و NS است که اشاره به سرور مربوط به Child Domain می کند. این رکورد ها هم برای انتقال کنترل حوزه و هم پاسخ به Iterative Queryها ضرورت دارند. به عنوان مثال با توجه به تصویر زیر، یک سرور معتبر برای Domainای که Delegate شده است(example.microsoft.com) همانند ns1.us.example.microsoft.com لازم است. برای این امر دو رکورد در Microsoft.com مورد نیاز است.

۱) یک رکورد NS: به این رکورد که به آن Delegation Record می گوییم، جهت ساختن Delegation و پاسخ به Query کلاینت DNS که توسط آن ns.usa.example.microsoft.com را یک Nameserver معرفی کند.

۲) یک رکورد A: به این رکورد که Glue Record می گوییم، جهت تبدیل نام nameserver در Delegation Record به IP Address آن به کار برده می شود.




Stub Zone

یک Stub Zone در واقع یک کپی از اطلاعات یک Zone است که حاوی اطلاعات پایه در خصوص Zone اصلی است. هدف Stub Zone ها آن است که یک DNS Server بتواند Query های دریافتی برای یک Zone را به طرز موثری Forward کند. مزیت دیگر Stub Zone ها قابلیت Update شدن آن ها از Master Zone است. عملکرد Stub Zone ها مشابه Zone Delegation است با این تمایز که ویژگی های آن سود می بریم.







.

[بانو . ./]

globalnames zone و DNS در ویندوز سرور ۲۰۰۸


پیش از ارائه ویندوز سرور ۲۰۰۸ بسیاری از شبکه های مایکروسافتی از یک وینس (WINS) سرور در محیط شبکه استفاده می کردند. WINS یک روش تبدیل نام (name resolution) مشابه DNS است که از پروتکل نت بایوس (NetBIOS) روی TCP/IP که NetBT هم گفته می شود استفاده می کند. این پروتکل بیشتر در سیستم عامل های قدیمی رایج بود. مشابه Windows 95/98 and Windows NT 4.0. اما همانطوری که می دانید در پروتکل IPv6 دگر از این دو پشتیبانی نمی شود .

برای کمک کردن مهاجرت به DNS در خصوص تمام تبدیل نام ها در ویندوز سرور ۲۰۰۸ قسمتی حیاتی طراحی شده که به نام GlobalNames Zone و یا GNZ است. برخی مدیران شبکه به سختی می خواهند تا یک نام تک قسمتی ثابت مشابه WINS داشته باشند. مثلا این اسم می تواند به یک سرور پر استفاده در یک شرکت بزرگ تعلق بگیرد که یک IP ثابت (Static) دارد.در واقع GNZ طراحی شده تا بتواند رکوردهای چنین سرور هایی را شامل شود.

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

کلاینت DNS با چسباندن پسوند(ها) ی مناسب قادر به resolve نام یک قسمتی است. مثلا اگر کلاینت دستور زیر را بزند


Ping Webserver


و پسوند DNS ماشین مثلا ErfanTaheri.local هست. حالا کلاینت خودکار پسوند را اضافه می کند و از یک Fully Qualified domain Name ( به اختصار FQDN ) استفاده می کند.

پسوند دی ان اس ( یا DNS suffix ) مناسب بر اساس آنکه کلاینت عضو چه دامینی است اعمال می شود. البته می شود با استفاده از تنظیمات TCP/IP و یا GroupPolicy نیز پسوند اعمال کرد. ترتیب اعمال این پسوند ها در خصوص کلاینتی که Windows XP یا Vista دارد به صورت زیر است:

۱) پسوند اصلی که یک کامپیوتر عضو دامین می شود.

تذکر: اگر Group Policy اعمال شده باشد این پسوند استفاده نمی شود.

۲) پسوند های که از طریق لیست پسوند های DNS از Group Policy اعمال می شود. (GPO DNS Suffix Search List) به ترتیبی که در لیست تنظیم شده اند.

۳)اگر سیاست گروهی اعمال نشده باشد:

- پسوند خاص هر کانکشن (اینترفیس های مختلف کارت شبکه) استفاده می شود(connection-specific DNS)

- در خصوص ویندوز ویستا فقط اگر از IPv6 و DHCPv6 استفاده شده باشد، اگر یک connection-specific suffix search list توسط DHCPv6 تنظیم شده باشد، پسوند های در لیست به ترتیب قرار گیری در لیست اعمال می شوند.

سیستم عامل های جدید مایکروسافت همانند ویندوز ویستا، سرور ۲۰۰۸ و ویندوز ۷ می توانند از یک متد تبدیل نام جدید به نام Link-Local Multicast Name Resolution (به اختصار LLMNR) نیز استفاده کنند.( همچنین multicast DNS یا mDNS نیز گفته می شود) با این متد جدید می توان نام کامپیوتر هایی را که در همان سگمنت (segment) هستند را در زمانی که DNSسرور در دسترس نیست تبدیل کرد. برای مثال در سناریویی که روتر(Router) میان یک Subnet و Subnet که در آن DNS سرور وجود دارد خراب شود، یک کامپیوتر می تواند نام کامپیوتر هایی که در همان Subnet هستند را تبدیل کند. این ویژگی بسیار مهم است.

به صورت پیش فرض یک DNS Sever ابتدا تلاش می کند تا جواب یک پرسش(query) را از روی اطلاعات Local Zone بدهد و سپس به GNZ مراجعه می کند. به منظور تنظیم بررسی رکورد های GNZ دستور زیر را در خط فرمان وارد کنید:
Dnscmd

ServerName /config /Enableglobalnamessupport 1

توجه : در دستور فوق ServerName نام سرور دی ان اس شما است

[بانو . ./]

.



ویژگی های جدید DNS


Microsoft DNS Server با آنکه با RFC های مرتبط به DNS که توسط Internet Engineering Task Force یا به اختصار IETF منتشر شده است، سازگار است دارای ویژگی های منحصر به فردی برای سرویس های NOS یا Network Operationg Syste مخصوص مایکروسافت است که تحت AD DS فعال می گردند. همانطور که می دانید، در یک Active Directory integrated Zone محل ذخیره سازی اطلاعات حتی تغییر می کند و قابلیت Secure DDNS در دسترس قرار می گیرد. جهت پشتیبانی از RODC ها، یک نسخه Primary فقط خواندنی طراحی شده که روی RODC ها قرار گیرد.

در +Windows Server 2008 R2 قابلیت background zone loading اضافه شده است که این ویژگی سبب می شود سرعت boot شدن سرور افزایش یابد. پیش از شروع سرویس دهی DNS Server نیاز است تمام رکورد ها load شوند. اگر یک سرور دارای Zone های متعدد با تعداد رکورد های بالایی باشد، زمان لازم قابل توجه خواهد بود. در یک گام برای حذف WINS Server از شبکه ها ویژگی جدید GNZ به DNS اضافه شده است تا بتواند از اسامی تک سیلابی پشتیبانی کند.

جهت افزایش محافظت در برابر Spoofing سرویس DNS از قابلیت Global Query Block List بهره می برد. توسط این قابلیت جدید، زمانی که کلاینت ها از پروتکل هایی همانند Web Proxy Automatic Discovery یا WPAD یا Intra-site Automatic Tunnel Addressing Protocol یا به اختصار ISATAP و از DNS جهت Resolve کردن اسامی استفاده می کنند می تواند برای کاربرانی که از قابلیت Dynamic Update بهره می برند مخاطره انگیز باشد.
DNS Security Extensions

DNS یک سرویس حیاتی برای زیرساخت شبکه ها به شمار می آید و امنیت آن بسیار اهمیت دارد. همه عمیقا بر این باورد هستند که ارتباطات DNS لازم است امن گردد با وجود تلاش های بسیار، به دلیل موانع متعدد پیاده سازی های یک DNS امن به اندازه کافی موفق نبوده است. DNS به خودی خود، هیچ قابلیت امنیتی را فراهم نمی آورد و در برابر حملاتی همچون Spoofing، Man In the Middle و Cache Poisoning ضعیف است. DNS Security Extensions یا به اختصار DNSSEC در RFC 2535 معین گردیده است و با استفاده از Public Key infrastructure و امضای دیجیتال ارتباطات DNS امن می گردند. Windows Server 2008 R2 از DNSSEC برای هر دو نوع Active Directory integrated Zone و File-backed Zone پشتیبانی به عمل می آورد. اگر DNSSEC روی Active Directory Integrated Zone فعال گردد، امکان Dynamic Update دیگر در دسترس نخواهد بود و از آن پس نیاز به Manual Update خواهد بود.

تمام پاسخ ها به Query ها در DNSSEC دارای امضای دیجیتال هستند بنابراین با بررسی امضا توسط Resolver (کلاینت) این امکان ایجاد می شود که صحت پاسخ بررسی گردد. مسئله قابل توجه آن است که DNSSEC سرویس confidentiality (محرمانگی) را برای ارتباطات DNS به صورت عادی فراهم نمی کند و به عبارت ساده تر، ارتباطات رمزنگاری نمی شوند اما سرویس Authentication وجود دارد. از سوی دیگر DNSSEC در برابر حملات DoS به صورت مستقیم محافظتی ایجاد نمی کند با این وجود، به دلیل امضا می تواند دارای مزایایی نسبت به DNS باشد. مایکروسافت اکیدا توصیه می کند در پیاده سازی DNSSEC از IPSec جهت ایمن سازی ارتباطات بین کلاینت و سرور استفاده گردد.
DNS Cache Locking

طراحی DNS بر این اساس که با استفاده از Caching سبب شود سرعت پاسخ گویی به Query ها برای نام هایی که Reslove شده اند، بالا برود. یکی از حملات به DNS به Cache Poisoning مشهور است. در این نوع حملات با استفاده از رکورد های malicious (بد اندیش) که روی حافظهCache باز نویسی(Overwrite) می شود سبب می شود تا ترافیک به نقطه ی دیگری منتقل گردد. ویژگی جدید Cache Locking سبب می شود، تا Cache در مدت زمان TTL رکورد نتواند Overwrite شود. این ویژگی سبب می شود که DNS در برابر این دسته از حملات محافظت نسبی پیدا کند.

Cache Loching با درصدی از زمان TTL قابل تنظیم است. به صورت پیش فرض ۱۰۰% است. این میزان در متغیر CacheLockingPercent در Registry تعیین شده است و برای ویرایش آن به مسیر زیر می توانید بروید.

HKEY_LoCAL_MACHINE\SYSYTEM\CurrentControlSet\servi ces\DNS\Parameters settings

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

dnscmd /config /CacheLockingPercent percentvalue

percentvalue معرف درصد مطلوب است.



DNS Socket Pool

DNS Server های قدیمی همواره از یک Source Port برای Resolve کردن Query های دریافتی خود استفاده می کنند. این مسئله سبب می شود حملات Cache Poisoning آسان تر صورت پذیرد. Microsoft DNS Server در Windows Server 2008 R2+ دارای قابلیتی است که از یک مخزن Socket به صورت random یکی را انتخاب کرده و آن را برای ارسال Query خود استفاده می کند. علاوه بر آن از یک Transaction ID که به صورت Random ساخته می شود نیز استفاده می گردد. DNS Socket Pool به صورت پیش فرض فعال است و از ۲۵۰۰ آدرس Socket مختلف استفاده می کند که می تواند تا ۱۰۰۰۰ افزایش یابد. بدیهی است اندازه بزرگتر محافظت بهتری به عمل می آورد. همچنین این امکان وجود دارد برخی از آدرس از pool مستثنی گردند. برای تنظیم این ویژگی که در Registry ثبت می گردد می توانید از دستورات زیر استفاده کنید. دو دستور ابتدا وضعیت فعلی را معین می کند.

dnscmd /info /SocketPoolSize
dnscmd /info /SocketPoolExcludePortRanges
dnscmd /config / SocketPoolSize value
dnscmd /config /SocketPoolExcludePortRanges value

value مقدار مطلوب است.


DNS Devolution

این ویژگی جدید، سبب می شود تا کلاینت های یک Child Domain در یک Forest بتواند به Resource های روی parent domain آسان تر دسترسی پیدا کنند. با استفاده از این ویژگی دیگر نیاز به بیان دقیق FQDN نخواهد بود و DNS Server برای پاسخ گویی به Queryها تا زمانی که پاسخ را پیدا کند به اندازه devolution به بررسی سطوح بالاتر از Forest می پردازد.

به عنوان مثال دامین child.contoso.com را تصور کنید. یک Query برای FileServer0 به صورت خودکار FQDN های FileServer0.Child.contoso.com و FilerServer0.Contoso.com را بررسی می کند. اندازه پیش فرض Devolution به ساختار Forest مرتبط است. در یک Single Domain Forest (جنگل تک درختی) این عمل صورت نمی گیرد و در خصوص دامین هایی که دارای یک Forest Root هستند به دلیل آنکه دارای تمایز در دامین هستند صورت نمی گیرد. جهت تنظیم این ویژگی به Group Policy در شاخه Configuration\Administrative Templates\Network\DNS Client مراجعه گردد. همچین با استفاده از Registry تنظیم این قابلیت امکان پذیر است:

در شاخه HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Win dows NT\DNSClient مقدار UseDomainNameDevolution معرف فعال بودن یا غیر فعال بودن این قابلیت است. در شاخه HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\Dnscache\Parameters مقدار DomainNameDevolutionLevel معرف سطوح devolution است که می تواند بین ۱ تا ۵۰ باشد.
















.