Cloudflare DNSSEC migration—পুরোনো DS record রাখলেই domain ভাঙতে পারে

পুরোনো সরবরাহকারীর DS রেকর্ড রেখে Cloudflare-এর নেমসার্ভারে ডোমেইন সরালে DNSSEC যাচাই ব্যর্থ হতে পারে। Cloudflare-এর DNSSEC নির্দেশনা অনুযায়ী, পুরোনো DS রিজলভারের ক্যাশে থাকা অবস্থায় নতুন নেমসার্ভারে গেলে সেটি Cloudflare-এর কীর সঙ্গে না মেলায় যাচাইকারী রিজলভার SERVFAIL ফেরাতে পারে। সাধারণ মাইগ্রেশনে তাই রেজিস্ট্রার থেকে পুরোনো DS সরিয়ে তার ক্যাশের মেয়াদ পার হওয়ার পর নেমসার্ভার বদলান; নতুন DS প্রকাশ করুন পুরোনো নেমসার্ভারের ক্যাশের মেয়াদও পার হলে।

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

পুরোনো DS থাকলে যাচাই কেন থামে

DS রেকর্ড ডোমেইনের মাতৃ জোনে থাকে এবং অধীন জোনের কী স্বাক্ষরকারী কী, অর্থাৎ KSK-এর সঙ্গে আস্থার যোগ তৈরি করে। ICANN-এর DNSSEC নির্দেশিকা ব্যাখ্যা করে, রেজিস্ট্রারের মাধ্যমে DS মাতৃ জোনে প্রকাশিত হয় এবং স্বাক্ষর যাচাই প্রধানত রিকার্সিভ রিজলভারে ঘটে। ফলে কর্তৃত্বপূর্ণ নেমসার্ভার উত্তর দিলেও যাচাইকারী রিজলভার আস্থার শৃঙ্খল মেলাতে না পারলে ব্যবহারকারী সেই উত্তর পাবেন না।

পুরোনো DS যদি পুরোনো সরবরাহকারীর KSK-কে নির্দেশ করে, Cloudflare-এর ভিন্ন KSK দিয়ে স্বাক্ষরিত জোনের সঙ্গে তার মিল হবে না। ব্যর্থতা ঘটে DNS উত্তর যাচাইয়ের পর্যায়ে; ওয়েব সার্ভার সচল থাকলেও ডোমেইনের নাম থেকে ঠিকানা পাওয়া আটকে যেতে পারে। আবার কোনো ব্রাউজারে সাইট খুললেই পরিবর্তন সম্পূর্ণ হয়েছে বোঝা যায় না। সেই ব্যবহারকারীর রিজলভার হয়তো তখনো পুরোনো নেমসার্ভার ব্যবহার করছে, অথবা DNSSEC যাচাই করছে না।

পরিবর্তনের আগে কী সংগ্রহ করবেন

রেজিস্ট্রারে থাকা সব DS রেকর্ড, মাতৃ জোনে প্রকাশিত NS রেকর্ড এবং পুরোনো কর্তৃত্বপূর্ণ নেমসার্ভারের নাম নোট করুন। DS ও NS-এর TTL-ও লিখে রাখুন: রেকর্ড বদলানোর পর রিজলভার কতক্ষণ আগের তথ্য ক্যাশে রাখতে পারে, অপেক্ষার সময় ঠিক করতে তা দরকার। রেজিস্ট্রারের প্যানেলে DS সরানোর অনুরোধ গৃহীত হওয়া এবং মাতৃ জোনের উত্তরে সেটি আর না থাকা আলাদা ঘটনা; অপেক্ষা শুরুর আগে প্রকাশিত উত্তর দেখুন।

Cloudflare-এ জোন যোগ করে তার DNS রেকর্ড পুরোনো কর্তৃত্বপূর্ণ জোনের সঙ্গে মিলিয়ে নিন। ওয়েব ঠিকানার A বা AAAA, মেইলের MX এবং মালিকানা যাচাই বা মেইল নীতির TXT রেকর্ড বাদ পড়লে DNSSEC ঠিক থাকলেও সংশ্লিষ্ট সেবা ব্যাহত হতে পারে। রেকর্ডের নামের পাশাপাশি মানও মিলিয়ে দেখুন, বিশেষ করে একই নামের একাধিক রেকর্ড থাকলে। এই প্রস্তুতি স্বাক্ষর যাচাইয়ের বাইরে নেমসার্ভার পরিবর্তনের আরেকটি ঝুঁকি কমায়।

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

পুরোনো DS সরিয়ে সাধারণ মাইগ্রেশন

পুরোনো সরবরাহকারী বাইরের DNSKEY প্রকাশ করতে না পারলে প্রথমে DS সরানোর পথ নিন। এতে পুরোনো DS-এর ক্যাশ শেষ হওয়া থেকে নতুন DS কার্যকর হওয়া পর্যন্ত DNSSEC আস্থার শৃঙ্খল সাময়িকভাবে থাকবে না। পরিকল্পনার মূল বিষয় হলো এই অবস্থাকে স্বীকার করে ধাপগুলো সঠিক ক্রমে শেষ করা; তাড়াহুড়া করে নেমসার্ভার বদলালে ক্যাশে থাকা পুরোনো DS আবার যাচাই ব্যর্থ করতে পারে।

