দুটি সাইট, একটি ব্যক্তিগত DNS জোন: রেকর্ডের মালিক কে?

আপনি সবুজ সাইটে একটি হোস্ট যোগ করেন, এটি সবুজ ব্যবহারকারীদের জন্য রিজলভ হয়, আর হলুদ অফিস এখনও NXDOMAIN পায়। এটি VPN-এর ব্যর্থতা নয়, ভাঙা রিজলভারও নয়; এটি ব্যক্তিগত জোনে মালিকানার শূন্যতা। দুটি আলাদাভাবে সম্পাদিত রেকর্ড তালিকা কেবল সাইটগুলো একে অপরকে পৌঁছাতে পারে বলে একটি জোন হয়ে যায় না। সমাধান হলো প্রকাশনা পরিকল্পনা, আরেকটি ফায়ারওয়াল নিয়ম নয়।

লক্ষণটিই অনুপস্থিত মালিকের নাম বলে দেয়

সম্ভবত প্রতিটি সাইটে একটি স্থানীয় ওভাররাইড, একটি Pi-hole এন্ট্রি বা একটি dnsmasq লাইন আছে যা কেউ নাম দরকার হলে যোগ করেছিল। সবুজ রেকর্ড শুধু সবুজ রিজলভারে আছে, তাই হলুদে থাকা ক্লায়েন্ট নিজের রিজলভারকে জিজ্ঞাসা করে সত্যিকারের "এমন কোনো নাম নেই" উত্তর পায়। পুরোনো উত্তর দেখতে আলাদা: হোস্ট সরে গেছে, একটি সাইট নিজের অনুলিপি হালনাগাদ করেছে, আর অন্যটি এখনও পুরোনো ঠিকানা ফেরত দেয়।

ক্যাশে ফ্লাশ করে কোনো প্যাটার্নই দীর্ঘস্থায়ীভাবে ঠিক হয় না। ফরওয়ার্ডিং রিজলভারের ক্যাশে হলো একবার পাওয়া উত্তরের অনুলিপি, নতুন নাম প্রকাশকারী কর্তৃত্ব নয়, তাই আজ কাজ করা ক্যাশে আগামীকালের হোস্ট সম্পর্কে কিছুই বলে না। BIND ডকুমেন্টেশন ঠিক এই কারণেই প্রাইমারি, সেকেন্ডারি, রিকার্সিভ ও ফরওয়ার্ডিং ভূমিকা আলাদাভাবে বর্ণনা করে।

তাই নকশার প্রশ্নটি সংকীর্ণ ও উত্তরযোগ্য: কে রেকর্ড তৈরি করতে পারে, এবং সেই রেকর্ড কীভাবে প্রতিটি রিজলভারে পৌঁছায় যাকে তার জন্য উত্তর দিতে হবে?

বিকল্প A: সেকেন্ডারিসহ একটি কর্তৃত্বমূলক জোন

internal.example.com-এর জন্য একটি প্রাইমারি চালান এবং সমর্থিত সেকেন্ডারিদের প্রতিটি সাইটে জোনটি নিতে দিন। প্রতিটি সাইটের রিকার্সিভ রিজলভার নিজের স্থানীয় সেকেন্ডারিকে জিজ্ঞাসা করে, তাই উত্তর ক্যাশে থেকে নয়, কর্তৃত্বমূলক উৎস থেকে আসে, আর একবার করা পরিবর্তন আবার টাইপ না করে স্থানান্তরিত হয়।

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

জোন স্থানান্তর ঠিকানা অনুযায়ী পরিচিত সেকেন্ডারিতে সীমাবদ্ধ রাখুন এবং বাস্তবায়ন যেখানে সমর্থন করে সেখানে লেনদেন স্বাক্ষর ব্যবহার করুন। খোলা স্থানান্তর মানে পোর্টে পৌঁছাতে পারে এমন যে কারোর জন্য আপনার অভ্যন্তরীণ নেমস্পেসের একটি অনুলিপি।

