কেন একটি ব্যক্তিগত Route 53 জোন পাবলিক নামের জন্য NXDOMAIN ফেরায়

ব্যক্তিগত Route 53 জোন পাবলিক রেকর্ডের সঙ্গে মিলিত না হয়ে নামের উত্তরটি প্রতিস্থাপন করে, আর ঠিক সেই কারণেই সবচেয়ে খারাপ মুহূর্তে মানুষ অবাক হয়। একটি অভ্যন্তরীণ রেকর্ড যোগ করুন api.example.net এর জন্য একটি ব্যক্তিগত জোনে example.net, এটি একটি VPC-এর সঙ্গে যুক্ত করুন, এবং সেই প্যারেন্টের অধীনে থাকা অন্য প্রতিটি নাম এখন কেবল ব্যক্তিগত জোন থেকেই উত্তর পায়। যে ক্লায়েন্ট গতকাল www.example.net -এ পৌঁছাতে পারত, আজ সে নেতিবাচক উত্তর পায়। নিচের আলোচনা সেই ব্যর্থ কোয়েরি থেকেই শুরু হয় এবং যে জোন উত্তর দিয়েছিল তার দিকে এগোয়।

কনসোল থেকে নয়, কোয়েরি থেকেই শুরু করুন

যে ক্লায়েন্ট সমস্যাটি জানিয়েছে তার কাছেই ব্যর্থতাটি পুনরুৎপাদন করুন এবং সঠিক নাম ও রেকর্ডের ধরন লিখে রাখুন। যে নামটি A -এর জন্য ব্যর্থ হয়, সেটি AAAA -এর জন্য এখনও সমাধান হতে পারে, আর ক্যাশ করা নাম আবার চাওয়া একটি ব্রাউজার কোনটি ভেঙেছে তা ঢেকে রাখে। কোয়েরিটি দুবার চালান: একবার ক্লায়েন্ট যে রিজলভার সত্যিই ব্যবহার করে তার মাধ্যমে, আর একবার তা এড়িয়ে যাওয়া ট্রেসিং দিয়ে।

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

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

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

কোন জোন উত্তর দিয়েছে তা পড়ুন

যে উত্তরটি NXDOMAIN বহন করে এবং authority অংশে ব্যক্তিগত জোনের SOA রাখে, সেটি ওই জোনেরই চূড়ান্ত উত্তর, ব্যর্থ লুকআপ নয়। Route 53 Resolver ব্যক্তিগত হোস্টেড জোনটি বেছে নিয়েছিল কারণ এর নাম মিলেছিল, তারপর চাওয়া ধরনের কোনো রেকর্ড পায়নি, আর নথিভুক্ত আচরণ হল প্রশ্নটি পাবলিক DNS-এ পাঠানোর বদলে নেতিবাচক উত্তরটি ফেরানো।

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

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

দুটি কমান্ডেরই জোনের মালিক অ্যাকাউন্টের ক্রেডেনশিয়াল দরকার, আর দ্বিতীয়টির জন্য প্রথমটি থেকে জোন আইডি দরকার। এটির জায়গায় নিজের আইডি বসান; উপরের প্লেসহোল্ডারটি ইচ্ছাকৃতভাবেই আসল নয়।

ব্যক্তিগত জোনই কেন জেতে

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

ওভারল্যাপিং নেমস্পেস বিভ্রান্তির দ্বিতীয় উৎস। example.net -এর জন্য ব্যক্তিগত জোন এবং api.example.net -এর জন্য ব্যক্তিগত জোন দুটিই একটি API কোয়েরির সঙ্গে মেলে, আর উত্তর দেয় বেশি নির্দিষ্টটি। এটি উপকারী যখন আপনি সংকীর্ণ অভ্যন্তরীণ নেমস্পেস চান, এবং বিপজ্জনক যখন সংকীর্ণ জোনে এমন রেকর্ড নেই যা বিস্তৃত জোনে আছে। ব্যক্তিগত হোস্টেড জোনের বিবেচনাগুলো Route 53 ডকুমেন্টেশনে নিচের দিকে গড়িয়ে পড়ার আচরণ ও নিয়মের অগ্রাধিকার দুটিই বর্ণনা করে, এবং দ্বিতীয় একটি ওভারল্যাপিং জোন যোগ করার আগে সেগুলো পড়া উচিত।

