নিরাপত্তা সুবিধা

ভূমিকা: DNS নিরাপত্তা হুমকি এবং প্রশমন

ডোমেন নেম সিস্টেমের উন্মুক্ত, বিতরণকৃত নকশা এবং ব্যবহারকারী ডেটাগ্রাম প্রোটোকল (UDP) এর ব্যবহারের কারণে, DNS বিভিন্ন ধরণের আক্রমণের জন্য ঝুঁকিপূর্ণ। পাবলিক বা "ওপেন" রিকারসিভ ডিএনএস রিসোলভারগুলি বিশেষত ঝুঁকির মধ্যে রয়েছে, কারণ তারা ইনকামিং প্যাকেটগুলিকে অনুমোদিত উৎস আইপি ঠিকানাগুলির একটি সেটে সীমাবদ্ধ করে না। আমরা সাধারণত দুটি সাধারণ ধরনের আক্রমণ নিয়ে উদ্বিগ্ন:

• স্পুফিং আক্রমণ DNS ক্যাশে বিষক্রিয়ার দিকে পরিচালিত করে। বিভিন্ন ধরনের DNS স্পুফিং এবং জালিয়াতি শোষণ প্রচুর, যার লক্ষ্য ব্যবহারকারীদের বৈধ সাইট থেকে দূষিত ওয়েবসাইটগুলিতে পুনঃনির্দেশ করা। এর মধ্যে রয়েছে তথাকথিত কামিনস্কি আক্রমণ , যেখানে আক্রমণকারীরা একটি সম্পূর্ণ ডিএনএস জোনের কর্তৃত্বপূর্ণ নিয়ন্ত্রণ নেয়।
• ডিনায়াল-অফ-সার্ভিস (DoS) আক্রমণ। আক্রমণকারীরা নিজেরাই সমাধানকারীদের বিরুদ্ধে DDoS আক্রমণ চালাতে পারে, বা অন্য সিস্টেমে DoS আক্রমণ শুরু করার জন্য সমাধানকারীদের হাইজ্যাক করতে পারে। বড় ডিএনএস রেকর্ড/প্রতিক্রিয়ার আকারকে কাজে লাগিয়ে অন্যান্য সিস্টেমে DoS আক্রমণ শুরু করতে DNS সার্ভার ব্যবহার করে আক্রমণগুলিকে পরিবর্ধন আক্রমণ বলা হয়।

আক্রমণের প্রতিটি শ্রেণীর নীচে আরও আলোচনা করা হয়েছে।

ক্যাশে বিষের আক্রমণ

ডিএনএস স্পুফিং আক্রমণের বিভিন্ন রূপ রয়েছে যার ফলে ক্যাশে বিষক্রিয়া হতে পারে, তবে সাধারণ পরিস্থিতি নিম্নরূপ:

1. আক্রমণকারী একটি ডোমেন নামের জন্য একটি লক্ষ্য DNS সমাধানকারী একাধিক প্রশ্ন পাঠায় যার জন্য তারা জানে যে সার্ভারটি প্রামাণিক নয় এবং এটি সার্ভারের ক্যাশে থাকার সম্ভাবনা কম।
2. সমাধানকারী অন্যান্য নাম সার্ভারে অনুরোধ পাঠায় (যার আইপি ঠিকানা আক্রমণকারীও ভবিষ্যদ্বাণী করতে পারে)।
3. ইতিমধ্যে, আক্রমণকারী ভুক্তভোগী সার্ভারকে নকল প্রতিক্রিয়া দিয়ে প্লাবিত করে যা প্রতিনিধি নাম সার্ভার থেকে উদ্ভূত বলে মনে হয়। প্রতিক্রিয়াগুলিতে এমন রেকর্ড রয়েছে যা শেষ পর্যন্ত আক্রমণকারী দ্বারা নিয়ন্ত্রিত আইপি ঠিকানাগুলিতে অনুরোধ করা ডোমেনকে সমাধান করে। তারা সমাধান করা নামের জন্য উত্তর রেকর্ড ধারণ করতে পারে বা, আরও খারাপ, তারা আক্রমণকারীর মালিকানাধীন একটি নাম সার্ভারে কর্তৃত্ব অর্পণ করতে পারে, যাতে তারা একটি পুরো অঞ্চলের নিয়ন্ত্রণ নিতে পারে।
4. যদি জাল প্রতিক্রিয়াগুলির একটি সমাধানকারীর অনুরোধের সাথে মেলে (উদাহরণস্বরূপ, কোয়েরির নাম, প্রকার, আইডি এবং সমাধানকারী উত্স পোর্ট দ্বারা) এবং প্রকৃত নাম সার্ভার থেকে একটি প্রতিক্রিয়ার আগে প্রাপ্ত হয়, সমাধানকারী নকল প্রতিক্রিয়া গ্রহণ করে এবং এটি ক্যাশ করে এবং বাতিল করে প্রকৃত প্রতিক্রিয়া।
5. আপস করা ডোমেন বা জোনের জন্য ভবিষ্যতের প্রশ্নের উত্তর ক্যাশে থেকে জাল ডিএনএস রেজোলিউশন দিয়ে দেওয়া হয়। যদি আক্রমণকারী নকল প্রতিক্রিয়ায় একটি খুব দীর্ঘ সময়-টু-লাইভ নির্দিষ্ট করে থাকে, জাল রেকর্ডগুলি রিফ্রেশ না করে যতদিন সম্ভব ক্যাশে থাকে।

