কেন একটি SRV রেকর্ড কেবল সেই ক্লায়েন্টকে সাহায্য করে যে নিজেই এটি খোঁজে

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

যে রেকর্ড কেউ খোঁজে না তা কাউকেই সাহায্য করতে পারে না

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

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

লেখার আগে ফিল্ডগুলো পড়ুন

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

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

ক্লায়েন্ট সত্যিই যে লেবেল পাঠায় তা খুঁজুন

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

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

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

টার্গেটও থাকতে হবে

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

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

ডিসকভারি মানে প্রমাণীকরণ নয়

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

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