A / 22 को डेलिगेट करना आसान है, यह 4 / 24s का डेलिगेशन है। A / 14, 4 / 16s, आदि का प्रतिनिधिमंडल है।
RFC2317 विशेष मामलों को / 24 से अधिक नेटमास्क के साथ कवर करता है। मूल रूप से कुछ भी ओकटेट सीमाओं पर inaddr.arpa क्षेत्रों के प्रतिनिधिमंडल को करने के लिए कोई सुपर-क्लीन तरीका नहीं है, लेकिन आप इसके चारों ओर काम कर सकते हैं। मान लें कि मैं 172.16.23.16/29 को सौंपना चाहता हूं, जो आईपी पते 172.16.23.16 -> 172.16.23.23 होगा।
23.16.172.in-addr.arpa ज़ोन के स्वामी के रूप में, मैं अपने ग्राहक को यह रेंज सौंपने के लिए अपने 23.16.172.rev ज़ोन फ़ाइल में डाल सकता हूँ:
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
तो, आप देख सकते हैं कि मैं एक नया क्षेत्र (16-29.23.16.172.in-addr.arpa) परिभाषित कर रहा हूं और इसे अपने ग्राहक के नाम सर्वर को सौंप रहा हूं। फिर मैं नए डेलीगेटेड ज़ोन के तहत संगत संख्याओं को प्रत्यायोजित करने के लिए IP से CNAME बना रहा हूँ।
ग्राहक के रूप में जिन्हें ये सौंपे गए हैं, मैं निम्नलिखित में से कुछ ऐसा करूँगा, जैसे name.conf:
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
और फिर .rev फ़ाइल में, मैं PTR को किसी भी सामान्य-addr.arpa क्षेत्र की तरह बनाऊंगा:
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
यह करने के लिए स्वच्छ तरीके की तरह है और यह प्रेमी ग्राहक को खुश करता है क्योंकि उनके पास PTR डालने के लिए एक in-addr.arpa ज़ोन है, आदि। ग्राहक के लिए यह एक छोटा तरीका है जो रिवर्स DNS को नियंत्रित करना चाहता है लेकिन डॉन ' t एक पूरे क्षेत्र को स्थापित करना चाहते हैं अपने मुख्य क्षेत्र में समान नामों के लिए केवल CNAME व्यक्तिगत रिकॉर्ड है।
इस मामले में, हम, प्रतिनिधि के रूप में, हमारी 23.16.172.rev फ़ाइल में ऐसा कुछ होगा:
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
तो यह अन्य विचार की अवधारणा के समान है, लेकिन एक नया क्षेत्र बनाने और इसे ग्राहक को सौंपने के बजाय, आप ग्राहक के पहले से मौजूद मुख्य क्षेत्र में नामों के रिकॉर्ड को CNAME कर रहे हैं।
ग्राहक अपने customer.com ज़ोन फ़ाइल में कुछ इस तरह होगा:
office IN A 172.16.23.17
17 IN PTR office.customer.com.
www IN A 172.16.23.18
18 IN PTR www.customer.com.
(etc)
यह सिर्फ ग्राहक के प्रकार पर निर्भर करता है। जैसा मैंने कहा, यह सिर्फ ग्राहक के प्रकार पर निर्भर करता है। एक प्रेमी ग्राहक अपने स्वयं के-addr.arpa क्षेत्र को स्थापित करना पसंद करेगा और एक डोमेन-नाम क्षेत्र में PTR को रखना बहुत ही अजीब लगेगा। एक गैर-प्रेमी ग्राहक अतिरिक्त कॉन्फ़िगरेशन के एक टन करने के लिए बिना "बस काम" करना चाहेगा।
अन्य तरीकों की संभावना है, बस उन दोनों का विस्तार कर रहा हूं जिनसे मैं परिचित हूं।
मैं सिर्फ अपने बयान के बारे में सोच रहा था कि कैसे / 22 और / 14 आसान हैं और इस बारे में सोच रहे हैं कि यह सच क्यों है लेकिन 25 और 32 के बीच कुछ भी कठिन है। मैंने इसका परीक्षण नहीं किया है, लेकिन मैं भटकता हूं अगर आप इस तरह से ग्राहक को संपूर्ण / 32 सौंप सकते हैं:
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
फिर, ग्राहक की तरफ, आप पूरे / 32 को पकड़ते हैं:
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
और फिर व्यक्तिगत फ़ाइल में आपके पास कुछ इस तरह होगा:
@ IN PTR office.customer.com.
स्पष्ट नकारात्मक पक्ष यह है कि प्रति फ़ाइल एक / 32 सकल की तरह है। लेकिन मुझे यकीन है कि यह काम करेगा।
मेरे द्वारा उल्लेखित सभी चीजें शुद्ध डीएनएस हैं, अगर किसी भी डीएनएस सर्वर ने आपको ऐसा नहीं करने दिया, क्योंकि यह डीएनएस की पूर्ण कार्यक्षमता को प्रतिबंधित कर रहा है। मेरे उदाहरण स्पष्ट रूप से BIND का उपयोग कर रहे हैं, लेकिन हमने Windows DNS और BIND का उपयोग करके ग्राहक का पक्ष लिया है। मुझे ऐसा कोई कारण नहीं दिख रहा है जो किसी सर्वर के साथ काम न करे।