কামিনস্কি আক্রমণের একটি চমৎকার ভূমিকার জন্য , কামিনস্কি ডিএনএস দুর্বলতার জন্য একটি সচিত্র নির্দেশিকা দেখুন।

DoS এবং পরিবর্ধন আক্রমণ

DNS সমাধানকারীরা সাধারণ DoS হুমকির সাপেক্ষে যা যেকোনো নেটওয়ার্ক সিস্টেমকে আঘাত করে। যাইহোক, পরিবর্ধন আক্রমণগুলি বিশেষ উদ্বেগের কারণ কারণ DNS সমাধানকারীরা আক্রমণকারীদের জন্য আকর্ষণীয় লক্ষ্যবস্তু যারা অতিরিক্ত বিনামূল্যে ব্যান্ডউইথ লাভের জন্য সমাধানকারীদের বৃহৎ প্রতিক্রিয়া-টু-অনুরোধের আকারের অনুপাতকে কাজে লাগায়। EDNS0 (DNS-এর জন্য এক্সটেনশন মেকানিজম) সমর্থনকারী রিসোলভারগুলি বিশেষভাবে দুর্বল কারণ প্যাকেটের আকার যথেষ্ট বড় যা তারা ফেরত দিতে পারে।

একটি পরিবর্ধনের দৃশ্যে, আক্রমণটি নিম্নরূপ এগিয়ে যায়:

1. আক্রমণকারী একটি নকল উৎস আইপি ঠিকানা ব্যবহার করে একটি শিকার DNS সার্ভার প্রশ্ন পাঠায়। প্রশ্নগুলি একই জাল আইপি ঠিকানা ব্যবহার করে একটি একক সিস্টেম বা সিস্টেমের একটি নেটওয়ার্ক থেকে পাঠানো যেতে পারে। প্রশ্নগুলি এমন রেকর্ডগুলির জন্য যা আক্রমণকারী জানে যে এর ফলে অনেক বড় প্রতিক্রিয়া হবে, মূল প্রশ্নের আকারের কয়েক ডজন গুণ ¹ পর্যন্ত (তাই নাম "পরিবর্ধন" আক্রমণ)।
2. ভিকটিম সার্ভার জাল রিকোয়েস্টে পাস করা সোর্স আইপি অ্যাড্রেসের বড় প্রতিক্রিয়া পাঠায়, যা সিস্টেমকে অপ্রতিরোধ্য করে এবং একটি DoS পরিস্থিতি সৃষ্টি করে।

প্রশমন

DNS দুর্বলতার জন্য স্ট্যান্ডার্ড সিস্টেম-ওয়াইড সমাধান হল DNSSEC । যাইহোক, এটি সর্বজনীনভাবে বাস্তবায়িত না হওয়া পর্যন্ত, খোলা ডিএনএস সমাধানকারীদের স্বাধীনভাবে পরিচিত হুমকির বিরুদ্ধে কিছু ব্যবস্থা গ্রহণ করতে হবে। অনেক কৌশল প্রস্তাব করা হয়েছে; IETF RFC 5452 দেখুন: তাদের বেশিরভাগের একটি ওভারভিউয়ের জন্য জাল উত্তরগুলির বিরুদ্ধে ডিএনএসকে আরও স্থিতিস্থাপক করার ব্যবস্থা । Google পাবলিক ডিএনএস-এ, আমরা নিম্নলিখিত পদ্ধতিগুলি প্রয়োগ করেছি এবং আমরা সুপারিশ করছি:

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

ডিএনএসএসইসি

ডোমেন নেম সিকিউরিটি এক্সটেনশন (DNSSEC) স্ট্যান্ডার্ডটি বেশ কয়েকটি IETF RFC-তে নির্দিষ্ট করা হয়েছে: 4033 , 4034 , 4035 , এবং 5155 ৷

নাম সার্ভার থেকে প্রাপ্ত প্রতিক্রিয়াগুলির সত্যতা যাচাই করে ডিএনএসএসইসি কাউন্টার ক্যাশে বিষক্রিয়ার আক্রমণ বাস্তবায়নকারী সমাধানকারীরা৷ প্রতিটি DNS জোন ব্যক্তিগত/পাবলিক কী জোড়ার একটি সেট বজায় রাখে এবং প্রতিটি DNS রেকর্ডের জন্য, ব্যক্তিগত কী ব্যবহার করে একটি অনন্য ডিজিটাল স্বাক্ষর তৈরি এবং এনক্রিপ্ট করা হয়। সংশ্লিষ্ট পাবলিক কী তারপর প্যারেন্ট জোনের অন্তর্গত কীগুলির মাধ্যমে বিশ্বাসের চেইন এর মাধ্যমে প্রমাণীকরণ করা হয়। DNSSEC-সঙ্গী সমাধানকারীরা এমন প্রতিক্রিয়া প্রত্যাখ্যান করে যাতে সঠিক স্বাক্ষর থাকে না। DNSSEC কার্যকরভাবে প্রতিক্রিয়াগুলিকে টেম্পার করা থেকে বাধা দেয়, কারণ বাস্তবে, ব্যক্তিগত কীগুলিতে অ্যাক্সেস ছাড়া স্বাক্ষর জাল করা প্রায় অসম্ভব।

