EDNS ক্লায়েন্ট সাবনেট (ECS) নির্দেশিকা

ভূমিকা

RFC 7871 - DNS ক্যোয়ারিতে ক্লায়েন্ট সাবনেট - Google পাবলিক DNS-এর মতো পুনরাবৃত্ত সমাধানকারীদের জন্য একটি পদ্ধতি সংজ্ঞায়িত করে যাতে আংশিক ক্লায়েন্ট আইপি ঠিকানা তথ্য প্রামাণিক DNS নাম সার্ভারে পাঠানো হয়। কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) এবং লেটেন্সি-সংবেদনশীল পরিষেবাগুলি সর্বজনীন DNS সমাধানকারীদের মাধ্যমে আসা নামের সন্ধানের প্রতিক্রিয়া দেওয়ার সময় সঠিক ভূ-অবস্থিত প্রতিক্রিয়া দিতে এটি ব্যবহার করে।

RFC ECS বৈশিষ্ট্যগুলি বর্ণনা করে যা প্রামাণিক নাম সার্ভারগুলিকে অবশ্যই প্রয়োগ করতে হবে; কিন্তু বাস্তবায়নকারীরা সবসময় সেই প্রয়োজনীয়তাগুলি অনুসরণ করে না। এছাড়াও ইসিএস অপারেশনাল এবং স্থাপনার সমস্যা রয়েছে যা RFC সমাধান করে না যা Google পাবলিক ডিএনএসের মতো সমাধানকারীদের জন্য সমস্যা সৃষ্টি করতে পারে যেগুলি প্রামাণিক নাম সার্ভারগুলিতে ইসিএস সমর্থন স্বয়ংক্রিয়ভাবে সনাক্ত করে, সেইসাথে OpenDNS এর মতো ECS হোয়াইটলিস্টিং প্রয়োজন এমন সমাধানকারীদের জন্য।

এই নির্দেশিকাগুলি প্রামাণিক DNS বাস্তবায়নকারী এবং অপারেটরদের অনেক সাধারণ ভুল এড়াতে সাহায্য করার উদ্দেশ্যে করা হয়েছে যা ECS-এর জন্য সমস্যা সৃষ্টি করতে পারে।

শর্তাবলীর সংজ্ঞা

আমরা ECS ক্রিয়াকলাপগুলি বর্ণনা করতে নিম্নলিখিত পদগুলি ব্যবহার করি:

  • একটি নেম সার্ভার ইসিএস প্রয়োগ করে (বা সমর্থন করে ) যদি এটি ইসিএস প্রশ্নের উত্তর দেয় ইসিএস প্রতিক্রিয়াগুলির সাথে যা ইসিএস বিকল্পগুলির সাথে মিলে যায় (এমনকি যদি ইসিএস বিকল্পগুলির সর্বদা একটি গ্লোবাল /0 স্কোপ প্রিফিক্স দৈর্ঘ্য থাকে)।

  • একটি জোন ইসিএস- সক্ষম হয় যদি একটি অ-শূন্য উৎস উপসর্গ সহ পাঠানো তার নাম সার্ভারগুলিতে ইসিএস প্রশ্নগুলি একটি অ-শূন্য সুযোগ সহ ইসিএস প্রতিক্রিয়া পায়।

