इस पेज का अनुवाद Cloud Translation API से किया गया है.

EDNS क्लाइंट सबनेट (ECS) दिशानिर्देश

शुरुआती जानकारी

आरएफ़सी 7871 - डीएनएस क्वेरी में क्लाइंट सबनेट – यह आपको Google के सार्वजनिक डीएनएस जैसे बार-बार होने वाले रिज़ॉल्वर जैसे काम करने के तरीके के बारे में बताता है. इससे, आधिकारिक डीएनएस नेम सर्वर को आधिकारिक आईपी पते की जानकारी भेजी जा सकती है. कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) और इंतज़ार के समय की संवेदनशील सेवाओं का इस्तेमाल, सार्वजनिक डीएनएस रिज़ॉल्वर से मिलने वाले नाम वाले लुकअप का जवाब देते समय, जगह के हिसाब से सटीक नतीजे देने के लिए किया जाता है.

आरएफ़सी, ऐसे ईसीएस फ़ीचर के बारे में बताती है जिन्हें आधिकारिक नेम सर्वर को लागू करना चाहिए; लेकिन, लागू करने वाले टूल हमेशा इन ज़रूरी शर्तों को पूरा नहीं करते. ईसीएस की कार्रवाई और डिप्लॉयमेंट से जुड़ी ऐसी समस्याएं भी हैं जो RFC के मुताबिक नहीं हैं. इनकी वजह से, Google की सार्वजनिक डीएनएस सेवा से जुड़े रिज़ॉल्वर, जैसे कि आधिकारिक नाम सर्वर में ईसीएस की सुविधा अपने-आप पहचानने की सुविधा मिलती है. साथ ही, रिज़ॉल्वर को ईसीएस की श्वेतसूची की ज़रूरत होती है, जैसे कि OpenDNS.

इन दिशा-निर्देशों का मकसद, आधिकारिक तौर पर डीएनएस लागू करने वालों और ऑपरेटर की मदद करना है. इनसे ईसीएस में होने वाली कई आम गलतियों से बचा जा सकता है.

अहम जानकारी: आधिकारिक नाम सर्वर और डीएनएस ज़ोन के लिए, ईसीएस डिप्लॉय करते समय, सभी दिशा-निर्देशों का पालन करें. इससे, यह पक्का करने में मदद मिलेगी कि नाम सर्वर को ECS डेटा भेजा जाए, जो क्लाइंट को भौगोलिक तौर पर मौजूद जवाब देता हो, और ECS की सुविधा वाले डीएनएस ज़ोन में दिए गए जवाबों को ठीक कर पाए.

शब्दों की परिभाषाएं

ECS कार्रवाइयों का वर्णन करने के लिए हम इन शब्दों का इस्तेमाल करते हैं:

नाम सर्वर, CS के साथ लागू (या सहायता करने वाला) करता है, अगर यह ECS क्वेरी के साथ जवाब देता है, जिनमें CS विकल्प होते हैं (भले ही, ECS विकल्पों की वैल्यू हमेशा ग्लोबल /0 स्कोप लंबाई के साथ हो).

ध्यान दें: ECS जवाब ज़रूरी है¹ ईसीएस पते से मेल खाता हो परिवार, पता, और स्रोत प्रीफ़िक्स की लंबाई. अगर वे ऐसा नहीं करते, तो नाम सर्वर सही तरीके से ECS लागू नहीं करता है और Google सार्वजनिक डीएनएस, ECS क्वेरी नहीं भेज सकता.
अगर शून्य से बाहर के सोर्स प्रीफ़िक्स के साथ भेजी गई ECS क्वेरी को, शून्य के अलावा किसी दूसरे स्कोप के साथ भेजा जाता है, तो ज़ोन ECS-चालू होता है.

आधिकारिक नेम सर्वर के लिए दिशा-निर्देश

