ক্রোমিয়ামের একটি বৈশিষ্ট্য রুট ডিএনএস সার্ভারে একটি বিশাল লোড তৈরি করে

ক্রোমিয়াম ব্রাউজার, গুগল ক্রোমের সমৃদ্ধ ওপেন-সোর্স প্যারেন্ট এবং নতুন মাইক্রোসফ্ট এজ, এমন একটি বৈশিষ্ট্যের জন্য উল্লেখযোগ্য নেতিবাচক মনোযোগ পেয়েছে যা ভাল উদ্দেশ্য নিয়ে তৈরি করা হয়েছিল: এটি ব্যবহারকারীর আইএসপি "চুরি" করছে কিনা তা পরীক্ষা করে অ-বিদ্যমান ডোমেন কোয়েরির ফলাফল .

ইন্ট্রানেট রিডাইরেক্ট ডিটেক্টর, যা পরিসংখ্যানগতভাবে বিদ্যমান থাকার সম্ভাবনা কম এমন র্যান্ডম "ডোমেন"-এর জন্য জাল প্রশ্ন তৈরি করে, বিশ্বব্যাপী রুট ডিএনএস সার্ভার দ্বারা প্রাপ্ত মোট ট্র্যাফিকের প্রায় অর্ধেকের জন্য দায়ী৷ ভেরিসাইন ইঞ্জিনিয়ার ম্যাট থমাস একটি দীর্ঘ লিখেছেন পোস্ট APNIC ব্লগে সমস্যাটি বর্ণনা করে এবং এর স্কেল মূল্যায়ন করে।

কিভাবে DNS রেজোলিউশন সাধারণত সঞ্চালিত হয়

.com, .net, ইত্যাদি সমাধান করার জন্য এই সার্ভারগুলি হল সর্বোচ্চ কর্তৃপক্ষের সাথে যোগাযোগ করা উচিত যাতে তারা আপনাকে বলবে যে frglxrtmpuf একটি টপ-লেভেল ডোমেইন (TLD) নয়।

ডিএনএস, বা ডোমেন নেম সিস্টেম, এমন একটি সিস্টেম যার মাধ্যমে কম্পিউটারগুলি 3.128.236.93 এর মতো অনেক কম ব্যবহারকারী-বান্ধব আইপি ঠিকানাগুলিতে arstechnica.com এর মতো স্মরণীয় ডোমেন নামগুলি সমাধান করতে পারে। DNS ছাড়া, ইন্টারনেট এমনভাবে বিদ্যমান থাকবে না যা মানুষ ব্যবহার করতে পারে, যার অর্থ উচ্চ-স্তরের অবকাঠামোতে অপ্রয়োজনীয় লোড একটি বাস্তব সমস্যা।

একটি একক আধুনিক ওয়েব পৃষ্ঠা লোড করার জন্য অবিশ্বাস্য সংখ্যক DNS লুকআপের প্রয়োজন হতে পারে। উদাহরণস্বরূপ, যখন আমরা ESPN-এর হোমপেজ বিশ্লেষণ করি, তখন আমরা a.espncdn.com থেকে z.motads.com পর্যন্ত 93টি পৃথক ডোমেন নাম গণনা করেছি। পৃষ্ঠাটি সম্পূর্ণরূপে লোড করার জন্য তাদের সবগুলি প্রয়োজনীয়!

সার্চ ইঞ্জিনের জন্য এই ধরনের কাজের চাপ সামঞ্জস্য করার জন্য যা সমগ্র বিশ্বকে পরিবেশন করতে হবে, DNS একটি বহু-স্তরীয় শ্রেণিবিন্যাস হিসাবে ডিজাইন করা হয়েছে। এই পিরামিডের শীর্ষে রয়েছে রুট সার্ভার - প্রতিটি শীর্ষ-স্তরের ডোমেইন, যেমন .com, এর নিজস্ব সার্ভারের পরিবার রয়েছে যা তাদের নীচের প্রতিটি ডোমেনের জন্য সর্বোচ্চ কর্তৃপক্ষ। এক ধাপ উপরে этих সার্ভার হল রুট সার্ভার নিজেদের, থেকে a.root-servers.net থেকে m.root-servers.net.