জানুয়ারী 2013 অনুযায়ী, Google পাবলিক DNS সম্পূর্ণরূপে DNSSEC সমর্থন করে। আমরা DNSSEC-ফরম্যাট করা বার্তাগুলি গ্রহণ করি এবং ফরোয়ার্ড করি এবং সঠিক প্রমাণীকরণের জন্য প্রতিক্রিয়া যাচাই করি। আমরা দৃঢ়ভাবে অন্যান্য সমাধানকারীদের একই কাজ করতে উত্সাহিত করি।

এছাড়াও আমরা IETF RFC 8198-এ উল্লেখিত NSEC প্রতিক্রিয়াগুলিকে ক্যাশে করি: DNSSEC-প্রমাণিত ক্যাশের আক্রমণাত্মক ব্যবহার ৷ এটি DNSSEC প্রয়োগকারী নাম সার্ভারে এবং নেতিবাচক উত্তরের জন্য NSEC ব্যবহার করে NXDOMAIN প্রশ্নগুলি কমাতে পারে।

ক্লায়েন্ট-সাইড এনক্রিপ্ট করা পরিবহন

Google পাবলিক DNS এনক্রিপ্ট করা ট্রান্সপোর্ট প্রোটোকল, HTTPS এর উপর DNS এবং TLS এর উপর DNS এর জন্য সমর্থন অফার করে। এই প্রোটোকলগুলি টেম্পারিং, ইভসড্রপিং এবং স্পুফিং প্রতিরোধ করে, ক্লায়েন্ট এবং Google পাবলিক ডিএনএসের মধ্যে গোপনীয়তা এবং নিরাপত্তাকে ব্যাপকভাবে বৃদ্ধি করে৷ তারা এন্ড-টু-এন্ড প্রমাণীকৃত DNS লুকআপ প্রদানের জন্য DNSSEC এর পরিপূরক।

মৌলিক বৈধতা পরীক্ষা বাস্তবায়ন

কিছু ডিএনএস ক্যাশে দুর্নীতি অনিচ্ছাকৃত, এবং অগত্যা দূষিত নয়, অনুরোধ এবং প্রতিক্রিয়াগুলির মধ্যে অমিলের কারণে হতে পারে (যেমন সম্ভবত একটি ভুল কনফিগার করা নাম সার্ভারের কারণে, ডিএনএস সফ্টওয়্যারে একটি বাগ ইত্যাদি)। ন্যূনতম, DNS সমাধানকারীদের নাম সার্ভারের প্রতিক্রিয়াগুলির বিশ্বাসযোগ্যতা এবং প্রাসঙ্গিকতা যাচাই করার জন্য চেক করা উচিত। আমরা নিম্নলিখিত সমস্ত প্রতিরক্ষার সুপারিশ (এবং বাস্তবায়ন) করি:

• বহির্গামী অনুরোধগুলিতে পুনরাবৃত্তিমূলক বিট সেট করবেন না এবং সর্বদা সুস্পষ্টভাবে প্রতিনিধি চেইন অনুসরণ করুন। পুনরাবৃত্ত বিট নিষ্ক্রিয় করা নিশ্চিত করে যে আপনার সমাধানকারী "পুনরাবৃত্ত" মোডে কাজ করে যাতে আপনি অন্য নাম সার্ভারকে আপনার পক্ষ থেকে এই প্রশ্নগুলি সম্পাদন করার অনুমতি দেওয়ার পরিবর্তে প্রতিনিধি চেইনের প্রতিটি নাম সার্ভারকে স্পষ্টভাবে জিজ্ঞাসা করেন৷
• সন্দেহজনক প্রতিক্রিয়া বার্তা প্রত্যাখ্যান করুন. আমরা কি "সন্দেহজনক" বলে মনে করি তার বিশদ বিবরণের জন্য নীচে দেখুন।
• আগের অনুরোধ থেকে ক্যাশে করা আঠালো রেকর্ডের উপর ভিত্তি করে ক্লায়েন্টদের কাছে A রেকর্ড ফেরত দেবেন না। উদাহরণস্বরূপ, আপনি যদি ns1.example.com-এর জন্য একটি ক্লায়েন্ট ক্যোয়ারী পান, তাহলে একটি .com TLD নাম সার্ভার থেকে ফিরে আসা ক্যাশে করা আঠালো রেকর্ডের উপর ভিত্তি করে একটি A রেকর্ড পাঠানোর পরিবর্তে আপনার ঠিকানাটি পুনরায় সমাধান করা উচিত।