किसी ECS-चालू क्षेत्र के लिए सभी आधिकारिक नाम सर्वर को क्षेत्र के लिए ECS चालू करना होगा.
- भले ही, नाम का सिर्फ़ एक सर्वरईसीएस याईसीएस या चालू करें जोन के लिए तैयार हो. ऐसा न होने पर, यह कैश मेमोरी में सेव किए गए ज़्यादातर डेटा का स्रोत बन जाता है. इसके जवाबों का दुनिया भर में इस्तेमाल किया जाता है, इसलिए (उनका TTL (टीटीएल) खत्म होने तक) एक ही नाम वाली सभी क्वेरी के जवाब के तौर पर इस्तेमाल किए जाते हैं (क्लाइंट सबनेट पर ध्यान दिए बिना). सर्वर से मिले जवाब, जो ईसीएस लागू करते हैं ईसीएस करते हैं और इसका इस्तेमाल सिर्फ़ खास दायरे में आने वाले क्लाइंट की क्वेरी के लिए किया जाता है. इसलिए, ग्लोबल स्कोप के रिस्पॉन्स की तुलना में उनका इस्तेमाल कम होता है.
आधिकारिक नाम सर्वर, जो ECS लागू करते हैं² लागू करते हैं. वे किसी आईपी पते या NS होस्टनेम से आने वाले सभी ज़ोन के लिए, ईसीएस क्वेरी भेज सकते हैं.
- Google सार्वजनिक डीएनएस, नाम सर्वर होस्टनेम या डीएनएस ज़ोन के बजाय, आईपी पते के हिसाब से ईसीएस सहायता की पहचान अपने-आप करता है. ऐसा इसलिए, क्योंकि पतों की संख्या, नाम सर्वर होस्टनेम की संख्या से कम होती है और डीएनएस ज़ोन की संख्या से काफ़ी कम होती है. अगर आधिकारिक नाम सर्वर हमेशाईसीएस क्वेरी (ईसीएस क्वेरी के लिए नहीं) को ईमेल नहीं भेजता है, तो Google सार्वजनिक डीएनएस उसे ईसीएस क्वेरी भेजना बंद कर सकता है.
ECS के लागू करने वाले आधिकारिक नाम सर्वर को ECS रिस्पॉन्स के साथ सभी ECS क्वेरी का जवाब देना चाहिए. इनमें, नेगेटिव और रेफ़रल रिस्पॉन्स भी शामिल हैं.
- ईसीएस सहायता की अपने-आप पहचान करने पर भी यही समस्याएं लागू होती हैं.
- नेगेटिव जवाब (NXDOMAIN और NODATA) चाहिए³ आरएफ़सी 7871 के साथ बेहतर तरीके से कैश और काम करने के लिए, ग्लोबल /0 दायरे का इस्तेमाल करें.
- NXDOMAIN और NODATA (बिना जवाब वाले सेक्शन के साथ NOERROR) के अलावा, ECS क्वेरी (खास तौर से SERVFAILED और REFUSED) के लिए गड़बड़ी के दूसरे रिस्पॉन्स, जैसे कि ग्लोबल /0 दायरे वाले मिलते-जुलते ECS विकल्प शामिल होने चाहिए.
  - अगर कोई आधिकारिक नाम सर्वर DoS हमले से लोड होने से रोकने की कोशिश कर रहा है, तो वह ECS डेटा के बिना SERVFAILED गड़बड़ी दिखा सकता है; ऐसा करने से Google सार्वजनिक डीएनएस, ईसीएस के साथ क्वेरी भेजना बंद कर देगा (इससे भेजें जाने वाले सही क्वेरी की संख्या कम हो सकती है, लेकिन बिना किसी क्रम के सबडोमेन हमले की क्वेरी पर असर नहीं पड़ेगा). सेवा की शर्तों को लागू करने के दौरान, क्वेरी का मान्य लोड कम करने से, सही क्वेरी के कामयाब होने की दर बेहतर हो सकती है या नहीं (हालांकि, सभी क्लाइंट के लिए कैश मेमोरी से जवाब दिए जा सकते हैं).
    
    लोड-शेडिंग का एक ज़्यादा असरदार तरीका यह है कि ग्लोबल /0 दायरे वाले सभी जवाब भेजे जाएं, ताकि Google का सार्वजनिक डीएनएस ईसीएस क्वेरी भेजना जारी रख सके. इससे हमला होने के बाद Google सार्वजनिक डीएनएस को भौगोलिक स्थिति वाले जवाब बहुत ज़्यादा दिखने मिलते हैं. जैसे-जैसे ग्लोबल स्कोप रिस्पॉन्स TTL (टीटीएल) की समयसीमा खत्म होने पर, इसे फिर से क्वेरी करना पड़ता है, इसलिए इसे ईसीएस सहायता का फिर से पता लगाने की ज़रूरत नहीं होती.