কতক্ষন পর পর এটা ঘটে?

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

যদি স্থানীয় প্রদানকারীর DNS সার্ভার বা "ফরোয়ার্ডিং সার্ভার" এর কনফিগারেশনে নির্দিষ্ট করা কোনো ক্যাশে প্রতিক্রিয়া না থাকে, তাহলে অনুরোধটি সরাসরি প্রামাণিক ডোমেন সার্ভারে উত্থাপিত হয় ঊর্ধ্বতন যাকে আপনি রূপান্তর করার চেষ্টা করছেন। কখন домен.com এর মানে হবে যে অনুরোধটি ডোমেনেরই প্রামাণিক সার্ভারে পাঠানো হয়েছে com, যা অবস্থিত gtld-servers.net.

পদ্ধতি gtld-servers, যেটির জন্য অনুরোধ করা হয়েছিল, ডোমেইন domain.com-এর জন্য প্রামাণিক নাম সার্ভারের একটি তালিকার সাথে সাড়া দেয়, সেইসাথে এই ধরনের একটি নাম সার্ভারের IP ঠিকানা ধারণকারী অন্তত একটি লিঙ্ক রেকর্ড। এর পরে, প্রতিক্রিয়াগুলি চেইনের নিচে চলে যায় - প্রতিটি ফরোয়ার্ডার এই প্রতিক্রিয়াগুলিকে সেই সার্ভারের কাছে পাঠায় যা তাদের অনুরোধ করেছিল, যতক্ষণ না প্রতিক্রিয়া অবশেষে স্থানীয় প্রদানকারীর সার্ভার এবং ব্যবহারকারীর কম্পিউটারে পৌঁছায়। তাদের সকলেই এই প্রতিক্রিয়া ক্যাশে করে যাতে অপ্রয়োজনীয়ভাবে উচ্চ-স্তরের সিস্টেমগুলিকে বিরক্ত না করে।

বেশিরভাগ ক্ষেত্রে, নাম সার্ভার রেকর্ড করে domain.com এই ফরওয়ার্ডারগুলির মধ্যে একটিতে ইতিমধ্যেই ক্যাশে করা হবে, তাই রুট সার্ভারগুলিকে বিরক্ত করা হবে না। যাইহোক, আপাতত আমরা যে ধরনের URL এর সাথে পরিচিত তা নিয়ে কথা বলছি - যেটি একটি নিয়মিত ওয়েবসাইটে রূপান্তরিত হয়। Chrome অনুরোধগুলি স্তরে রয়েছে৷ ঊর্ধ্বতন এই, ক্লাস্টার নিজেদের ধাপে root-servers.net.

Chromium এবং NXDomain চুরি চেক

Chromium চেক করে "এই DNS সার্ভার কি আমাকে বোকা করছে?" Verisign এর রুট DNS সার্ভারের ক্লাস্টারে পৌঁছানো সমস্ত ট্রাফিকের প্রায় অর্ধেক।

ক্রোমিয়াম ব্রাউজার, গুগল ক্রোমের মূল প্রকল্প, নতুন মাইক্রোসফ্ট এজ এবং অগণিত কম পরিচিত ব্রাউজার, ব্যবহারকারীদের একটি একক বাক্সে অনুসন্ধানের সহজতা প্রদান করতে চায়, যাকে কখনও কখনও "অমনিবক্স" বলা হয়। অন্য কথায়, ব্যবহারকারী ব্রাউজার উইন্ডোর শীর্ষে একই টেক্সট ফিল্ডে আসল URL এবং সার্চ ইঞ্জিন কোয়েরি উভয়ই প্রবেশ করে। সরলীকরণের দিকে আরও একটি পদক্ষেপ নেওয়া, এটি ব্যবহারকারীকে URL এর অংশ প্রবেশ করতে বাধ্য করে না http:// বা https://.

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