প্রয়োজনীয় মানদণ্ড পূরণ করে না এমন প্রতিক্রিয়া প্রত্যাখ্যান করা

Google পাবলিক DNS নিম্নলিখিত সবগুলি প্রত্যাখ্যান করে:

• বিশ্লেষণযোগ্য বা বিকৃত প্রতিক্রিয়া।
• প্রতিক্রিয়া যেখানে কী ক্ষেত্রগুলি অনুরোধে সংশ্লিষ্ট ক্ষেত্রের সাথে মেলে না৷ এর মধ্যে রয়েছে ক্যোয়ারী আইডি, সোর্স আইপি, সোর্স পোর্ট, গন্তব্য আইপি বা কোয়েরির নাম। DNS স্পুফ আচরণের সম্পূর্ণ বিবরণের জন্য RFC 5452, বিভাগ 3 দেখুন।
• অনুরোধের সাথে প্রাসঙ্গিক নয় এমন রেকর্ড।
• উত্তর রেকর্ডের জন্য আমরা CNAME চেইন পুনর্গঠন করতে পারি না।
• রেকর্ড (উত্তর, কর্তৃপক্ষ, বা অতিরিক্ত বিভাগে) যার জন্য প্রতিক্রিয়া নাম সার্ভার বিশ্বাসযোগ্য নয়। আমরা একটি প্রদত্ত ডোমেনের জন্য প্রতিনিধি শৃঙ্খলে একটি নাম সার্ভারের স্থান দ্বারা "বিশ্বাসযোগ্যতা" নির্ধারণ করি। Google পাবলিক DNS ক্যাশে প্রতিনিধি চেইন তথ্য, এবং আমরা একটি নির্দিষ্ট অনুরোধে সাড়া দেওয়ার জন্য প্রতিক্রিয়াকারী নাম সার্ভারের বিশ্বাসযোগ্যতা নির্ধারণ করতে ক্যাশে করা তথ্যের বিপরীতে প্রতিটি আগত প্রতিক্রিয়া যাচাই করি।

অনুরোধে এনট্রপি যোগ করা হচ্ছে

একবার একজন সমাধানকারী মৌলিক স্যানিটি চেক প্রয়োগ করে, একজন আক্রমণকারীকে কোয়েরি আইডি, ইউডিপি পোর্ট (অনুরোধের), আইপি ঠিকানা (প্রতিক্রিয়ার) এবং মূল প্রশ্নের নামের সাথে মেলে দেওয়ার জন্য প্রতিক্রিয়া সহ শিকার সমাধানকারীকে প্লাবিত করতে হবে বৈধ নাম সার্ভার করার আগে অনুরোধ করুন।

দুর্ভাগ্যবশত, এটি অর্জন করা কঠিন নয়, কারণ একটি অনন্যভাবে শনাক্তকারী ক্ষেত্র, ক্যোয়ারী আইডি মাত্র 16 বিট দীর্ঘ (যেমন এটি সঠিকভাবে পাওয়ার জন্য 1/65,536 সুযোগের জন্য)। অন্যান্য ক্ষেত্রগুলিও পরিসরে সীমিত, অনন্য সমন্বয়ের মোট সংখ্যাকে তুলনামূলকভাবে কম সংখ্যায় পরিণত করে। জড়িত সমন্বয়বিদ্যার গণনার জন্য RFC 5452, বিভাগ 7 দেখুন।

অতএব, চ্যালেঞ্জ হল অনুরোধ প্যাকেটে যতটা সম্ভব এনট্রপি যোগ করা, DNS বার্তার মানক বিন্যাসের মধ্যে, আক্রমণকারীদের পক্ষে সুযোগের উইন্ডোর মধ্যে ক্ষেত্রগুলির একটি বৈধ সংমিশ্রণ সফলভাবে মেলানো আরও কঠিন করে তোলা। আমরা নিম্নলিখিত বিভাগে আলোচনা করা সমস্ত কৌশল সুপারিশ করি এবং প্রয়োগ করেছি।

আমরা জুলাই 2022-এ DNS OARC 38 সম্মেলনে এখানে উল্লিখিত কৌশলগুলির একটি আপডেট পর্যালোচনা উপস্থাপন করেছি। উপস্থাপনাটিতে নাম সার্ভার অপারেটরদের জন্য সুপারিশও অন্তর্ভুক্ত রয়েছে।

উৎস পোর্ট র্যান্ডমাইজ করা

একটি মৌলিক পদক্ষেপ হিসাবে, বহির্গামী অনুরোধ প্যাকেটগুলিকে ডিফল্ট UDP পোর্ট 53 ব্যবহার করার অনুমতি দেবেন না, বা একাধিক পোর্ট বরাদ্দ করার জন্য একটি অনুমানযোগ্য অ্যালগরিদম ব্যবহার করতে দেবেন না (যেমন সাধারণ বৃদ্ধি)। আপনার সিস্টেমে অনুমোদিত হিসাবে 1024 থেকে 65535 পর্যন্ত বিস্তৃত পোর্ট ব্যবহার করুন এবং পোর্টগুলি বরাদ্দ করতে একটি নির্ভরযোগ্য র্যান্ডম নম্বর জেনারেটর ব্যবহার করুন। উদাহরণস্বরূপ, Google পাবলিক ডিএনএস প্রায় 32,000টি বিভিন্ন পোর্ট নম্বরের অনুমতি দিতে ~15 বিট ব্যবহার করে।