- रेफ़रल (डेलिगेशन) रिस्पॉन्स में, ईसीएस डेटा और होना⁴ ग्लोबल /0 दायरे का इस्तेमाल करना चाहिए. ध्यान दें कि डेलिगेशन रिस्पॉन्स उन क्लाइंट को कभी फ़ॉरवर्ड नहीं किए जाते जिनके पते ECS डेटा में दिखते हैं. इसलिए, solver's के क्लाइंट आईपी पते की मदद से किसी देश या इलाके के NS, A या AAAA रिकॉर्ड को चुने जाने चाहिए, न कि ECS डेटा को.
ECS के लागू करने वाले आधिकारिक नाम सर्वर में, ECS विकल्प के साथ मिले सभी क्वेरी टाइप के रिस्पॉन्स में, मेल खाने वाला ECS विकल्प शामिल होना चाहिए. ECS डेटा के साथ IPv4 पते (A) क्वेरी का जवाब देने के लिए यह काफ़ी नहीं है. A, AAAA, PTR, MX या किसी दूसरी तरह की क्वेरी के जवाबों में, मैच करने वाले ECS डेटा या रिज़ॉल्वर ज़रूरी जवाब के तौर पर जवाब छोड़ सकते हैं. और Google सार्वजनिक डीएनएस, ECS डेटा के साथ क्वेरी भेजना बंद कर सकता है.

खास तौर पर, एसओए, एनएस, और डीएस क्वेरी के लिए ईसीएस के जवाबों को हमेशा ग्लोबल /0 दायरे का इस्तेमाल करना चाहिए, ताकि डेटा को कैश मेमोरी में सेव किया जा सके और उन पर डेलिगेशन की सुविधा एक जैसा दिखे (नाम सर्वर के होस्टनेम के लिए, A/AAAA क्वेरी के लिए जगह की जानकारी से जुड़े जवाब ठीक होते हैं). ECS डेटा के आधार पर नहीं बदलने वाले, किसी भी तरह की क्वेरी (उदाहरण के लिए, TXT, PTR वगैरह) को जवाब में, सोर्स प्रीफ़िक्स की लंबाई के बराबर स्कोप का इस्तेमाल नहीं करना चाहिए. क्वेरी को बेहतर तरीके से कैश करने और क्वेरी लोड करने के लिए, ग्लोबल /0 दायरे का इस्तेमाल करना चाहिए.
ECS-चालू CNAME जवाब देने वाले आधिकारिक नाम सर्वर हो सकता है⁵, चेन का सिर्फ़ पहला CNAME शामिल करता है. साथ ही, CNAME चेन का आखिरी टारगेट ECS-चालू होना चाहिए, जिसकी शुरुआत में प्रीफ़िक्स एक ही हो. ECS के स्पेसिफ़िकेशन में अंतर होने की वजह से, बार-बार होने वाले कुछ रिज़ॉल्वर (खास तौर पर अनबाउंड⁶) रिस्पॉन्स के तौर पर, ऐसे डोमेन का जवाब दे सकते हैं जो CCS नहीं है.
ECS डेटा में IPv6 पते शामिल हो सकते हैं यहां तक कि IPv4-ओनली नाम सर्वर के लिए भी (इसके उलट, हालांकि IPv6 सिर्फ़ नाम सर्वर का इस्तेमाल नहीं किया जा सकता).