প্রামাণিক নাম সার্ভারের জন্য নির্দেশিকা

  1. একটি ECS-সক্ষম জোনের জন্য সমস্ত প্রামাণিক নাম সার্ভার অবশ্যই জোনের জন্য ECS সক্রিয় করতে হবে।

    • এমনকি যদি শুধুমাত্র একটি নাম সার্ভার ইসিএস প্রয়োগ না করে বা জোনের জন্য এটি সক্ষম না করে, তবে এটি দ্রুত বেশিরভাগ ক্যাশে করা ডেটার উত্স হয়ে যায়। কারণ এর প্রতিক্রিয়াগুলির বিশ্বব্যাপী সুযোগ রয়েছে (তাদের TTL মেয়াদ শেষ না হওয়া পর্যন্ত) একই নামের জন্য (ক্লায়েন্ট সাবনেট নির্বিশেষে) সমস্ত প্রশ্নের প্রতিক্রিয়া হিসাবে ব্যবহার করা হয়। যে সার্ভারগুলি ECS প্রয়োগ করে এবং এটি সক্ষম করে সেগুলি থেকে প্রতিক্রিয়াগুলি শুধুমাত্র নির্দিষ্ট সুযোগের মধ্যে থাকা ক্লায়েন্টদের প্রশ্নের জন্য ব্যবহৃত হয়, তাই বিশ্বব্যাপী সুযোগ প্রতিক্রিয়াগুলির তুলনায় সেগুলি ব্যবহার করার সম্ভাবনা অনেক কম৷

  2. প্রামাণিক নাম সার্ভারগুলি যেগুলি ECS প্রয়োগ করে তাদের অবশ্যই 2 একটি IP ঠিকানা বা NS হোস্টনাম থেকে পরিবেশিত সমস্ত অঞ্চলের জন্য ECS প্রশ্নের ECS প্রতিক্রিয়া পাঠাতে হবে, এমনকি যে অঞ্চলগুলি ECS- সক্ষম নয় তাদের জন্যও৷

    • নাম সার্ভার হোস্টনাম বা DNS জোনের পরিবর্তে Google পাবলিক DNS IP ঠিকানা দ্বারা স্বয়ংক্রিয়ভাবে ECS সমর্থন সনাক্ত করে কারণ ঠিকানার সংখ্যা নাম সার্ভার হোস্টনামের সংখ্যার চেয়ে ছোট এবং DNS জোনের সংখ্যার চেয়ে অনেক ছোট। যদি একটি প্রামাণিক নাম সার্ভার সর্বদা ECS প্রশ্নগুলিতে ECS প্রতিক্রিয়া না পাঠায় (এমনকি যে অঞ্চলগুলি ECS-সক্ষম নয় তাদের জন্য), Google পাবলিক DNS এটিকে ECS প্রশ্নগুলি পাঠানো বন্ধ করতে পারে।

  3. ইসিএস বাস্তবায়নকারী প্রামাণিক নাম সার্ভারগুলি অবশ্যই নেতিবাচক এবং রেফারেল প্রতিক্রিয়া সহ ECS প্রতিক্রিয়া সহ সমস্ত ECS প্রশ্নের উত্তর দিতে হবে।

    • ইসিএস সমর্থনের স্বয়ং-শনাক্তকরণ সম্পর্কে একই সমস্যা এখানেও প্রযোজ্য।

    • নেতিবাচক প্রতিক্রিয়া (NXDOMAIN এবং NODATA) RFC 7871-এর সাথে আরও ভাল ক্যাশিং এবং সামঞ্জস্যের জন্য 3 গ্লোবাল /0 সুযোগ ব্যবহার করা উচিত।

    • NXDOMAIN এবং NODATA (খালি উত্তর বিভাগ সহ NOERROR) ছাড়াও, ECS প্রশ্নের অন্যান্য ত্রুটির প্রতিক্রিয়াগুলিতে (বিশেষত SERVFAIL এবং REFUSED) গ্লোবাল /0 স্কোপের সাথে একটি মিলে যাওয়া ECS বিকল্প অন্তর্ভুক্ত করা উচিত।

      • যদি একটি প্রামাণিক নাম সার্ভার একটি DoS আক্রমণ থেকে লোড কমানোর চেষ্টা করে, তাহলে এটি ECS ডেটা ছাড়াই একটি SERVFAIL ফেরত দিতে পারে; এটি বারবার করার ফলে Google পাবলিক ডিএনএস ইসিএস-এর সাথে প্রশ্ন পাঠানো বন্ধ করে দেয় (যা তাদের পাঠানো বৈধ প্রশ্নের সংখ্যা কমাতে পারে, কিন্তু র্যান্ডম সাবডোমেন আক্রমণের প্রশ্নগুলিকে প্রভাবিত করবে না)। একটি DoS আক্রমণের সময় বৈধ ক্যোয়ারী লোড হ্রাস করা বৈধ প্রশ্নের জন্য সাফল্যের হারকে উন্নত করতে পারে বা নাও করতে পারে (যদিও সমস্ত ক্লায়েন্টের জন্য ক্যাশে থেকে প্রতিক্রিয়া দেওয়া যেতে পারে)।

        একটি আরও কার্যকর লোডশেডিং পদ্ধতি হল গ্লোবাল /0 স্কোপ সহ সমস্ত প্রতিক্রিয়া পাঠানো যাতে Google পাবলিক DNS ইসিএস প্রশ্নগুলি পাঠাতে থাকে। এটি Google পাবলিক ডিএনএসকে আক্রমণ বন্ধ হওয়ার পরে খুব তাড়াতাড়ি জিও-অবস্থিত প্রতিক্রিয়াগুলি ফিরিয়ে দিতে দেয়, কারণ এটিকে ইসিএস সমর্থন পুনরায় সনাক্ত করার প্রয়োজন নেই, কেবলমাত্র বিশ্বব্যাপী স্কোপ প্রতিক্রিয়া TTLগুলির মেয়াদ শেষ হয়ে গেলে পুনরায় অনুসন্ধান করার জন্য।

    • রেফারেল (প্রতিনিধি) প্রতিক্রিয়াগুলিতে অবশ্যই ECS ডেটার সাথে মিল থাকতে হবে এবং 4 টি একটি বিশ্বব্যাপী /0 সুযোগ ব্যবহার করা উচিত। মনে রাখবেন যে প্রতিনিধিদের প্রতিক্রিয়াগুলি কখনই সেই ক্লায়েন্টদের কাছে ফরোয়ার্ড করা হয় না যাদের ঠিকানাগুলি ECS ডেটাতে উপস্থিত হয়, তাই যে কোনও ভূ-অবস্থিত NS, A, বা AAAA রেকর্ডগুলি সমাধানকারীর ক্লায়েন্ট আইপি ঠিকানা দ্বারা নির্বাচন করা উচিত, ECS ডেটা নয়।

  4. ইসিএস বাস্তবায়নকারী প্রামাণিক নাম সার্ভারগুলিকে অবশ্যই একটি ECS বিকল্পের সাথে প্রাপ্ত সমস্ত ক্যোয়ারী প্রকারের প্রতিক্রিয়াগুলিতে একটি মিলে যাওয়া ECS বিকল্প অন্তর্ভুক্ত করতে হবে। ইসিএস ডেটা সহ IPv4 ঠিকানা (A) প্রশ্নের উত্তর দেওয়া যথেষ্ট ভাল নয়; A, AAAA, PTR, MX, বা অন্য যেকোন প্রশ্নের উত্তরে অবশ্যই ECS ডেটার সাথে মিল থাকতে হবে বা সমাধানকারীরা সম্ভাব্য জাল প্রতিক্রিয়া হিসাবে প্রতিক্রিয়া বাদ দিতে পারে এবং Google পাবলিক DNS ECS ডেটা সহ প্রশ্ন পাঠানো বন্ধ করতে পারে।

    বিশেষ করে, SOA, NS, এবং DS প্রশ্নের ECS প্রতিক্রিয়াগুলি সর্বদা আরও ভাল ক্যাশিং এবং প্রতিনিধিদের একটি সামঞ্জস্যপূর্ণ দৃষ্টিভঙ্গির জন্য বিশ্বব্যাপী /0 সুযোগ ব্যবহার করা উচিত (নাম সার্ভার হোস্টনামের জন্য A/AAAA প্রশ্নের ভূ-অবস্থিত প্রতিক্রিয়া ঠিক আছে)। ECS ডেটার উপর ভিত্তি করে পরিবর্তিত না হওয়া যেকোন ক্যোয়ারী টাইপের (যেমন TXT, PTR, ইত্যাদি) উত্তরগুলি সোর্স প্রিফিক্স দৈর্ঘ্যের সমান স্কোপ ব্যবহার করা উচিত নয়, তাদের আরও ভাল ক্যাশিং এবং কম ক্যোয়ারী লোডের জন্য একটি গ্লোবাল /0 স্কোপ ব্যবহার করা উচিত।

  5. ইসিএস-সক্ষম CNAME প্রতিক্রিয়াগুলি ফেরত দেওয়া প্রামাণিক নাম সার্ভারগুলিতে 5 শুধুমাত্র চেইনের প্রথম CNAME অন্তর্ভুক্ত করা উচিত এবং CNAME চেইনের চূড়ান্ত লক্ষ্যটি একই সুযোগ উপসর্গের দৈর্ঘ্যে ECS-সক্ষম হওয়া উচিত। ECS স্পেসিফিকেশনে অস্পষ্টতার কারণে, কিছু পুনরাবৃত্ত সমাধানকারী (উল্লেখ্যভাবে আনবাউন্ড 6 ) চূড়ান্ত নন-CNAME ডোমেনের সুযোগের সাথে একটি প্রতিক্রিয়া ফেরত দিতে পারে (/0 যদি এটি ECS-সক্ষম না হয়)।

  6. ECS ডেটাতে IPv6 ঠিকানা থাকতে পারে এমনকি IPv4-শুধুমাত্র নাম সার্ভারের জন্য (এবং এর বিপরীতে, যদিও IPv6-শুধুমাত্র নাম সার্ভার বিরল)।

    • নেম সার্ভারগুলিকে বৈধ ইসিএস বিকল্প ডেটা সহ প্রতিক্রিয়া জানাতে হবে (/0 সুযোগ ঠিক আছে, তবে উত্স ঠিকানা এবং উপসর্গের দৈর্ঘ্য অবশ্যই মিলবে)।

    • একটি জোনের জন্য ECS আলাদাভাবে IPv4 এবং IPv6 ঠিকানার জন্য সক্রিয় করা যেতে পারে।

  7. ইসিএস-সক্ষম প্রতিক্রিয়া প্রদানকারী প্রামাণিক নাম সার্ভারগুলি অবশ্যই তাদের উত্তরগুলিতে 7টি ওভারল্যাপ স্কোপ প্রিফিক্স নয় ৷ ওভারল্যাপিং স্কোপ উপসর্গগুলির একটি উদাহরণ নিম্নলিখিত হবে:

    • উৎস উপসর্গ 198.0.0.0/8 198.18.0.0/15 উত্তর A

    • উৎস উপসর্গ 198.51.100/24 ​​সহ প্রশ্ন : স্কোপ প্রিফিক্স 198.51.0.0/16 সহ উত্তর B

    যদি একজন ক্লায়েন্ট উপরের ক্রমানুসারে একটি ECS-সক্ষম রিকার্সিভ সমাধানকারীকে জিজ্ঞাসা করে, তাহলে উভয় প্রশ্নই প্রতিক্রিয়া A পেতে পারে, কারণ ক্যাশে করা প্রতিক্রিয়া A-এর স্কোপ দ্বিতীয় কোয়েরির উপসর্গের সুযোগ অন্তর্ভুক্ত করে। এমনকি যদি ক্লায়েন্টের প্রশ্নগুলি বিপরীত ক্রমে করা হয়, এবং উভয় প্রশ্নই প্রামাণিক নাম সার্ভারে ফরোয়ার্ড করা হয়, ক্যাশে করা প্রতিক্রিয়া বিভিন্ন সময়ে মেয়াদ শেষ হতে পারে; ওভারল্যাপিং প্রিফিক্স 198.51.100/24 -এ পুনরাবৃত্ত সমাধানকারীর পরবর্তী প্রশ্নগুলি A বা B হয় প্রতিক্রিয়া পেতে পারে।

  8. নাম সার্ভারে প্রথমবার ECS সমর্থন প্রয়োগ করার সময়, এই ECS সক্ষম অঞ্চলগুলি পরিবেশনকারী নাম সার্ভারগুলির জন্য নতুন IP ঠিকানা ব্যবহার করুন৷

    • যখন প্রামাণিক নাম সার্ভারগুলি যেগুলি ECS প্রয়োগ করেছিল কিন্তু বিশ্বব্যাপী স্কোপের ফলাফলগুলি ফেরত দেয় তারা একটি জোনের জন্য ECS সক্ষম উত্তরগুলি ফেরত দিতে শুরু করে, তখন Google পাবলিক ডিএনএস পূর্ববর্তী বিশ্বব্যাপী স্কোপ প্রতিক্রিয়াগুলির TTLগুলির মেয়াদ শেষ হওয়ার সাথে সাথে প্রশ্নের ভূ-অবস্থানযুক্ত প্রতিক্রিয়াগুলি ফেরত দেওয়া শুরু করে৷

    • ইসিএস সমর্থনের Google পাবলিক ডিএনএস স্বয়ং-শনাক্তকরণ খুব কমই একটি আইপি ঠিকানা (বা নাম সার্ভার হোস্টনাম) এর জন্য ইসিএস কোয়েরির চেষ্টা করে যখন এতে ইসিএস সমর্থনের স্বয়ংক্রিয়ভাবে শনাক্ত করা হয় না (টাইমআউট, FORMERR, ব্যাডভারস ফেরত দেওয়া, বা নন-ইসিএস প্রতিক্রিয়া পাঠানো)। সেই আইপি ঠিকানাগুলিতে (বা এনএস হোস্টনাম) নতুন ইসিএস বাস্তবায়নগুলি খুব ধীরে ধীরে স্বয়ংক্রিয়ভাবে সনাক্ত করা হয়, বা একেবারেই নয়।

  9. নিশ্চিত করুন যে নেটওয়ার্ক সংযোগগুলি নির্ভরযোগ্য এবং যে কোনও প্রতিক্রিয়া হার সীমিত করার পর্যাপ্ত পরিমাণে সেট করা হয়েছে যাতে নাম সার্ভারগুলি কোয়েরি ড্রপ না করে (অথবা আরও খারাপ, একটি ম্যাচিং ইসিএস বিকল্পের অভাবের ত্রুটির সাথে প্রতিক্রিয়া জানায়)৷

    • ইসিএস কোয়েরির উপর সীমিত প্রতিক্রিয়ার হার প্রয়োগকারী নাম সার্ভারগুলির জন্য, সর্বোত্তম প্রতিক্রিয়া হল ট্রাঙ্কেশন (TC) পতাকা সেট সহ NODATA, শুধুমাত্র একটি মিলে যাওয়া প্রশ্ন বিভাগ এবং একটি মিলে যাওয়া ECS বিকল্প রয়েছে।

  10. সব প্রশ্নের সময়মত উত্তর পাঠান (আদর্শভাবে 1 সেকেন্ডের মধ্যে)।

    • ECS কোয়েরির জন্য অনলাইন জিও-আইপি লুকআপ পরিষেবাগুলি ব্যবহার করা নির্ভরযোগ্যভাবে কাজ করবে না, কারণ DNS ক্যোয়ারী এবং অনলাইন জিও-আইপি পরিষেবার ক্রমবর্ধমান বিলম্ব এক সেকেন্ডের মধ্যে হওয়ার সম্ভাবনা কম। ইসিএস সমর্থনের Google পাবলিক ডিএনএস স্বয়ং-শনাক্তকরণ বিলম্বিত প্রতিক্রিয়াগুলিকে দুর্বল বা অসম্পূর্ণ ইসিএস সমর্থনের একটি ইঙ্গিত হিসাবে বিবেচনা করে এবং ভবিষ্যতের প্রশ্নগুলি ইসিএসের সাথে পাঠানোর সম্ভাবনা হ্রাস করে। যদি যথেষ্ট প্রতিক্রিয়া দেরি হয়, এটি ECS প্রশ্ন পাঠানো বন্ধ করে দেয়।

RFC 7871 রেফারেন্স এবং অন্যান্য পাদটীকা

1 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.

2 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.

3 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.

4 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.

5 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.

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

একটি CNAME চেইনে চূড়ান্ত ডোমেনের সুযোগ ব্যবহার করা আনবাউন্ডে ক্ষতিকারক নয়, যেহেতু এটি সাধারণত স্থানীয় স্টাব বা ফরওয়ার্ডিং সমাধানকারী হিসাবে স্থাপন করা হয়, যেখানে সমস্ত ক্লায়েন্ট একই সাবনেটে থাকে এবং একই প্রতিক্রিয়া পাবে।

7 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:

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

  2. 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.