যদি কোনও ব্যবহারকারী তাদের কোম্পানির ইন্ট্রানেটের "বিপণন" টাইপ করে এবং কোম্পানির ইন্ট্রানেটের একই নামের একটি অভ্যন্তরীণ ওয়েবসাইট থাকে, তাহলে ক্রোমিয়াম একটি তথ্য বাক্স প্রদর্শন করে ব্যবহারকারীকে জিজ্ঞাসা করে যে তারা "বিপণন" অনুসন্ধান করতে চান বা সেখানে যেতে চান https://marketing. এটি এমন নাও হতে পারে, কিন্তু অনেক ISP এবং সর্বজনীন Wi-Fi প্রদানকারী প্রতিটি ভুল বানান ইউআরএলকে "হাইজ্যাক" করে, ব্যবহারকারীকে কিছু ব্যানার-পূর্ণ পৃষ্ঠায় পুনঃনির্দেশ করে।

এলোমেলো প্রজন্ম

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

দুর্ভাগ্যবশত, নেটওয়ার্কে যে না ডিএনএস প্রশ্নের ফলাফল চুরি করে, এই তিনটি অপারেশন সাধারণত একেবারে শীর্ষে উঠে যায়, সমস্ত উপায়ে রুট নেম সার্ভারে যায়: স্থানীয় সার্ভার কীভাবে সমাধান করতে হয় তা জানে না qwajuixk, তাই এই অনুরোধটি তার ফরোয়ার্ডারের কাছে ফরোয়ার্ড করে, যা শেষ পর্যন্ত একই কাজ করে a.root-servers.net অথবা তার "ভাইদের" একজনকে "দুঃখিত, কিন্তু এটি একটি ডোমেন নয়" বলতে বাধ্য করা হবে না।

যেহেতু আনুমানিক 1,67*10^21 সম্ভাব্য জাল ডোমেইন নাম রয়েছে যার দৈর্ঘ্য সাত থেকে পনেরো অক্ষর পর্যন্ত, সবচেয়ে সাধারণ প্রতি "সৎ" নেটওয়ার্কে সম্পাদিত এই পরীক্ষাগুলি থেকে, এটি রুট সার্ভারে পৌঁছে যায়। এই পরিমাণ হিসাবে অনেক অর্ধেক ক্লাস্টারগুলির সেই অংশের পরিসংখ্যান অনুসারে রুট DNS-এর মোট লোডের root-servers.net, যা Verisign এর মালিকানাধীন।

ইতিহাসের পুনরাবৃত্তি ঘটে

এই প্রথমবার নয় যে সেরা উদ্দেশ্য নিয়ে একটি প্রকল্প তৈরি করা হয়েছে ব্যর্থ অথবা প্রায় অপ্রয়োজনীয় ট্র্যাফিকের সাথে একটি পাবলিক রিসোর্স প্লাবিত করে - এটি অবিলম্বে 2000 এর দশকের মাঝামাঝি সময়ে ডি-লিঙ্ক এবং পল-হেনিং কাম্পের NTP (নেটওয়ার্ক টাইম প্রোটোকল) সার্ভারের দীর্ঘ এবং দুঃখজনক ইতিহাসের কথা মনে করিয়ে দেয়।