মনে রাখবেন যে যদি আপনার সার্ভারগুলি ফায়ারওয়াল, লোড-ব্যালেন্সার বা নেটওয়ার্ক ঠিকানা অনুবাদ (NAT) সম্পাদন করে এমন অন্যান্য ডিভাইসগুলির পিছনে স্থাপন করা হয়, তবে সেই ডিভাইসগুলি বহির্গামী প্যাকেটগুলিতে পোর্টগুলিকে এলোমেলো করে দিতে পারে। নিশ্চিত করুন যে আপনি পোর্ট ডি-র্যান্ডমাইজেশন নিষ্ক্রিয় করতে NAT ডিভাইসগুলি কনফিগার করেছেন৷

নাম সার্ভারের র্যান্ডমাইজিং পছন্দ

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

আপনি যদি লেটেন্সি সম্পর্কে উদ্বিগ্ন হন, আপনি রাউন্ড-ট্রিপ টাইম (RTT) ব্যান্ডিং ব্যবহার করতে পারেন, যার মধ্যে নির্দিষ্ট লেটেন্সি থ্রেশহোল্ড (যেমন 30 ms, 300 ms, ইত্যাদি) এর নিচে থাকা ঠিকানাগুলির একটি সীমার মধ্যে র্যান্ডমাইজ করা থাকে।

DNS কুকিজ

RFC 7873 DNS বার্তাগুলিতে 64-বিট কুকিজ যোগ করার জন্য একটি EDNS0 বিকল্প সংজ্ঞায়িত করে। একটি DNS কুকি সমর্থনকারী ক্লায়েন্ট একটি র্যান্ডম 64-বিট কুকি এবং ঐচ্ছিকভাবে (যদি পরিচিত) একটি অনুরোধে একটি সার্ভার কুকি অন্তর্ভুক্ত করে। যদি একটি সমর্থনকারী সার্ভার একটি অনুরোধে কুকি বিকল্পটিকে বৈধ বলে খুঁজে পায়, তাহলে প্রতিক্রিয়ায় ক্লায়েন্ট কুকি এবং সঠিক সার্ভার কুকি প্রতিফলিত করে৷ সমর্থনকারী ক্লায়েন্ট তারপর প্রতিক্রিয়াতে ক্লায়েন্ট কুকি যাচাই করে প্রত্যাশিত সার্ভার থেকে প্রতিক্রিয়াটি এসেছে তা যাচাই করতে পারে।

যদি একটি নাম সার্ভার DNS কুকিজ সমর্থন না করে, তাহলে নিম্নলিখিত দুটি বিকল্প এনট্রপি যোগ করতে ব্যবহার করা যেতে পারে।

ক্যোয়ারী নামের ক্ষেত্রে র্যান্ডমাইজ করা

DNS মানগুলির জন্য প্রয়োজন যে নাম সার্ভারগুলি কেস-সংবেদনশীলতার সাথে নামগুলি ব্যবহার করে৷ উদাহরণস্বরূপ, example.com এবং EXAMPLE.COM নামগুলি একই IP ঠিকানা ² -তে সমাধান করা উচিত। উপরন্তু, নাম সার্ভারের একটি ছোট সংখ্যালঘু ব্যতীত সবকটি উত্তরে নামটি প্রতিধ্বনিত করে, যেমনটি অনুরোধে উপস্থিত হয়েছিল, মূল ক্ষেত্রে সংরক্ষণ করে।

অতএব, অনুরোধে এনট্রপি যোগ করার আরেকটি উপায় হল এলোমেলোভাবে অনুসন্ধান করা ডোমেন নামের অক্ষরের ক্ষেত্রে তারতম্য করা। এই কৌশলটি "0x20" নামেও পরিচিত কারণ US-ASCII অক্ষরের ক্ষেত্রে বিট 0x20 ব্যবহার করা হয়, লেনদেনের পরিচয় উন্নত করতে DNS লেবেলে Bit 0x20-এর ব্যবহার IETF ইন্টারনেট ড্রাফটে প্রথম প্রস্তাব করা হয়েছিল। এই কৌশলের সাহায্যে, নাম সার্ভারের প্রতিক্রিয়া অবশ্যই শুধুমাত্র ক্যোয়ারী নামের সাথে মিলবে না কিন্তু নামের স্ট্রিং-এর প্রতিটি অক্ষরের ক্ষেত্রেও মিলবে; উদাহরণস্বরূপ, wWw.eXaMpLe.CoM বা WwW.ExamPLe.COm । এটি শীর্ষ-স্তরের এবং রুট ডোমেনগুলির জন্য কোয়েরিতে সামান্য বা কোন এনট্রপি যোগ করতে পারে না, তবে এটি বেশিরভাগ হোস্টনামের জন্য কার্যকর।

