Nebula লাইটহাউস DNS: কে কোন রেকর্ড জিজ্ঞাসা করতে পারে?
ঐচ্ছিক লিসেনার লাইটহাউসের কাছে থাকা হোস্ট তথ্য থেকে উত্তর দেয়। A রেকর্ড ও TXT অনুসন্ধান পৌঁছানোর ক্ষমতা ও দর্শকশ্রেণিতে ভিন্ন, তাই এটিকে ইচ্ছাকৃতভাবে বাঁধুন।
Nebula-র লাইটহাউস ভূমিকা অনেক কাজ করে যা মানুষ স্বয়ংক্রিয় বলে ধরে নেয়, আর DNS-এ উত্তর দেওয়া তার একটি নয়। নাম পরিবেশন একটি ঐচ্ছিক লিসেনার যা বন্ধ অবস্থায় শুরু হয়, তাই যে হোস্ট ওভারলের ভিতরে নাম ভালোভাবে রিজলভ করে, তার কাছে সহকর্মীর ল্যাপটপ রিজলভ করার মতো কিছুই নাও থাকতে পারে। এটি চালু করার আগে ঠিক করুন কে এটিতে পৌঁছাবে এবং কোন ধরনের রেকর্ডের উত্তর দিতে আপনি রাজি, কারণ এই দুই উত্তর ভিন্ন।
লিসেনারটি ঐচ্ছিক এবং ডিফল্টে বন্ধ
ডিসকভারি ও DNS আলাদা সেবা। লাইটহাউস পিয়ারদের একে অপরকে খুঁজে পেতে সাহায্য করে, এবং অতিরিক্তভাবে যে হোস্টগুলো সে জানে সেগুলোর নাম-জিজ্ঞাসার উত্তর দিতে পারে, কিন্তু সেই দ্বিতীয় অংশটি কনফিগারেশনে স্পষ্টভাবে চালু করতে হয়।
কিছু সক্রিয় করার আগে ঠিক করুন কোন ইন্টারফেস ও নেটওয়ার্ক লিসেনারে পৌঁছাবে। যে DNS সেবা আপনি যে ইন্টারফেসে চাননি সেখানে উত্তর দেয়, সেটি ছোট তথ্য ফাঁসে পরিণত হয়, আর কেউ সেই লগ এন্ট্রি পড়ে না। সিদ্ধান্তটি এখন নেওয়া অনেক সস্তা, পরে সংকুচিত করার চেয়ে, যখন কিছু ভুল উত্তরের উপর নির্ভর করতে শুরু করে। দুই লাইন কনফিগারেশন ছয় মাস পরে একটি ঘটনার নোটের চেয়ে বোঝা সহজ।
A রেকর্ড ও TXT একই দর্শকশ্রেণি ভাগ করে না
এই দুই ধরনের রেকর্ড ভিন্ন শর্তে উত্তর দেওয়া হয়, আর তাদের একক সেবা হিসেবে বিবেচনা করাই সেই ভুল যা প্রতিরোধ করতে এই নিবন্ধ।
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
এই অসমতা ইচ্ছাকৃত, অবহেলা নয়। নাম-থেকে-ঠিকানা ম্যাপিং বাইরের কারও জন্য কম মূল্যবান, অন্যদিকে সার্টিফিকেট মেটাডেটা আপনার ওভারলের পরিচয়গুলো বর্ণনা করে। কেবল একই প্রক্রিয়া দুটোরই উত্তর দেয় বলে এক সারি থেকে অন্য সারিতে অনুমান বহন করবেন না।
এটি কেবল লাইটহাউসের নিজের হোস্ট সম্পর্কে উত্তর দেয়
এটি আপনার অফিস, ক্লাউড VPC বা পাবলিক ইন্টারনেটের জন্য সাধারণ রিজলভার নয়। লাইটহাউস তাকে দেওয়া হোস্ট তথ্য থেকে উত্তর দেয়, তাই বৈশিষ্ট্যটি প্রতিটি পিয়ারে নয়, লাইটহাউস নোডে থাকে।
যখন কোনো নাম ব্যর্থ হয় যার ওভারলের সঙ্গে কোনো সম্পর্ক নেই, তখন সেই জোন ও রিজলভার খুঁজুন যারা সত্যিই তার মালিক। হোস্টের সাধারণ DNS কনফিগারেশনে ওভারল রিজলভার মেশানো এলোমেলো দেখতে ব্যর্থতা তৈরি করে, কারণ কিছু নাম রিজলভ হয় আর অন্যগুলোর উত্তর কেউ দেয় না।
লক্ষ্য করুন বুটস্ট্র্যাপ এন্ডপয়েন্ট। প্রথম লাইটহাউসে পৌঁছাতে ব্যবহৃত হোস্টনামকে সাধারণ পথে রিজলভ হতে হয়, তার আগে ডিসকভারি তার উপর নির্ভর করতে পারে না, তাই এখানে মুরগি-ডিমের সমস্যা দেখতে ঠিক ভাঙা ওভারলের মতো। এটি একইভাবে রিপোর্টও করে: যে পিয়ার কখনো ওঠে না এবং কোনো স্পষ্ট কারণ নেই। সার্টিফিকেট স্পর্শ করার আগে নাম রিজলভিং পরীক্ষা করুন, কারণ এই ক্রমটি তাদের ধরে যারা কঠিন অর্ধেক দিয়ে শুরু করেছে।
বাইন্ড ঠিকানা যাচাই করুন, তারপর বাইরে থেকে পরীক্ষা করুন
lighthouse.dns.host এবং lighthouse.dns.port নির্ধারণ করে ঐচ্ছিক সেবাটি কোথায় শোনে। হোস্ট ফায়ারওয়াল ও নেটওয়ার্ক নীতির সঙ্গে এই মানগুলো পর্যালোচনা করুন, কারণ বাইন্ড ঠিকানা একটি উদ্দেশ্যের ঘোষণা, নিজে থেকে কোনো নিরাপত্তা নিয়ন্ত্রণ নয়।
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortযে নেটওয়ার্কগুলো আপনি অনুমোদন করতে চান সেখান থেকে কোয়েরি করুন, লাইটহাউসের নিজের থেকে নয়। লাইটহাউসে সফল অনুসন্ধান প্রমাণ করে প্রক্রিয়াটি চলছে, এবং বাইরের হোস্ট কী জিজ্ঞাসা করতে পারে সে বিষয়ে কিছুই বলে না, অথচ সেটাই আসল প্রশ্ন।
এটি উদ্দেশ্যমূলকভাবে প্রকাশ করুন
নাম ও সার্টিফিকেট মেটাডেটা উপকারী পরিচালন তথ্য, আর উপকারিতা দুই দিকেই কাটে। লিসেনারটি কেবল ওভারলের জন্য হবে কি না, কোন রেকর্ড ধরন অনুমোদিত হবে এবং কনফিগারেশন বদলালে কে পর্যালোচনা করবে তা ঠিক করুন।
তারপর লাইটহাউস সেটিংসের পাশে এটি লিখে রাখুন। পরের যে ব্যক্তি রিজলিউশন ব্যর্থতা ডিবাগ করবে সে অন্যথায় ধরে নেবে সেবাটি সবসময় সেখানেই ছিল। সে এও ধরে নেবে সেবাটি যেখানেই সে পরীক্ষা করছে সেখান থেকেই সবসময় পৌঁছানো যেত। বাইন্ড ঠিকানা, অনুমোদিত নেটওয়ার্ক ও রেকর্ড ধরন লিখে রাখা একটি অনুচ্ছেদ সেই ব্যক্তির একটি বিকেল বাঁচায় এবং কেন কিছু বদলাল তা জিজ্ঞাসা করা একটি বার্তা থেকে আপনাকে বাঁচায়।