VPN-এ BIND: কন্ডিশনাল ফরওয়ার্ড না স্টাব জোন?
VPN দিয়ে একটি প্রাইভেট জোন সমাধানের তিনটি উপায় এবং কোনটির জন্য কোনটি: ফরওয়ার্ড, স্টাব বা সেকেন্ডারি, সঙ্গে সোর্স-অ্যাড্রেস পরীক্ষা যা সিদ্ধান্ত দেয়।
আপনার অফিসের রেজলভার একটি কর্পোরেট নেমস্পেস ছাড়া সব কিছুর উত্তর দেয়, আর যে কর্পোরেট DNS সার্ভার সেটি জানে তা VPN-এর পেছনে আছে। BIND সেই একক জোন তিনটি ভিন্ন উপায়ে আপস্ট্রিমের হাতে দিতে পারে, এবং তারা ভিন্নভাবে ব্যর্থ হয়। কন্ডিশনাল ফরওয়ার্ড সবচেয়ে ছোট প্রতিশ্রুতি, স্টাব জোন ডেলিগেশন ডেটা রাখে, আর সেকেন্ডারি পূর্ণ কপি রাখে। আপনার রেজলভার কী রাখবে এবং আপস্ট্রিম কী অনুমতি দেবে তার ভিত্তিতে বেছে নিন, আপনি আগে কোন স্নিপেট পেয়েছেন তার ভিত্তিতে নয়।
একটি নেমস্পেসের জন্য তিনটি ব্যবস্থা
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
কন্ডিশনাল ফরওয়ার্ড: সবচেয়ে ছোট প্রতিশ্রুতি
ধরুন, একটি অফিস রেজলভার 192.168.10.53-এ এবং একটি কর্পোরেট সার্ভার 10.40.0.53-এ, যা অনুমোদিত টানেল দিয়ে পৌঁছানো যায়। ঘোষণাটি তিন লাইনের, আর আকর্ষণীয়টি হল forward only, কারণ এটি পথ নয়, ব্যর্থতার আচরণ বদলায়।
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};forward only থাকলে অপ্রাপ্য আপস্ট্রিম এই জোনের জন্য পুনরাবৃত্তিমূলক সমাধানে ফেরার বদলে SERVFAIL দেয়। একটি প্রাইভেট নেমস্পেসের জন্য সাধারণত এটাই চান, কারণ ফেরা প্রাইভেট নামগুলিকে পাবলিক রেজলভারে পাঠাত এবং ইন্টারনেট থেকে অকেজো উত্তর ফিরিয়ে আনত। BIND রেফারেন্স উভয় নীতিই নথিভুক্ত করে, আর পার্থক্যটি স্নিপেট যতটা বোঝায় তার চেয়ে বেশি গুরুত্বপূর্ণ। একই নামের জন্য ইতিমধ্যে থাকা জোন প্রতিস্থাপন না করে জোনটিকে বিদ্যমান কনফিগারেশনে একীভূত করুন।
স্টাব বা সেকেন্ডারি: কখন ডেলিগেশন গুরুত্বপূর্ণ
একটি স্টাব জোন কর্পোরেট সার্ভারের কাছে জোনের NS রেকর্ড চায় এবং তারপর সরাসরি অথরিটেটিভ সার্ভারগুলিকে জিজ্ঞাসা করে। এটি বেছে নিন যখন আপস্ট্রিম অঞ্চল বড় বা উপবিভক্ত এবং আপনি চান আপনার রেজলভার সবকিছু একটি ঠিকানায় পিন না করে ডেলিগেশন অনুসরণ করুক। মূল্য হল NS ডেটা হালনাগাদ থাকার উপর নির্ভরতা, এবং তালিকাভুক্ত প্রতিটি নেমসার্ভার আপনার রেজলভারের সোর্স অ্যাড্রেস থেকে পৌঁছানোর যোগ্য হওয়ার উপর নির্ভরতা।
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};একটি সেকেন্ডারি স্থানীয় ডেটা থেকে উত্তর দেয় এবং আপস্ট্রিম বিভ্রাটও কাটিয়ে ওঠে, এজন্যই ট্রান্সফার নির্ভরতা মেনে নেওয়া যায়। এর মানে আপনার রেজলভার এখন এমন একটি জোনের কপি রাখে যা তার নয়, তাই ফাইল পাথ, প্রাইমারিতে ট্রান্সফার ACL এবং রিফ্রেশ টাইমার সবই আপনার পরিচালন পৃষ্ঠের অংশ হয়ে যায়।
যে পরীক্ষা এদের মধ্যে সিদ্ধান্ত দেয়
BIND নিজের আউটবাউন্ড কোয়েরি তৈরি করে, তাই প্রশ্নটি ল্যাপটপ 10.40.0.53-এ পৌঁছাতে পারে কি না নয়, বরং রেজলভার হোস্টটি কর্পোরেট সার্ভার যে সোর্স অ্যাড্রেস দেখবে সেখান থেকে পৌঁছাতে পারে কি না। আগে কার্নেলকে জিজ্ঞাসা করুন, তারপর সার্ভারকে, সেই ক্রমে।
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleপথে UDP ও TCP অনুমোদন করুন: ছোট করা উত্তর TCP বাধ্য করে, এবং শুধু UDP অনুমোদনকারী নীতি মাঝে মাঝে ব্যর্থতা তৈরি করে যা প্যাকেট ক্ষতির মতো দেখায়। কর্পোরেট পক্ষের আপনার রেজলভারের সোর্সের জন্য অনুমোদন নিয়ম এবং সেখানে ফেরার রুট, দুটোই দরকার; সেই সোর্স হতে পারে রেজলভারের রাউটেড অ্যাড্রেস বা স্পষ্টভাবে অনুবাদ করা একটি, এবং এটি বিরলভাবে ক্লায়েন্ট পুলের অ্যাড্রেস। NS কোয়েরি ব্যর্থ হলে ফরওয়ার্ড জোন যেমনই আচরণ করুক, স্টাব জোন কাজ করতে পারে না।
টানেল নয়, উত্তর যাচাই করুন
অফিস রেজলভার দিয়ে এমন একটি নামের জন্য কোয়েরি করুন যা আপনি কখনো চাননি, এবং উত্তরের authority অংশ দেখে বুঝুন তা কর্পোরেট জোন থেকে এসেছে কি না। ক্যাশে করা উত্তর বর্তমান পথ সম্পর্কে কিছু প্রমাণ করে না, আর আপস্ট্রিমে সরাসরি সফল কোয়েরি প্রমাণ করে না যে আপনার রেজলভার সেই জোন বেছে নিয়েছে। একই কোয়েরি TCP-তে পুনরাবৃত্তি করুন যাতে নিশ্চিত হন পথটি সংক্ষিপ্তকরণ সহ্য করে।
ক্লায়েন্টদের অফিস রেজলভারের দিকে রাখুন, এবং DNSSEC যাচাই চালু রাখুন। স্বাধীন এনক্রিপ্টেড রেজলভার দিয়ে কনফিগার করা ব্রাউজার এই ব্যবস্থা সম্পূর্ণ এড়িয়ে যায়, আর অপ্রত্যাশিত উত্তর সঠিক দেখানোর জন্য যাচাই বন্ধ করা দৃশ্যমান ব্যর্থতাকে অদৃশ্য ব্যর্থতায় বদলায়।
তিনটির মধ্যে কোনটি বেছে নিলেন এবং কেন তা লিখে রাখুন। পরের যে ব্যক্তি জোনটি ব্যর্থ হতে দেখবে তার কনফিগ ফাইলের চেয়ে সেই বাক্যটি বেশি দরকার হবে।