এই কৌশলটি বাস্তবায়ন করার সময় আমরা একটি উল্লেখযোগ্য চ্যালেঞ্জ আবিষ্কার করেছি যে কিছু নাম সার্ভার প্রত্যাশিত প্রতিক্রিয়া আচরণ অনুসরণ করে না:

• কিছু নাম সার্ভার সম্পূর্ণ কেস-অসংবেদনশীলতার সাথে প্রতিক্রিয়া জানায়: অনুরোধের ক্ষেত্রে নির্বিশেষে তারা সঠিকভাবে একই ফলাফল প্রদান করে, কিন্তু প্রতিক্রিয়াটি অনুরোধের নামের সঠিক ক্ষেত্রের সাথে মেলে না।
• অন্যান্য নাম সার্ভারগুলি সম্পূর্ণ কেস-সংবেদনশীলতার সাথে প্রতিক্রিয়া জানায় (ডিএনএস মান লঙ্ঘন করে): তারা অনুরোধের ক্ষেত্রের উপর নির্ভর করে সমতুল্য নামগুলিকে ভিন্নভাবে পরিচালনা করে, হয় একেবারে উত্তর দিতে ব্যর্থ হয় বা ভুল NXDOMAIN প্রতিক্রিয়া ফেরত দেয় যা নামের সঠিক ক্ষেত্রের সাথে মেলে অনুরোধ.
• arpa জোনে পিটিআর কোয়েরি ছাড়া কিছু নাম সার্ভার সঠিকভাবে কাজ করে।

এই উভয় প্রকারের নাম সার্ভারের জন্য, ক্যোয়ারী নামের ক্ষেত্রে পরিবর্তন করলে অবাঞ্ছিত ফলাফল আসবে: প্রথম গোষ্ঠীর জন্য, প্রতিক্রিয়া একটি নকল প্রতিক্রিয়া থেকে আলাদা করা যাবে না; দ্বিতীয় গ্রুপের জন্য, প্রতিক্রিয়া (যদি থাকে) সম্পূর্ণ ভুল হতে পারে।

এই সমস্যার আমাদের বর্তমান সমাধান হল শুধুমাত্র নাম সার্ভারের জন্য কেস র্যান্ডমাইজেশন ব্যবহার করা যা আমরা জানি যে মানগুলি সঠিকভাবে প্রয়োগ করে। আমরা আমাদের লগ বিশ্লেষণের উপর ভিত্তি করে তাদের প্রত্যেকের জন্য উপযুক্ত ব্যতিক্রম সাবডোমেন তালিকাভুক্ত করি। যদি এই সার্ভারগুলি থেকে আসা একটি প্রতিক্রিয়া সঠিক ক্ষেত্রে না থাকে, আমরা প্রতিক্রিয়া প্রত্যাখ্যান করি। সক্রিয় নাম সার্ভারগুলি আমাদের আউটবাউন্ড ট্র্যাফিকের 70% এর বেশি পরিচালনা করে।

ক্যোয়ারী নামের জন্য নন্স লেবেল প্রিপেন্ডিং

যদি একটি সমাধানকারী সরাসরি ক্যাশে থেকে একটি নাম সমাধান করতে না পারে, বা সরাসরি একটি প্রামাণিক নাম সার্ভারকে জিজ্ঞাসা করতে না পারে, তাহলে এটি অবশ্যই একটি রুট বা TLD নাম সার্ভার থেকে রেফারেলগুলি অনুসরণ করবে৷ বেশিরভাগ ক্ষেত্রে, রুট বা TLD নাম সার্ভারে অনুরোধের ফলে IP ঠিকানায় নামটি সমাধান করার চেষ্টা না করে অন্য নাম সার্ভারে রেফারেল করা হবে। এই ধরনের অনুরোধের জন্য, অনুরোধের এনট্রপি বাড়ানোর জন্য একটি কোয়েরি নামের সাথে একটি র্যান্ডম লেবেল সংযুক্ত করা নিরাপদ হওয়া উচিত, যেখানে একটি অস্তিত্বহীন নাম সমাধান করতে ব্যর্থ হওয়ার ঝুঁকি না নিয়ে। অর্থাৎ, entriih- entriih-f10r3.www.google.com এর মতো একটি ননস লেবেল যুক্ত নামের জন্য একটি রেফারিং নাম সার্ভারে একটি অনুরোধ পাঠানো হলে, www.google.com এর অনুরোধের মতো একই ফলাফল ফেরত দেওয়া উচিত।