1. রেজিস্ট্রারে পুরোনো DS সরান। মাতৃ জোনের উত্তরে সেটি আর নেই দেখে আগে নোট করা DS-এর পূর্ণ TTL পার হতে দিন। শুধু একটি রিজলভারের উত্তর দেখে অপেক্ষা শেষ করবেন না; সেখানে পুরোনো রেকর্ড ইতিমধ্যে ক্যাশ থেকে সরে গিয়ে থাকতে পারে।
2. রেজিস্ট্রারে Cloudflare-নির্ধারিত নেমসার্ভার বসান। পুরোনো NS-এর TTL পার হওয়ার সময় দিন এবং Cloudflare-এর কর্তৃত্বপূর্ণ নেমসার্ভারে প্রত্যাশিত DNS রেকর্ড আছে কি না সরাসরি দেখুন। এই সময় পুরোনো জোন সচল রাখুন।
3. Cloudflare-এ DNSSEC চালু করে তৈরি হওয়া নতুন DS-এর তথ্য রেজিস্ট্রারে দিন। পরে মাতৃ জোনে প্রকাশিত DS-এর সঙ্গে Cloudflare-এ দেখানো তথ্য মিলিয়ে নিন এবং যাচাইকারী রিজলভারে উত্তর গ্রহণ হচ্ছে কি না পরীক্ষা করুন।

এখানে অপেক্ষার কারণ দুই ধরনের ক্যাশ। DS-এর পুরোনো কপি থাকলে নতুন Cloudflare কী দিয়ে স্বাক্ষরিত উত্তর ব্যর্থ হতে পারে। বিপরীতে, পুরোনো নেমসার্ভারে যাওয়ার সম্ভাবনা থাকা অবস্থায় শুধু নতুন কীর DS প্রকাশ করলে সেই পুরোনো পথের উত্তরও যাচাইয়ে আটকে যেতে পারে। তাই নেমসার্ভার পরিবর্তন এবং নতুন DS প্রকাশের মাঝের ধাপ বাদ দেওয়া নিরাপদ নয়।

DNSSEC চালু রেখেই মাল্টি-সাইনার পথ

পুরোনো সরবরাহকারী বাইরের DNSKEY প্রকাশ করতে পারলে Cloudflare-এর সক্রিয় মাইগ্রেশন পদ্ধতি অনুসারে দুই জোনে পরস্পরের জোন স্বাক্ষরকারী কী, অর্থাৎ ZSK, যোগ করা যায়। এখানে নতুন DS আগেভাগে প্রকাশ করাই পুরো সমাধান নয়: উভয় কর্তৃত্বপূর্ণ সরবরাহকারীর DNSKEY উত্তরে দুই ZSK থাকতে হবে। রেজিস্ট্রারেও পরিবর্তনের মধ্যবর্তী সময়ে দুই সরবরাহকারীর DS এবং নেমসার্ভার রাখার সুযোগ প্রয়োজন।

1. Cloudflare-এ আমদানি করা রেকর্ড মিলিয়ে DNSSEC ও মাল্টি-সাইনার ব্যবস্থা চালু করুন। পুরোনো সরবরাহকারীর ZSK Cloudflare জোনে যোগ করুন, তারপর Cloudflare-এর ZSK পুরোনো সরবরাহকারীর জোনে যোগ করুন।
2. পুরোনো ও নতুন সরবরাহকারীর প্রত্যেক কর্তৃত্বপূর্ণ নেমসার্ভারে সরাসরি DNSKEY প্রশ্ন পাঠান। সব উত্তরে দুই ZSK পাওয়া এবং পরিবর্তিত DNSKEY-এর ক্যাশের মেয়াদ পার হওয়ার পর রেজিস্ট্রারে Cloudflare-এর DS ও নেমসার্ভার যোগ করুন।
3. দুই কর্তৃত্বপূর্ণ পথের উত্তর যাচাই হলে পুরোনো DS ও নেমসার্ভার সরান। পুরোনো DS-এর TTL-এর অন্তত দেড় গুণ সময় অপেক্ষা করে তবেই Cloudflare জোন থেকে পুরোনো ZSK মুছুন।

এই পদ্ধতিতে মধ্যবর্তী সময়ের রিজলভার পুরোনো বা নতুন যেকোনো কর্তৃত্বপূর্ণ পথে গেলেও বৈধ স্বাক্ষর যাচাই করার ব্যবস্থা থাকে। কিন্তু পুরোনো সরবরাহকারী DNSKEY উত্তরে বাইরের কী দিতে না পারলে প্রথম ধাপই অসম্পূর্ণ থেকে যায়। সে অবস্থায় রেজিস্ট্রারে দুই DS যোগ করে পরীক্ষা চালানো সমাধান নয়; সাধারণ DS-অপসারণ পদ্ধতির জন্য আলাদা সময় নির্ধারণ করুন।

যাচাই ব্যর্থ হলে কোথায় ফিরবেন

পরিবর্তনের পর মাতৃ জোনের DS ও NS, প্রতিটি কর্তৃত্বপূর্ণ নেমসার্ভারের DNSKEY ও প্রয়োজনীয় সেবা রেকর্ড, এবং একাধিক স্বতন্ত্র DNSSEC-যাচাইকারী রিজলভারের ফল আলাদা করে দেখুন। কোনো রিজলভার SERVFAIL দিলে প্রথমে তার দেখা DS কোন KSK-এর সঙ্গে মেলে এবং সে কোন কর্তৃত্বপূর্ণ পথে পৌঁছাচ্ছে, তা খুঁজুন। একটি রিজলভারে সফল উত্তর অন্য রিজলভারের ক্যাশে পুরোনো DS বা NS নেই—এ নিশ্চয়তা দেয় না। পরীক্ষায় শুধু উত্তর এসেছে কি না নয়, যাচাই সফল হয়েছে কি না দেখুন।

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

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

আরও পড়ুন:

• GitHub-এ পুরোনো SSH ভাঙতে পারে—RSA key বদলানোর আগে এই পরীক্ষা করুন
• GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
• পাঁচটি Rust বদলে ১০০ TB RAM মুক্ত—Cloudflare-এর DNS cache পাঠ