খরচ হলো সমন্বয়: একটি সম্পাদনা পথ, একটি পরিবর্তন পর্যালোচনা, এবং রেকর্ড ভুল হলে কে দায়িত্বে থাকে সে সম্পর্কে যৌথ বোঝাপড়া।

বিকল্প B: প্রতিটি সাইটের জন্য একটি সাবডোমেইন

সবুজ সাইটকে green.internal.example.com এবং হলুদ সাইটকে yellow.internal.example.com প্রতিনিধিত্ব করুন। প্রতিটি সাইট নিজের নামের জন্য কর্তৃত্বমূলক হয়ে ওঠে, আর মূল জোন কেবল প্রতিনিধিত্বের রেকর্ড বহন করে। একটি ফাইলের জন্য প্রতিদ্বন্দ্বিতা মিলিয়ে যায়, এবং স্থানীয় দল কেন্দ্রীয় পরিবর্তনের অপেক্ষা না করেই হোস্ট যোগ করতে পারে।

প্রতিনিধিত্ব মূল জোনে থাকতে হবে, NS রেকর্ড দিয়ে যা সাইটের কর্তৃত্বমূলক সার্ভারগুলোকে নির্দেশ করে। পূর্ণ প্রতিনিধিত্ব অকার্যকর হলে সাবডোমেইনের জন্য শর্তসাপেক্ষ ফরওয়ার্ড একটি বৈধ বিকল্প, তবে এটি রিজলভার সেটিং, প্রকাশিত সত্য নয়, তাই প্রতিটি রিজলভারের একই নিয়ম দরকার।

খরচ সরিয়ে যায় না, স্থান বদলায়: মূল জোনের এখনও একজন মালিক দরকার, আর নতুন সাইট তৈরি এখন এক জায়গার বদলে দুই জায়গায় পরিবর্তন।

প্রতিটি রিজলভারকে পছন্দটি অনুসরণ করান

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

Pi-hole স্থানীয় রিজলিউশন দিলে লিখে রাখুন কোন রেকর্ডগুলো তার মালিকানাধীন এবং কোন কোয়েরিগুলো সে ফরওয়ার্ড করে। দুটি আলাদাভাবে সম্পাদিত Pi-hole তালিকা এখনও প্রতিলিপি হয় না। Pi-hole v6-এ কাস্টম dnsmasq লাইন হোস্ট-সাইড অপশন যেমন TOML, CLI বা পরিবেশ চলক দিয়ে সেট করা হয় এবং API-এর মাধ্যমে প্রকাশ করা হয় না; /etc/dnsmasq.d/ ফাইল লোড করা আলাদা অপশন যা ডিফল্টে বন্ধ।

তারপর সর্বত্র দৃশ্যমান হওয়া উচিত এমন একটি নাম দিয়ে দুই দিক থেকেই পরীক্ষা করুন:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA উত্তর আপনাকে বলে হলুদ রিজলভার নিজেকে কর্তৃত্বমূলক ভাবে কি না, সেকেন্ডারিকে জিজ্ঞাসা করছে কি না, নাকি শুধু ফরওয়ার্ড করছে। এগুলো ভিন্ন ব্যর্থতার ধরনসহ ভিন্ন নকশা, আর উত্তর সাধারণত চিহ্নিত করে আপনি আসলে কোনটি মোতায়েন করেছেন।

তিনটি গ্রহণযোগ্যতার ক্ষেত্রে শেষ করুন: প্রতিটি সাইট থেকে একটি নাম, এক ঘণ্টার মধ্যে পরিবর্তিত একটি রেকর্ড, এবং সাইটগুলোর মধ্যের সংযোগ অনুপলব্ধ। যে নকশা কেবল প্রথমটি পাস করে, তার কাগজে প্রকাশনা পরিকল্পনা আছে আর উৎপাদনে স্থানীয় ওভাররাইড আছে।