যদিও বাস্তবে এই ধরনের অনুরোধগুলি বহির্গামী অনুরোধের 3% এরও কম তৈরি করে, স্বাভাবিক ট্র্যাফিক অনুমান করে (যেহেতু বেশিরভাগ প্রশ্নের উত্তর সরাসরি ক্যাশে বা একক প্রশ্নের দ্বারা দেওয়া যেতে পারে), এইগুলি অবিকল সেই ধরনের অনুরোধ যা একজন আক্রমণকারী জোর করার চেষ্টা করে। সমস্যা সমাধানকারী। অতএব, এই কৌশলটি কামিনস্কি-শৈলীর শোষণ প্রতিরোধে খুব কার্যকর হতে পারে।

এই কৌশলটি বাস্তবায়নের জন্য প্রয়োজন যে ননস লেবেলগুলি কেবলমাত্র সেই অনুরোধগুলির জন্য ব্যবহার করা হবে যা রেফারেলের ফলাফলের গ্যারান্টিযুক্ত; অর্থাৎ, যে প্রতিক্রিয়াগুলিতে উত্তর বিভাগে রেকর্ড নেই। যাইহোক, এই ধরনের অনুরোধের সেট সংজ্ঞায়িত করার চেষ্টা করার সময় আমরা বেশ কিছু চ্যালেঞ্জের সম্মুখীন হয়েছি:

• কিছু কান্ট্রি-কোড TLD (ccTLD) নাম সার্ভার আসলে অন্যান্য দ্বিতীয়-স্তরের TLDs (2LDs) এর জন্য প্রামাণিক। যদিও তাদের দুটি লেবেল রয়েছে, 2LDs টিএলডির মতো আচরণ করে, যে কারণে তারা প্রায়শই ccTLD নাম সার্ভার দ্বারা পরিচালিত হয়। উদাহরণস্বরূপ, .uk নাম সার্ভারগুলি mod.uk এবং nic.uk জোনের জন্যও প্রামাণিক, এবং তাই, হোস্টনামগুলি সেই জোনগুলির মধ্যে রয়েছে, যেমন www.nic.uk , www.mod.uk ইত্যাদি৷ অন্য কথায়, এই ধরনের হোস্টনামের রেজোলিউশনের জন্য ccTLD নাম সার্ভারের কাছে অনুরোধের ফলে রেফারেল হবে না, কিন্তু প্রামাণিক উত্তর হবে; এই ধরনের হোস্টনামের সাথে ননস লেবেল যুক্ত করলে নামগুলি অমীমাংসিত হবে।
• কখনও কখনও জেনেরিক TLD (gTLD) নাম সার্ভার নাম সার্ভারের জন্য অ-অনুমোদিত প্রতিক্রিয়া প্রদান করে। অর্থাৎ, কিছু নাম সার্ভার হোস্টনাম আছে যেগুলি তাদের ডোমেনের জন্য জোনে না হয়ে একটি gTLD জোনে বাস করে। একটি জিটিএলডি এই হোস্টনামের জন্য একটি অ-অনুমোদিত উত্তর প্রদান করবে, রেফারেল ফেরত দেওয়ার পরিবর্তে এটির ডাটাবেসে থাকা যাই হোক না কেন আঠালো রেকর্ড ব্যবহার করে। উদাহরণস্বরূপ, ns3.indexonlineserver.com নামের সার্ভারটি ns3.indexonlineserver.com জোনের পরিবর্তে .COM gTLD জোনে indexonlineserver.com । যখন আমরা n3.indexonlineserver.com জন্য একটি জিটিএলডি সার্ভারে একটি অনুরোধ জারি করি, তখন আমরা রেফারেলের পরিবর্তে এটির জন্য একটি আইপি ঠিকানা পেয়েছি৷ যাইহোক, যদি আমরা একটি ননস লেবেল প্রিপেন্ড করে থাকি, তাহলে আমরা indexonlineserver.com এ একটি রেফারেল পেয়েছি, যা তখন হোস্টনামটি সমাধান করতে অক্ষম ছিল। অতএব, আমরা নাম সার্ভারের জন্য ননস লেবেল যুক্ত করতে পারি না যার জন্য একটি জিটিএলডি সার্ভার থেকে একটি রেজোলিউশন প্রয়োজন।
• অঞ্চল এবং হোস্টনামের জন্য কর্তৃপক্ষ সময়ের সাথে পরিবর্তিত হয়। এটি একটি অপ্রস্তুত হোস্টনামের কারণ হতে পারে যা একবার অমীমাংসিত হয়ে উঠতে পারে যদি প্রতিনিধি চেইন পরিবর্তন হয়।

এই চ্যালেঞ্জগুলি মোকাবেলা করার জন্য, আমরা হোস্টনামের জন্য ব্যতিক্রমগুলি কনফিগার করেছি যার জন্য আমরা ননস লেবেল যুক্ত করতে পারি না। এগুলি হল হোস্টনাম যার জন্য TLD নাম সার্ভারগুলি আমাদের সার্ভার লগ অনুসারে নন-রেফারেল প্রতিক্রিয়াগুলি প্রদান করে৷ আমরা ক্রমাগত ব্যতিক্রম তালিকা পর্যালোচনা করি যাতে এটি সময়ের সাথে বৈধ থাকে।

সদৃশ প্রশ্নগুলি সরানো হচ্ছে