এর কোনোটিই পাবলিক জোন বদলায় না। পাবলিক রিজলভারগুলো এখনও পাবলিক রেকর্ডের সঠিক উত্তর দেয়, আর তাই VPC-র বাইরের সবার কাছে ব্যর্থতাটি ক্লায়েন্টের সমস্যা মনে হয়।

রেকর্ড যোগ করার আগে নেমস্পেস বেছে নিন

যদি কেবল অভ্যন্তরীণ সেবার একটি নতুন পরিবারের ব্যক্তিগত নাম দরকার হয়, তবে তাকে একটি নিবেদিত ব্যক্তিগত সাবডোমেইন দিন এবং পাবলিক প্যারেন্টকে অক্ষত রাখুন। internal.example.net -এর মতো একটি নাম www.example.net -কে ছায়া দিতে পারে না, আর অনুপস্থিত রেকর্ডের ক্ষতির পরিধি সীমিত থাকে সেই নামগুলোতে যা আপনি এ কাজের জন্য বানিয়েছেন। খরচটি হল বিদ্যমান URL ও সার্টিফিকেট নতুন নামের সঙ্গে না মিলতে পারে।

যখন পাবলিক ও ব্যক্তিগত ব্যবহারকারীদের একই হোস্টনেম রাখতে হয়, তখন split-view DNS-ই সমর্থিত নকশা এবং এতে প্রতিটি ভিউতে রেকর্ডগুলো স্পষ্টভাবে রক্ষণাবেক্ষণ করতে হয়। একটিমাত্র রেকর্ড থাকা বিস্তৃত ব্যক্তিগত জোন সেই জোনের নিচের পাবলিক নির্ভরতাগুলো রক্ষা করে না; বরং একটি রেকর্ডওয়ালা জোন দিয়ে সেগুলো প্রতিস্থাপন করে।

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

রিজলভারের পথ, তারপর রুট অনুসরণ করুন

ল্যাপটপ ব্যক্তিগত ভিউ দেখে কেবল তখনই যখন তার কোয়েরি সংযুক্তি থাকা রিজলভারে পৌঁছায়। VPN সার্ভারে hosts ফাইল সম্পাদনা করলে সংযুক্ত ক্লায়েন্টদের কাছে কিছুই প্রকাশ হয় না, আর পাবলিক রিজলভার দিয়ে সাজানো ক্লায়েন্ট টানেল চালু থাকা অবস্থায় পাবলিক উত্তরই পেতে থাকে। ক্লায়েন্ট যে রিজলভার ঠিকানা পেয়েছে তা নিশ্চিত করুন, তারপর সার্ভার থেকে নয়, ক্লায়েন্ট থেকেই কোয়েরি পুনরাবৃত্তি করুন।

নামটি সমাধান হওয়ার পর, ফেরত আসা ঠিকানার পথটি আলাদা ধাপ হিসেবে পরীক্ষা করুন, যেমন ip route get দিয়ে কোয়েরি যে ঠিকানা ফেরিয়েছে তার বিরুদ্ধে। ঠিকানার রুট ছাড়া সঠিক ব্যক্তিগত উত্তর একটি রাউটিং সমস্যা, আর রেকর্ড নেই বলে উত্তর দেওয়া একটি DNS-ভিউ সমস্যা; দুটিকে এক সমস্যা ভাবলে যে সমাধান আসে তা টেকে না। সেবার TLS হোস্টনেম ও সার্টিফিকেট যাচাই অপরিবর্তিত রাখুন, কারণ ব্যক্তিগত ঠিকানা বদলায় সংযোগ কোথায় যায়, কোন সার্টিফিকেট বৈধ তা নয়।

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