به عنوان یک مدیر شبکه یا کسی که با ساختارهای شبکه آشنایی دارد، قطعا تا کنون با مبحثی به نام Zone در ساختار DNS برخورد کرده اید. هر چند که به دلیل اینکه در بسیاری از موارد تنظیمات مربوط به Zone ها در DNS بصورت خودکار توسط فرآیند DCPROMO در اکتیودایرکتوری انجام می شود اما به هر حال بد نیست که در خصوص ماهیت اصلی Zone و چیستی آن صحبت کنیم. در این مقاله قصد داریم شما را با مفاهیم تئوری و مفهومی Zone و انواع آن در سیستم عامل های سرور شرکت مایکروسافت آشنا کنیم. ابتدا به بررسی مفهوم Zone می پردازیم و با این سئوال شروع می کنیم که Zone چیست؟
بد نیست قبل از اینکه به مفهوم فنی Zone بپردازیم واژه Zone را از لحاظ لغوی بررسی کنیم. از لحاظ مفهوم لغوی Zone در فارسی به معنی منطقه، محدوده، قلمرو و بخش می باشد. در ساختار DNS نیز Zone به معنی یک بخش مشخص، یک فضای مدیریت شده، یک فضای اجرایی در داخل ساختار DNS می باشد که منحصر به یک ساختار نامگذاری مشخص شده است. برای اینکه درک بهتری از مفهوم Zone داشته باشید همان مثال همیشگی را در خصوص DNS به خاطر بیاورید، DNS را با یک دفترچه تلفن مقایسه کنید، این دفترچه تلفن دارای ترتیبی است که بر اساس حروف الفبا مرتب شده اند و شماره تلفن ها نیز بر اساس همان ها مرتب شده اند، شما قطعا می دانید که کسی که دارای نام خانوادگی نصیری است در قسمت حروف الفای نون قرار دارد نه در جای دیگر، همین مثال را در خصوص Zone ها نیز بکار می بریم. تمامی زیر مجموعه های نام دامنه ای که با آدرس geekboy.pro هستند در داخل یک Zone به همان اسم نگهداری می شوند، برای مثال آدرس IP یا رکورد مربوط به نام دامنه dl.geekboy.pro قطعا در Zone مربوط به geekboy.pro قرار دارد نه در جای دیگر. فراموش نکنیم که ساختار Zone ها از همان ساختار سلسله مراتبی DNS پیروی می کند. در هر Zone آدرس های IP و یا نام دامنه ها یا نام Host های مورد نظر برای جستجو همانند شماره تلفن های موجود در دفترچه تلفن وجود دارد. که در اینجا به هر یک از این موجودیت ها به اختصار رکورد گفته می شود. بصورت کلی دو نوع Zone به نامهای Reverse Lookup Zone و Forward Lookup Zone وجود دارد که اینها طبقه بندی کلی مجموعه Zone ها می باشد، در Forward Lookup Zone نام دامنه خواسته شده به آدرس IP و در Reverse Lookup Zone آدرس IP مقصد به نام دامنه مرتبط می شوند. فارق از اینکه Zone ما از کدامیک از این دو نوع است، هر یک از این دو نوع Zone کلی به انواع دیگری طبقه بندی می شوند که به شرح زیر می باشد:
- Primary zone
- Secondary zone
- Stub zone
primary zone
وقتی برای اولین بار در DNS یک zone می سازیم باید از نوع primary باشد. این zone، هم نوشتنی و هم خواندنی است. این zone منبع اصلی اطلاعات است و کپی های اصلی از اطلاعات zone را در یک local file یا در ADDS ذخیره می کند، وقتی zone در یک فایل ذخیره می شود، به صورت پیشفرض این فایل zone_name.dns نامیده می شود و در پوشه ی %windir%\System32\Dns ، روی سرور قرار می گیرد. تمامی zone ها باید نام داشته باشند، یعنی بر اساس name.name باشند. برای مثال dl.geekboy.pro یک نام دامنه است.
secondary zone
این zone هم مانند primary zone است با این تفاوت که DNS سرور Backup است و وقتی ما یک DNS سرور primary داریم قطعا وجود نسخه ی پشتیبان برای آن جز ضروریات است، secondary zone فقط (Read only) خواندنی است. هرچیزی که در primary zone ساخته شود در secondary zone هم ساخته خواهد شد که به این فرآیند zone transferring می گویند. secondary zone یک کپی از primary zone است و روی ADDS نمی تواند ذخیره شود و به دلیل اینکه secondary zone ها از نوع استاندارد هستند پایگاه داده آنها در پوشه ی DNS در system32 ذخیره می شود. این zone درخواستها را به primary zone ارجاع می دهد.
Stub zone
این Zone در واقع یک کپی از یک Primary Zone است که صرفا حاوی رکوردهای ضروری برای شناسایی Zone ای است که حاوی کلیه کوردهای Authoritative برای آن Zone است. Stub Zone تا حدود زیادی با Secondary Zone شباهت دارد با این تفاوت که در Secondary Zone کلیه رکوردهایی که در Primary Zone قرار دارد وجود دارد اما در Stub Zone صرفا رکوردهای ضروری برای شناسایی سرورهایی که رکوردهای مورد نظر را در درون خود نگه می دارد. معمولا زمانی از Stub Zone استفاده می کنیم که می خواهیم چندین DNS Namespace متفاوت را برای کاربران خود سرویس دهی کنیم. شما نمی توانید تغییراتی در Stub Zone ایجاد کنید مگر اینکه در Primary Zone ای که از آن گرفته شده است تغییری ایجاد شود.
رکورد هایی که در Stub Zone قرار می گیرند به شرح زیر می باشد:
- رکوردهای SOA یا Start Of Authority Records
- Host name یا A رکوردهای تمام سرورها
- NS یا Name Server رکوردهای تمام Name Server های معتبر در زون ها که Glue record نام دارند
- SRV service و MX و A رکوردهای های مربوط به host ها را ندارد.
پس همانطور که بدیهی است یک Secondary Zone بسیار بزرگتر از یک Stub Zone است. این حجم کوچک Stub Zone ها باعث میشود که ترافیک حاصل از Replication Zone در شبکه بسیار ناچیز باشد، چرا که رکوردهای NS به ندرت تغییر میکنند و در نتیجه نیاز به Replication در آنها زیاد احساس نمیشود. همچنین از آنجا که بیشتر DNS سرورها طوری طراحی میشوند که از ایجاد ترافیک حاصل از Zone Transfer به Secondary Zone جلوگیری شود، تنها SOA , NS و A رکوردها در Stub Zone برای Name Server ها درخواست میشوند. در نهایت یکی از مورادی که باعث برتری Stub Zone ها نسبت به Secondary Zone ها میشود این است که Stub Zone ها می توانند Active Directory Integrated باشند اما Secondary Zone ها نمیتوانند. از این رو به راحتی می توان عمل Replication را بین Stub Zone و دومین کنترلرها انجام داد. توجه کنید که استفاده از Stub Zone در مواقعی که بیش از یک فارست داریم توصیه می شود. از Stub Zone ها به دلیل کاهش ترافیک Zone Transfer بین دو مجموعه ای که به وسیله WAN با یکدیگر ارتباط برقرار کرده اند استفاده میشود.
کاربردهای Stub zone
بروز نگه داشتن اطلاعات Zone ای که Delegate شده است: با بروز شدن اطلاعات stub zone اطلاعات مربوط به child domain ها نیز بروز می شود و همین امر باعث می شود که اطلاعات موجود در parent domain همیشه بروز نگه داشته بشود.
بهبود فرآیند Name Resolution: ساختار stub zone به DNS سرور این امکان را می دهد که بتواند فرآیند Recursion را با استفاده از لیست Name Server هایی که دارد و بدون مراجعه به اینترنت با سرعت بیشتری انجام دهد.
ساده سازی مدیریت DNS: شما با استفاده از ساختار Stub Zone می توانید اطلاعات موجود در خصوص DNS سرور های معتبر را بدون استفاده از ساختار Secondary Zone براحتی منتشر کنید. از جهتی با استفاده از قابلیت Delegation باعث ساده تر شدن فرآیند مدیریت در DNS می شوند.
دو لیست از سرورهای DNS که در مدیریت، نگهداری و بارگذاری stub zone مشارکت دارند وجود دارند:
- لیست ای از سرورهای اصلی (master servers) از آن DNS سروری که stub zone را بارگذاری و آپدیت میکند. که این master server ممکن است primary DNS server یا secondary DNS server برای zone باشد.
- لیستی از DNS serverهای معتبر و شناخته شده برای zone.
در زیر هم یک ویدیو قرار داده ایم که هم توضیح میده که DNS Zone چی هست و هم آموزش ایجاد اون ها رو توضیح میده.
DNS zone (wikipedia)
A DNS zone is any distinct, contiguous portion of the domain name space in the Domain Name System (DNS) for which administrative responsibility has been delegated to a single manager.
The domain name space of the Internet is organized into a hierarchical layout of subdomains below the DNS root domain. The individual domains of this tree may serve as delegation points for administrative authority and management. However, usually it is furthermore desirable to implement fine-grained boundaries of delegation, so that multiple sub-levels of a domain may be managed independently. Therefore, the domain name space is partitioned into areas (zones) for this purpose. A zone starts at a domain and extends downward in the tree to the leaf nodes or to the top-level of subdomains where other zones start.[1]
A DNS zone is implemented in the configuration system of a domain name server. Historically, it is defined in the zone file, an operating system text file that starts with the special DNS record type Start of Authority (SOA) and contains all records for the resources described within the zone. This format was originally used by the Berkeley Internet Name Domain Server (BIND) software package, and is defined in RFC 1034 and RFC 1035
Domains and zones
Most top-level domain name registry operators offer their name spaces to the public or to entities with mandated geographic or otherwise scoped purpose for registration of second-level domains. Similarly an organization in charge of a lower level domain may operate its name space similarly and subdivide its space.
Each registration or allocation of subdomain space obligates the registrant to maintain an administrative and technical infrastructure to manage the responsibility for its zone, including sub-delegation to lower-level domains. Each delegation confers essentially unrestricted technical autonomy over the allocated space. An area of one or more subdomains that has been delegated for management is called a DNS zone. A zone always starts at a domain boundary to include all leaf nodes (hosts) in the domain, or it ends at the boundary of another independently managed zone.
As each domain is further divided into sub-domains, each becoming a DNS zone itself with its own set of administrators and DNS servers, the tree grows with the largest number of leaf nodes at the bottom. At this lowest level, in the end-nodes or leaves of the tree, the term DNS zone becomes essentially synonymous with the term “domain”, both in terms of use and administration. The term domain is used in the business functions of the entity assigned to it and the term zone is usually used for configuration of DNS services.
Internet infrastructure DNS zones
The top-level domain arpa serves as a delegation zone for various technical infrastructure aspects of DNS and the Internet, and does not implement the registration and delegation system of the country and generic domains. The name arpa is a remnant of the ARPANET, one of the predecessor stages of the Internet. Intended as a transitional aid to the DNS system, deleting the domain arpa was later found to be impractical. Consequently, the name was officially redefined as an acronym for Address and Routing Parameter Area. It contains sub-zones used for reverse resolution of IP addresses to host names (IPv4: in-addr.arpa, IPv6: ip6.arpa), telephone number mapping (ENUM, e164.arpa), and uniform resource identifier resolution (uri.arpa, urn.arpa).
Although the administrative structure of this domain and its sub-domains is different, the technical delegation into zones of responsibility is similar and the DNS tools and servers used are identical to any other zone. Sub-zones are delegated by components of the respective resources. For example, 8.8.2.5.5.2.2.0.0.8.1.e164.arpa., which might represent an E.164 telephone number in the ENUM system, might be sub-delegated at suitable boundaries of the name. An example of an IP addresses in the reverse DNS zone is 166.188.77.208.in-addr.arpa, which represents the address 208.77.188.166 and resolves to the domain name www.example.com. In the case of IP addresses, the reverse zones are delegated to the Internet service provider (ISP) to which the IP address block is assigned. When an ISP allocates a range to a customer, it usually also delegates the management of that space to the customer by insertion of name server resource records pointing to the customers DNS facilities into their zone, or provides other management tools. Allocations of single IP addresses for networks connected through network address translation (NAT) typically do not provide such facilities.
Example of zone authority in DNS queries
As an example of the DNS resolving process, consider the role of a recursive DNS resolver attempting to look up the address “en.wikipedia.org.”. It begins with a list of addresses for the most authoritative name servers it knows about – the root zone name servers (indicated by the full stop or period), which contains name server information for all top-level domains of the Internet.
When querying one of the root name servers, it is possible that the root zone will not directly contain a record for “en.wikipedia.org.”, in which case it will provide a referral to the authoritative name servers for the “org.” top level domain (TLD). The resolver is issued a referral to the authoritative name servers for the “org.” zone, which it will contact for more specific information. Again when querying one of the “org.” name servers, the resolver may be issued with another referral to the “wikipedia.org.” zone, whereupon it will again query for “en.wikipedia.org.”. Since (as of July 2010) “en.wikipedia.org.” is a CNAME to “text.wikimedia.org.” (which is in turn a CNAME to “text.esams.wikimedia.org.”), and the “wikipedia.org.” name servers also happen to contain authoritative data for the “wikimedia.org.” zone, the resolution of this particular query occurs entirely within the queried name server, and the resolver will receive the address record it requires with no further referrals.
If the last name server queried did not contain authoritative data for the target of the CNAME, it would have issued the resolver with yet another referral, this time to the zone text.wikimedia.org.. However, since the resolver had previously determined the authoritative name servers for the zone org., it does not need to begin the resolution process from scratch but instead start at zone org., thus avoiding another query to the root name servers.
There is no requirement that resolving should involve any referrals at all. Looking up en.wikipedia.org. on the root name servers always results in referrals, but if an alternative DNS root is used which is set up to contain a record for en.wikipedia.org., then the record is returned on the first query.
ممنون بسیار مفید بود
خواهش میکنم