अहम जानकारी: IPv6 ECS दायरे की मान्य वैल्यू न दिखाना, इसकी सबसे आम वजह है आधिकारिक नाम सर्वर को Google की सार्वजनिक डीएनएस सेवा से ECS डेटा नहीं मिलता है.
- नाम सर्वरों को मान्य ECS विकल्प डेटा के साथ जवाब देना चाहिए (/0 दायरा ठीक है, लेकिन स्रोत पता और उपसर्ग लंबाई को मेल खाना चाहिए).
- किसी ज़ोन के लिए ECS, IPv4 और IPv6 पते के लिए अलग से चालू किए जा सकते हैं.
ECS की सुविधा वाले जवाब देने वाले आधिकारिक नाम सर्वर ज़रूरी नहीं⁷ अपने जवाबों के स्कोप ओवरलैप प्रीफ़िक्स से मेल खाते हों. ओवरलैप होने वाले स्कोप प्रीफ़िक्स का उदाहरण यह है:
- सोर्स प्रीफ़िक्स 198.18.0.0/15 वाली क्वेरी: जवाब के स्कोप प्रीफ़िक्स 198.0.0.0/8 के साथ
- सोर्स प्रीफ़िक्स 198.51.100/24 वाली क्वेरी: दायरे वाले प्रीफ़िक्स 198.51.0.0/16 के साथ रिस्पॉन्स B
अगर कोई क्लाइंट ऊपर दिए गए क्रम में, ECS की सुविधा वाले बार-बार होने वाले रिज़ॉल्वर की क्वेरी करता है, तो दोनों क्वेरी के जवाब में A मिल सकता है. क्योंकि कैश मेमोरी में सेव किए गए रिस्पॉन्स A के दायरे में दूसरी क्वेरी का प्रीफ़िक्स दायरा भी शामिल होता है. भले ही क्लाइंट क्वेरी, उलटे क्रम में बनाई गई हों, और दोनों क्वेरी को आधिकारिक नाम सर्वर पर फ़ॉरवर्ड किया जाता हो, कैश मेमोरी में सेव किए गए जवाब, अलग-अलग समय पर खत्म हो सकते हैं; ओवरलैप होने वाले प्रीफ़िक्स में बाद वाले रिकवरी वाले रिज़ॉल्वर 198.51.100/24 को या तो जवाब A या B मिल सकता है.
नाम सर्वर पर पहली बार ECS सहायता लागू करते समय, इन ECS चालू ज़ोन को नाम देने वाले नाम सर्वर के लिए, नए आईपी पते का इस्तेमाल करें.
- जब आधिकारिक नाम सर्वर ने ECS की सुविधा लागू की लेकिन ग्लोबल स्कोप के नतीजे दिखाने की सुविधा शुरू की, तो किसी ज़ोन के लिए CS के चालू जवाब दिखने लगे. Google सार्वजनिक डीएनएस, क्वेरी के लिए भौगोलिक जगह पर मिलने वाले जवाबों को जल्द ही फिर से शामिल करना शुरू कर देगा. जैसे, पिछले ग्लोबल स्कोप के जवाबों की TTL (टीटीएल) भी खत्म हो जाएगी.
- ईसीएस सहायता के लिए Google सार्वजनिक डीएनएस की अपने-आप पहचान करने की सुविधा, शायद ही कभी आईपी पते (या नाम सर्वर होस्टनेम) के लिए ईसीएस क्वेरी की कोशिश करती है. हालांकि, ऐसा तब ही होता है, जब उसे ईसीएस सहायता की कमी का पता चला हो (समय खत्म होने पर, FORMERR, BACKVERS पर वापस आना या गैर-ECS रिस्पॉन्स भेजना). उन आईपी पतों (या NS होस्टनेम) पर नए ईसीएस लागू करने का पता अपने-आप बहुत धीरे लगाया जाता है या बिल्कुल भी नहीं दिखता.
पक्का करें कि नेटवर्क कनेक्शन भरोसेमंद हों और जवाब देने की कोई भी सीमा इतनी ज़्यादा हो कि नाम सर्वर क्वेरी को न छोड़ें (या इससे भी खराब, उन गड़बड़ियों के साथ जिनका मिलान करने के लिए ईसीएस का विकल्प न हो).
- ECS क्वेरी के लिए रिस्पॉन्स रेट की सीमा को लागू करने वाले नाम सर्वर के लिए, कटौस (TC) फ़्लैग सेट वाला सबसे अच्छा जवाब NODATA होता है. इसमें सिर्फ़ मिलते-जुलते सवाल वाला सेक्शन और मेल खाने वाला ECS विकल्प शामिल होता है.
सभी क्वेरी के लिए समय पर जवाब दें (बेहतर तरीके से 1 सेकंड के अंदर).
- ईसीएस क्वेरी के लिए जियो-आईपी ऑनलाइन सेवाओं का इस्तेमाल भरोसेमंद तरीके से नहीं किया जा सकता. इसलिए, डीएनएस क्वेरी और ऑनलाइन जियो-आईपी सेवा के कुल इंतज़ार का समय एक सेकंड के अंदर होना चाहिए. Google की सार्वजनिक डीएनएस सेवा के लिए, ईसीएस की मदद से अपने-आप पहचान करने की सुविधा को देरी से काम करने वाला रिस्पॉन्स माना जाता है. यह पाया जाता है कि ईसीएस की सुविधा खराब है या अधूरी है. साथ ही, आने वाले समय में ईसीएस के ज़रिए क्वेरी भेजे जाने की संभावना कम हो जाती है. अगर ज़्यादा जवाब मिलने में देरी होती है, तो यह ECS क्वेरी भेजना बंद कर देता है.

RFC 7871 रेफ़रंस और दूसरी फ़ुटनोट

¹ https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

² https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

³ https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

⁴ https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

⁵ https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

⁶ https://unbound.net/pipermail/unBOUND-users/2015-May/003875.html

CNAME चेन में फ़ाइनल डोमेन के दायरे का इस्तेमाल अनबाउंड में नुकसान पहुंचाने वाला नहीं होता है, क्योंकि इसे आम तौर पर स्थानीय स्टब या फ़ॉरवर्डिंग रिज़ॉल्वर के रूप में डिप्लॉय किया जाता है, जहां सभी क्लाइंट एक ही सबनेट में होते हैं और उन्हें एक जैसा रिस्पॉन्स मिलता है.

⁷ https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

Deaggregate the shorter prefix response into multiple longer prefix responses, or

Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.