2005 সালে, ফ্রিবিএসডি ডেভেলপার পল-হেনিং, যিনি ডেনমার্কের একমাত্র স্ট্র্যাটাম 1 নেটওয়ার্ক টাইম প্রোটোকল সার্ভারের মালিক ছিলেন, প্রেরিত ট্রাফিকের জন্য একটি অপ্রত্যাশিত এবং বড় বিল পেয়েছিলেন। সংক্ষেপে, কারণটি ছিল ডি-লিংক ডেভেলপাররা কোম্পানির সুইচ, রাউটার এবং অ্যাক্সেস পয়েন্টের লাইনের ফার্মওয়্যারে কাম্পা সার্ভার সহ স্ট্র্যাটাম 1 এনটিপি সার্ভারের ঠিকানা লিখেছিল। এটি অবিলম্বে কাম্পার সার্ভারের ট্র্যাফিক নয়গুণ বৃদ্ধি করেছে, যার ফলে ডেনিশ ইন্টারনেট এক্সচেঞ্জ (ডেনমার্কের ইন্টারনেট এক্সচেঞ্জ পয়েন্ট) তার শুল্ক "ফ্রি" থেকে "প্রতি বছর $9" এ পরিবর্তন করেছে।

সমস্যাটি ছিল না যে সেখানে অনেকগুলি ডি-লিঙ্ক রাউটার ছিল, তবে সেগুলি "লাইনের বাইরে" ছিল। অনেকটা ডিএনএসের মতো, এনটিপিকে অবশ্যই একটি ক্রমানুসারে কাজ করতে হবে - স্ট্র্যাটাম 0 সার্ভারগুলি স্ট্র্যাটাম 1 সার্ভারে তথ্য পাঠায়, যা স্ট্র্যাটাম 2 সার্ভারে তথ্য দেয় এবং অনুরূপ স্তরের নীচে। একটি সাধারণ হোম রাউটার, সুইচ বা অ্যাক্সেস পয়েন্ট যেমন একটি ডি-লিঙ্ক এনটিপি সার্ভার ঠিকানাগুলির সাথে প্রোগ্রাম করা হয়েছে স্ট্র্যাটাম 2 বা স্ট্র্যাটাম 3 সার্ভারে অনুরোধ পাঠাবে।

ক্রোমিয়াম প্রকল্প, সম্ভবত সর্বোত্তম উদ্দেশ্যের সাথে, DNS সমস্যায় NTP সমস্যার প্রতিলিপি তৈরি করেছে, ইন্টারনেটের রুট সার্ভারগুলিকে এমন অনুরোধ সহ লোড করছে যা তারা কখনই পরিচালনা করার জন্য ছিল না।

দ্রুত সমাধানের আশা রয়েছে

Chromium প্রকল্পের একটি ওপেন সোর্স আছে বাগ, যার জন্য এই সমস্যা সমাধানের জন্য ডিফল্টরূপে ইন্ট্রানেট পুনঃনির্দেশ ডিটেক্টর নিষ্ক্রিয় করা প্রয়োজন৷ আমাদের অবশ্যই ক্রোমিয়াম প্রকল্পকে ক্রেডিট দিতে হবে: বাগটি পাওয়া গেছে এর আগেকিভাবে Verisign এর ম্যাট থমাস তাকে তার সঙ্গে অনেক মনোযোগ এনেছে উপবাস APNIC ব্লগে। বাগটি জুন মাসে আবিষ্কৃত হয়েছিল, কিন্তু থমাসের পোস্ট পর্যন্ত বিস্মৃত ছিল; রোজা রাখার পর তিনি নিবিড় তত্ত্বাবধানে থাকতে শুরু করেন।

আশা করা যায় যে সমস্যাটি শীঘ্রই সমাধান করা হবে, এবং রুট ডিএনএস সার্ভারগুলিকে প্রতিদিন আনুমানিক 60 বিলিয়ন বোগাস প্রশ্নের উত্তর দিতে হবে না।

বিজ্ঞাপনের অধিকারগুলিতে

এপিক সার্ভার - এটা উইন্ডোজে ভিপিএস বা শক্তিশালী AMD EPYC ফ্যামিলি প্রসেসর এবং খুব দ্রুত ইন্টেল NVMe ড্রাইভ সহ লিনাক্স। অর্ডার করতে তাড়াতাড়ি করুন!

উত্স: www.habr.com