নেমসার্ভার স্থানান্তরের পর সব কন্ট্রোল প্যানেলে কাজটি সফল দেখালেও ওয়েবসাইটে প্রবেশ করা অসম্ভব হয়ে পড়তে পারে। ডোমেইন সক্রিয়, নতুন অথরিটেটিভ নেমসার্ভারগুলো প্রত্যাশিত IP ঠিকানাই ফেরত দিচ্ছে, আর ওয়েব সার্ভারেও কোনো পরিবর্তন হয়নি। তবু DNSSEC যাচাইকারী DNS রিজলভারগুলো SERVFAIL জানাচ্ছে। এর পেছনে প্রায়ই থাকে এমন একটি DNSSEC ডেলিগেশন, যা এখনও আগের DNS সেবাদাতার সাইনিং কী-কে বিশ্বাস করছে।
এই অনুসন্ধানের পেছনের ঘটনায় সাধারণ DNS অনুসন্ধান ব্যর্থ হচ্ছিল, অথচ DNSSEC যাচাই এড়িয়ে একই প্রশ্ন করলে উত্তর পাওয়া যাচ্ছিল। প্যারেন্ট জোনে তখনও পুরোনো DS রেকর্ড প্রকাশিত ছিল, কিন্তু নতুন অথরিটেটিভ জোনটি প্রথমে স্বাক্ষরবিহীন ছিল। নতুন জোনের সঙ্গে মেলে এমন কী প্রকাশ করে সেটিতে স্বাক্ষর যুক্ত করার পর পরীক্ষিত রিজলভারগুলো আবার যাচাইকৃত উত্তর দিতে শুরু করে। মূল শিক্ষা DNSSEC বন্ধ করে দেওয়া নয়; নেমসার্ভার স্থানান্তর এবং DNSSEC-এর আস্থার শৃঙ্খল স্থানান্তর—এ দুটি আলাদা কাজ।
সঠিক A রেকর্ড থাকা সত্ত্বেও কেন SERVFAIL দেখা দিতে পারে
DNS দুটি ভিন্ন প্রশ্নের উত্তর দেয়। একটি A রেকর্ড জানায়, কোনো নামের সঙ্গে কোন IPv4 ঠিকানা যুক্ত। আর DNSSEC একটি যাচাইকারী রিজলভারকে জানায়, সেই উত্তর বিশ্বাসযোগ্য কি না। ঠিকানার তথ্য সঠিক হলেই DNSSEC-এর আস্থার শৃঙ্খল বৈধ হবে, এমন নয়।
DNSSEC-স্বাক্ষরিত ডোমেইনের ক্ষেত্রে এই শৃঙ্খল বিশ্বস্ত প্যারেন্ট জোন থেকে DS (Delegation Signer) রেকর্ড হয়ে চাইল্ড জোনের DNSKEY পর্যন্ত বিস্তৃত। চাইল্ড জোন তার DNS ডেটার জন্য RRSIG রেকর্ডে ডিজিটাল স্বাক্ষর প্রকাশ করে। DS রেকর্ডে অনুমোদিত DNSKEY শনাক্তকারী একটি ডাইজেস্ট থাকে; এটি A রেকর্ড নয়, প্রাইভেট কী-এর অনুলিপিও নয়, কিংবা সাধারণ জোন-ফাইল এডিটরের কোনো সেটিংও নয়।
অথরিটেটিভ নেমসার্ভার পরিবর্তনের পরও প্যারেন্ট জোন আগের সাইনিং কী-এর সঙ্গে সম্পর্কিত DS রেকর্ড প্রকাশ করতে পারে। নতুন জোনে সেই রেকর্ডের সঙ্গে মেলে এমন DNSKEY ও স্বাক্ষর না থাকলে DNSSEC যাচাইকারী রিজলভার আস্থার শৃঙ্খল সম্পূর্ণ করতে পারে না। সাধারণত সে উত্তরটিকে অবিশ্বস্ত বা bogus হিসেবে ধরে এবং যাচাই না করা ঠিকানা ফেরানোর বদলে SERVFAIL দেয়।
এটি HTTP পরিষেবা বন্ধ হয়ে যাওয়ার ঘটনা থেকে আলাদা। অনুরোধটি ওয়েব সার্ভার পর্যন্ত পৌঁছাতেই নাও পারে। মেয়াদোত্তীর্ণ TLS সার্টিফিকেটের সমস্যাও এটি নয়: DNSSEC DNS ডেটা যাচাই করে, আর HTTPS পরে ব্রাউজার ও সার্ভারের মধ্যে স্থাপিত সংযোগ সুরক্ষিত রাখে।
DNSSEC সমস্যা আর অনুপস্থিত রেকর্ডের মধ্যে পার্থক্য বোঝার পরীক্ষা
সবচেয়ে কার্যকর পরীক্ষায় একই রিজলভারের কাছে একই ডোমেইন সম্পর্কে দুবার প্রশ্ন করা হয়। প্রথমে স্বাভাবিক অনুসন্ধান চালিয়ে শুধু উত্তর নয়, স্ট্যাটাসও দেখুন:
dig example.com A +noall +comments +answerএরপর DNSSEC Checking Disabled (CD) বিট সেট করে একই অনুসন্ধান করুন:
dig example.com A +cdflag +noall +comments +answerপর্যবেক্ষিত ব্যর্থতার ক্ষেত্রে সাধারণ অনুসন্ধানে SERVFAIL এসেছিল, কিন্তু CD-সহ অনুসন্ধানে প্রত্যাশিত A রেকর্ড পাওয়া গিয়েছিল। এই পার্থক্য জোরালোভাবে ইঙ্গিত করেছিল যে সমস্যাটি অনুপস্থিত DNS রেকর্ড বা অচল অ্যাপ্লিকেশন নয়, বরং DNSSEC যাচাইয়ে। +cdflag অপশনটি সমর্থিত রিকার্সিভ রিজলভারকে ওই অনুরোধের জন্য তার স্বাভাবিক DNSSEC যাচাই না করতে বলে। এটি রোগনির্ণয়ের উপায়, ব্রাউজারে সমস্যা সারানোর পদ্ধতি নয়; এর মাধ্যমে দর্শকদের জন্য DNSSEC বন্ধও করা যায় না।
+short দিয়ে ফাঁকা ফল দেখেই সিদ্ধান্ত নেবেন না। কোনো উত্তর না থাকা এবং SERVFAIL—দুটিই ওই সংক্ষিপ্ত আউটপুটে ফাঁকা দেখাতে পারে। সমস্যা অনুসন্ধানের সময় +comments রাখুন, যাতে status: SERVFAIL ও status: NOERROR স্পষ্ট দেখা যায়।
শুধু CD-সহ ও CD-বিহীন ফলের তুলনা DNSSEC-এর ঠিক কোন অংশে ব্যর্থতা ঘটেছে, তা বলে না; এটি পরবর্তী তদন্তের দিক নির্দেশ করে। রিজলভারের আপস্ট্রিমেও সাময়িক ত্রুটি থাকতে পারে। তাই প্রয়োজনে পরীক্ষা আবার চালান এবং প্যারেন্ট ডেলিগেশন খতিয়ে দেখুন।
শুধু DNS এডিটর নয়, প্যারেন্ট জোনের DS রেকর্ডও পরীক্ষা করুন
ডোমেইনের জন্য DS রেকর্ড আছে কি না দেখুন:
dig example.com DS +noall +comments +answerডেলিগেশনের পুরো পথ আরও ভালোভাবে দেখতে সরাসরি DNS-এর স্তরক্রম অনুসরণ করে প্রশ্ন করুন:
dig +trace example.com DSসুনির্দিষ্ট অথরিটেটিভ প্যারেন্ট নেমসার্ভারটি টপ-লেভেল ডোমেইনের ওপর নির্ভর করে। গুরুত্বপূর্ণ হলো প্যারেন্ট জোনে প্রকাশিত DS রেকর্ডসমষ্টি (RRset), DNS হোস্টিং ড্যাশবোর্ডে দেখানো সারাংশ শুধু নয়। রেজিস্ট্রার বদলালেও নেমসার্ভার অপরিবর্তিত থাকতে পারে, আবার রেজিস্ট্রার না বদলিয়েও নেমসার্ভার পরিবর্তন করা যায়। উভয় ক্ষেত্রেই প্যারেন্টের DS রেকর্ড সক্রিয় অথরিটেটিভ জোনের সঙ্গে সামঞ্জস্যপূর্ণ হতে হবে।
একটি DS রেকর্ডে চারটি অর্থপূর্ণ ক্ষেত্র থাকে: কী ট্যাগ, অ্যালগরিদম, ডাইজেস্টের ধরন এবং ডাইজেস্ট। সমস্যার অনুসন্ধানে কী ট্যাগ সুবিধাজনক শনাক্তকারী, কিন্তু শুধু সেটি দিয়ে DNSKEY মিলে গেছে বলে প্রমাণ করা যায় না। ডাইজেস্ট এবং অ্যালগরিদমের তথ্যও অথরিটেটিভ জোনে সত্যিই সরবরাহ করা কোনো কী-এর সঙ্গে মিলতে হবে।
এই ঘটনার নির্ণায়ক অবস্থা ছিল সহজ: প্যারেন্ট জোন পুরোনো DNSSEC আস্থাসংক্রান্ত তথ্য প্রকাশ করছিল, অথচ নতুন অথরিটেটিভ জোনের ব্যবস্থাপনা প্যানেল জানাচ্ছিল যে স্বাক্ষর করার ব্যবস্থা নিষ্ক্রিয়। A রেকর্ডগুলো ছিল এবং যাচাই এড়ালে সেগুলো পাওয়াও যাচ্ছিল। অ্যাপ্লিকেশনের কনফিগারেশন বদলানো কিংবা একই A রেকর্ড বারবার সম্পাদনা করে এই অসামঞ্জস্য সারানো যেত না।
ভেঙে যাওয়া DNSSEC ডেলিগেশন পুনরুদ্ধারের দুটি উপায়
পুনরুদ্ধারের দুটি বৈধ কৌশল আছে। দুটিই আস্থার শৃঙ্খলের একই অসামঞ্জস্য দূর করে, কিন্তু পরিচালনাগত ফল আলাদা। সচেতনভাবে একটি বেছে নিন; এলোমেলোভাবে দুটির মধ্যে যাতায়াত করবেন না।
উপায় ১: পুরোনো DS সরিয়ে সাময়িকভাবে স্বাক্ষরবিহীন জোন চালানো
বর্তমান ডোমেইন রেজিস্ট্রারকে বা তার সমর্থিত DNSSEC ব্যবস্থাপনা ইন্টারফেসের মাধ্যমে প্যারেন্ট জোন থেকে পুরোনো DS রেকর্ড সরাতে বলুন। প্যারেন্ট আর নিরাপদ ডেলিগেশনের ঘোষণা না দিলে DNSSEC যাচাইকারী রিজলভার স্বাক্ষরবিহীন চাইল্ড জোনকে bogus না ধরে নিরাপত্তা-যাচাইবিহীন বা insecure হিসেবে গ্রহণ করতে পারে। এতে DNS কাজ চালিয়ে যায়, তবে ওই ডোমেইনের DNSSEC প্রমাণীকরণ সাময়িকভাবে থাকে না।
প্যারেন্টের DS রেকর্ডসমষ্টি পরিবর্তনের নির্ভরযোগ্য ব্যবস্থা থাকলে জরুরি অবস্থায় এটিই প্রায়ই সহজতর উপায়। রিকার্সিভ ক্যাশ থেকে পুরোনো DS-এর মেয়াদ শেষ না হওয়া পর্যন্ত বিদ্যমান সাইনিং কনফিগারেশন স্থিতিশীল রাখুন। শুধু কন্ট্রোল প্যানেল থেকে DS সরিয়ে দেওয়া হয়েছে দেখলেই নিশ্চিন্ত হবেন না: বাইরে থেকে প্যারেন্ট রেকর্ড যাচাই করুন এবং তার TTL শেষ হওয়ার সময় বিবেচনা করুন। HTTPS-এর কার্যক্রম DNSSEC সেটিংয়ের ওপর নির্ভরশীল নয়। সাময়িকভাবে স্বাক্ষরবিহীন অবস্থায় যাওয়ার এই পদ্ধতি RFC 8078-এও বর্ণিত আছে।
উপায় ২: নতুন জোনে স্বাক্ষর দিয়ে তার সঙ্গে মিলে এমন DS প্রকাশ করা
অন্য উপায় হলো নতুন অথরিটেটিভ DNS সেবাদাতার কাছে DNSSEC চালু করা, তার DNSKEY তৈরি করা, জোনে স্বাক্ষর দেওয়া এবং সংশ্লিষ্ট DS রেকর্ড প্যারেন্ট জোনে প্রকাশ করা। এরপর DNSSEC যাচাইকারী রিজলভার নতুন DNSKEY পর্যন্ত একটি বিশ্বস্ত পথ তৈরি করে A রেকর্ড যাচাই করতে পারে।
পর্যবেক্ষিত ঘটনায় এই পথেই পরিষেবা পুনরুদ্ধার হয়েছিল। DNS ব্যবস্থাপনা ইন্টারফেস জানিয়েছিল যে এটি কী তৈরি করেছে, জোনে স্বাক্ষর দিয়েছে এবং নতুন DS প্রকাশ করেছে। পরে প্যারেন্ট জোনের অনুসন্ধানে পুরোনো রেকর্ডের পাশাপাশি নতুন DS-ও দেখা যায়। DNSSEC যাচাইকারী রিকার্সিভ রিজলভারগুলো প্রত্যাশিত A রেকর্ড ফেরাতে শুরু করে; পরের একটি পরীক্ষায় ad ফ্ল্যাগসহ NOERROR পাওয়া যায়, যা ওই রিজলভারের দৃষ্টিতে ডেটা প্রমাণীকৃত হওয়ার ইঙ্গিত দেয়।
ধাপগুলোর ক্রম গুরুত্বপূর্ণ: সংশ্লিষ্ট DNSKEY ও বৈধ স্বাক্ষর অথরিটেটিভ DNS পরিষেবা থেকে আগে থেকেই পাওয়া না গেলে প্রকাশিত DS কোনো কাজে আসে না। কন্ট্রোল প্যানেলে “published” লেখা দেখা বাইরের যাচাইয়ের বিকল্প নয়। ক্যাশে থাকা DS, DNSKEY, RRSIG ও NS রেকর্ডের কারণে ভিন্ন রিজলভার ভিন্ন সময়ে স্বাভাবিক অবস্থায় ফিরতে পারে।
দুটি DS রেকর্ড থাকা সত্ত্বেও কেন সাইট অচল থাকেনি
একটি অপ্রত্যাশিত বিষয় ছিল: প্যারেন্ট জোনে সাময়িকভাবে একটি অপ্রচলিত DS ও একটি নতুন বৈধ DS—দুটিই ছিল, তবু DNSSEC যাচাই সফল হচ্ছিল। এতে কোনো বিরোধ নেই। কী পরিবর্তনের সময় যেমন ঘটে, একটি DS রেকর্ডসমষ্টিতে একাধিক রেকর্ড থাকতে পারে। DNSSEC যাচাইকারীর জন্য প্রতিটি DS-কে বর্তমানে ব্যবহারযোগ্য কী শনাক্ত করতে হবে না; উপযুক্ত কোনো একটি DS থেকে DNSKEY ও বৈধ স্বাক্ষর পর্যন্ত একটি বৈধ প্রমাণীকরণ পথ পেলেই যথেষ্ট। RFC 6840 স্পষ্ট করেছে, যাচাইকারীদের একটি বৈধ পথ পেলেই তা গ্রহণ করা উচিত।
তার মানে পুরোনো কী চিরকাল রেখে দেওয়া ভালো নয়। অপ্রচলিত DS পরিচালনায় বিভ্রান্তি বাড়ায়; নতুন আস্থার শৃঙ্খল যাচাই হয়ে গেলে শেষ পর্যন্ত সেটি সরিয়ে ফেলা উচিত। কিন্তু যাচাইকৃত DNS অনুসন্ধান ইতিমধ্যে সফল হলে তার পরিষ্কার-পরিচ্ছন্নতা রক্ষণাবেক্ষণের কাজ, আবার ঝুঁকিপূর্ণ DNSSEC রিসেট করার অজুহাত নয়।
এখানে কন্ট্রোল প্যানেলের একটি বিশেষ বিপজ্জনক ফাঁদ আছে: “emergency unpublish DS” নামের কাজটি নতুন কার্যকর DS-সহ সব DS রেকর্ড সরিয়ে দিতে পারে। একইভাবে প্যারেন্টে DS প্রকাশিত থাকা অবস্থায় জোনের সাইনিং বন্ধ করলে সঙ্গে সঙ্গে আবার বিভ্রাট ঘটতে পারে। এই কাজগুলোর কোনোটিই নির্দিষ্ট একটি অপ্রচলিত DS রেকর্ড মুছে দেওয়ার সমান নয়। ইন্টারফেসে পৃথক রেকর্ড বেছে নেওয়া না গেলে সব মুছে দেওয়ার বদলে রেজিস্ট্রার-সমর্থিত নির্দিষ্ট রেকর্ড পরিবর্তনের পদ্ধতি ব্যবহার করুন।
অথরিটেটিভ নেমসার্ভার নিরাপদে পরিবর্তনের পদ্ধতি
সবচেয়ে নিরাপদ ক্রমটি নির্ভর করে পুরোনো ও নতুন DNS সেবাদাতা কী ব্যবস্থাপনা সমন্বয় করতে পারে কি না তার ওপর। সাময়িক স্বাক্ষরবিহীন পর্যায় ব্যবহার করে প্রচলিত ধরনের স্থানান্তরে নিচের ক্রম অনুসরণ করলে এই ঘটনায় দেখা অসামঞ্জস্য এড়ানো যায়:
- আগে গন্তব্য জোন প্রস্তুত করুন। প্রয়োজনীয় A, AAAA, CNAME, MX, TXT এবং অন্যান্য প্রাসঙ্গিক রেকর্ড কপি করুন। ডেলিগেশন বদলানোর আগে নতুন অথরিটেটিভ নেমসার্ভারগুলোতে সরাসরি পরীক্ষা চালান।
- প্যারেন্ট জোনে DNSSEC-এর অবস্থা পরীক্ষা করুন। DS রেকর্ড আছে কি না দেখুন এবং কে সেগুলো পরিবর্তন করতে পারবে তা নির্ধারণ করুন। আপনি নিজে কখনো DNSSEC চালু না করলেও এটি করুন; কিছু DNS পরিষেবা স্বয়ংক্রিয়ভাবে স্বাক্ষর যোগ করে।
- পুরোনো স্বাক্ষরিত জোন চালু থাকা অবস্থাতেই পুরোনো DS সরান। অথরিটেটিভ প্যারেন্ট জোনে পরিবর্তনটি নিশ্চিত করুন। এরপর আগের ক্যাশে থাকা DS তথ্যের মেয়াদ শেষ হওয়ার জন্য যথেষ্ট সময় অপেক্ষা করুন। অপেক্ষার সময় পর্যবেক্ষিত TTL অনুযায়ী নির্ধারিত হবে, সবার জন্য নির্দিষ্ট কোনো মিনিটের সংখ্যা অনুযায়ী নয়।
- নেমসার্ভারের ডেলিগেশন পরিবর্তন করুন। ক্যাশে থাকা NS ডেলিগেশনের কারণে পুরোনো নেমসার্ভারে অনুরোধ যেতে পারে, তাই সেই অথরিটেটিভ পরিষেবাটি চালু রাখুন। প্যারেন্টের NS TTL বিবেচনা করুন এবং বিভিন্ন রিজলভার আসলে কোন সার্ভার ব্যবহার করছে তা যাচাই করুন।
- DNSSEC আবার চালু করবেন কি না ঠিক করুন। নতুন পরিষেবা স্বাক্ষরবিহীন রাখতে চাইলে DS প্রকাশ করবেন না। স্বাক্ষরিত রাখতে চাইলে সংশ্লিষ্ট DS প্রকাশের আগে নতুন DNSKEY ও স্বাক্ষর ঠিকমতো সরবরাহ করা হচ্ছে কি না যাচাই করুন। পুরোনো NS-এর ক্যাশে থাকা ডেলিগেশনও বিবেচনায় রেখে সমন্বয় করুন, যাতে নতুন করে যাচাইয়ের অসামঞ্জস্য না হয়।
- স্বতন্ত্রভাবে যাচাই করুন। প্যারেন্টের DS, অথরিটেটিভ DNSKEY, সাধারণ রিকার্সিভ DNS উত্তর এবং DNSSEC যাচাইকারী রিজলভারের প্রমাণীকৃত-ডেটা ফল পরীক্ষা করুন।
DNSSEC-এর সুরক্ষা একটানা বজায় রাখা জরুরি হলে সাময়িক স্বাক্ষরবিহীন পর্যায়ের বদলে সমন্বিত কী রোলওভার বা মাল্টি-সাইনার স্থানান্তরই ভালো। এর জন্য উভয় DNS সেবাদাতার প্রয়োজনীয় কী ও সাইনিং ব্যবস্থা সমর্থন করতে হবে; পুরোনো DS ডাইজেস্ট শুধু নতুন সেবাদাতার কাছে কপি করলেই কী রোলওভার হয় না।
স্থানান্তরের পর যাচাইয়ের সংক্ষিপ্ত তালিকা
DNSSEC-সংক্রান্ত যেকোনো পরিবর্তনের পরে DNS রেকর্ড এবং রিজলভার সেই রেকর্ডগুলোর প্রমাণ গ্রহণ করছে কি না—দুটিই পরীক্ষা করুন:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerপ্রমাণীকৃত উত্তর যাচাই করতে DNSSEC যাচাইকারী রিকার্সিভ রিজলভার ব্যবহার করুন। তার উত্তরে NOERROR এবং প্রত্যাশিত A রেকর্ড থাকলে নাম সমাধান সফল হয়েছে। অতিরিক্ত ad ফ্ল্যাগ থাকলে বোঝায় যে রিজলভার তার DNSSEC নীতি অনুযায়ী উত্তরটি প্রমাণীকৃত বলে জানিয়েছে। শুধু ad ফ্ল্যাগ অনুপস্থিত থাকাই ব্যর্থতার প্রমাণ নয়; রিজলভারের সক্ষমতা, নীতি এবং অনুসন্ধানের ফ্ল্যাগ ভিন্ন হতে পারে। বিভ্রাট চলাকালে যাচাইকারী রিজলভারের মাধ্যমে DNSKEY অনুসন্ধান ব্যর্থ হলে তদন্তের অংশ হিসেবে সক্রিয় অথরিটেটিভ DNS পরিষেবাকে সরাসরি প্রশ্ন করুন।
একটি রিজলভার সফল উত্তর দিলেই থেমে যাবেন না। বিভিন্ন ক্যাশে সাময়িকভাবে ভিন্ন ডেলিগেশন ও কী থাকতে পারে। চলমান পরিচালনাগত সহায়তার অনুরোধও হালনাগাদ করুন: নতুন কার্যকর DS প্রকাশের পরে আগে দেওয়া সব DS সরানোর নির্দেশ বিপজ্জনক হয়ে যায়। পরবর্তী বার্তায় সক্রিয় কী অক্ষত রাখার কথা স্পষ্ট করুন এবং প্রয়োজন হলে শুধু অপ্রচলিত রেকর্ডটি সরাতে বলুন।
সমস্যাটি ওয়েব সার্ভারের ভুল ঠিকানার কারণে ঘটেনি। DNS উত্তর কোথা থেকে দেওয়া হবে তা বদলানো হয়েছিল, কিন্তু কোন উত্তরকে বিশ্বাস করতে হবে সে বিষয়ে রিজলভারকে নির্দেশ দেওয়া আস্থার তথ্য আগে সামঞ্জস্যপূর্ণ করা হয়নি। তাই প্রতিবার নেমসার্ভার পরিবর্তনের আগে জরুরি প্রশ্ন হলো: প্যারেন্ট জোন কোন DS রেকর্ডগুলো প্রকাশ করছে এবং গন্তব্য জোনের DNSKEY ও স্বাক্ষর কি সেগুলোর শর্ত পূরণ করবে?