DNS সমাধানকারীরা "জন্মদিনের আক্রমণ" এর জন্য ঝুঁকিপূর্ণ, তাই বলা হয় কারণ তারা গাণিতিক "জন্মদিনের প্যারাডক্স" ব্যবহার করে, যেখানে একটি ম্যাচের সম্ভাবনার জন্য প্রচুর পরিমাণে ইনপুট প্রয়োজন হয় না। জন্মদিনের আক্রমণে শিকার সার্ভারকে শুধু নকল প্রতিক্রিয়াই নয়, প্রাথমিক প্রশ্নের সাথে প্লাবিত করা জড়িত, একটি একক নামের রেজোলিউশনের জন্য একাধিক অনুরোধ জারি করার জন্য সমাধানকারীর উপর নির্ভর করা। জারি করা বহির্গামী অনুরোধের সংখ্যা যত বেশি হবে, আক্রমণকারীর একটি নকল প্রতিক্রিয়ার সাথে সেই অনুরোধগুলির একটির সাথে মিলিত হওয়ার সম্ভাবনা তত বেশি: একজন আক্রমণকারীকে শুধুমাত্র 300টি ইন-ফ্লাইট অনুরোধের জন্য প্রয়োজন একটি জাল মেলাতে 50% সাফল্যের সুযোগের জন্য প্রতিক্রিয়া, এবং 100% সাফল্যের জন্য 700টি অনুরোধ।

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

রেট-সীমিত প্রশ্ন

ডিনায়াল-অফ-সার্ভিস আক্রমণ প্রতিরোধ করা ওপেন রিকারসিভ ডিএনএস সমাধানকারীদের জন্য বেশ কয়েকটি বিশেষ চ্যালেঞ্জ তৈরি করে:

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

DoS আক্রমণ মোকাবেলার জন্য সর্বোত্তম পন্থা হল একটি হার-সীমিতকরণ বা "থ্রটলিং" প্রক্রিয়া আরোপ করা। Google পাবলিক DNS দুই ধরনের হার নিয়ন্ত্রণ প্রয়োগ করে:

• অন্যান্য নাম সার্ভারে বহির্গামী অনুরোধের হার নিয়ন্ত্রণ। আমাদের সমাধানকারী সার্ভারগুলি থেকে চালু করা যেতে পারে এমন DoS আক্রমণ থেকে অন্যান্য DNS নাম সার্ভারগুলিকে রক্ষা করার জন্য, Google পাবলিক DNS প্রতিটি নাম সার্ভার আইপি ঠিকানার জন্য প্রতিটি পরিবেশন ক্লাস্টার থেকে বহির্গামী অনুরোধের উপর QPS সীমা প্রয়োগ করে৷

• ক্লায়েন্টদের বহির্গামী প্রতিক্রিয়া হার নিয়ন্ত্রণ. আমাদের সমাধানকারী সার্ভার থেকে চালু করা যেতে পারে এমন প্রশস্তকরণ এবং প্রথাগত বিতরণ করা DoS (বটনেট) আক্রমণ থেকে অন্য কোনো সিস্টেমকে রক্ষা করার জন্য, Google পাবলিক DNS ক্লায়েন্টের প্রশ্নের উপর সীমিত দুই ধরনের হার সম্পাদন করে:

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

  যদি একটি উৎসের আইপি ঠিকানা থেকে ডিএনএস কোয়েরি সর্বোচ্চ QPS হার অতিক্রম করে, অতিরিক্ত প্রশ্ন বাদ দেওয়া হবে। যদি একটি উৎস আইপি ঠিকানা থেকে UDP-এর উপর DNS প্রশ্নগুলি ধারাবাহিকভাবে গড় ব্যান্ডউইথ বা পরিবর্ধন সীমা অতিক্রম করে (মাঝে মাঝে বড় প্রতিক্রিয়া পাস হবে), প্রশ্নগুলি বাদ দেওয়া হতে পারে বা শুধুমাত্র একটি ছোট প্রতিক্রিয়া পাঠানো হতে পারে। ছোট প্রতিক্রিয়াগুলি একটি ত্রুটি প্রতিক্রিয়া বা ছেঁটে ফেলা বিট সেট সহ একটি খালি প্রতিক্রিয়া হতে পারে (যাতে বেশিরভাগ বৈধ প্রশ্নগুলি টিসিপির মাধ্যমে পুনরায় চেষ্টা করা হবে এবং সফল হবে)। সমস্ত সিস্টেম বা প্রোগ্রাম TCP এর মাধ্যমে পুনরায় চেষ্টা করবে না, এবং TCP এর উপর DNS ক্লায়েন্ট সাইডে ফায়ারওয়াল দ্বারা অবরুদ্ধ হতে পারে, তাই কিছু অ্যাপ্লিকেশন সঠিকভাবে কাজ নাও করতে পারে যখন উত্তরগুলি কাটা হয়। যাইহোক, ছেঁটে ফেলা RFC- অনুগত ক্লায়েন্টদের বেশিরভাগ ক্ষেত্রে সঠিকভাবে কাজ করতে দেয়।