একটি ব্যক্তিগত নাম EC2 ইনস্ট্যান্স থেকে রিজলভ হয় কিন্তু VPN দিয়ে সংযুক্ত ল্যাপটপ থেকে হয় না, আর জোন কনসোলে সঠিক দেখায়। প্রথম প্রবণতা রেকর্ড সম্পাদনা করা, যা প্রায় কখনোই সমস্যা নয়। রেকর্ড কাউকে উত্তর দিচ্ছে; শুধু আপনার ল্যাপটপকে উত্তর দিচ্ছে না। দুই কলারের মধ্যে পার্থক্য হলো তারা কোন resolver-কে জিজ্ঞাসা করে এবং সেই resolver-এর VPC-র DNS ভিউতে সমর্থিত পথ আছে কি না।

রেকর্ডটির অস্তিত্ব প্রমাণ করে শুরু করি, তারপর বাকি সময় কোয়েরি পথে ব্যয় করি। এগুলো আলাদা সিস্টেম এবং ভিন্নভাবে ব্যর্থ হয়।

কিছু বদলানোর আগে ব্যর্থতার আকৃতি পড়ুন

তিনটি ফলাফল তিনটি ভিন্ন বিষয় বোঝায়, আর একটি কোয়েরি তাদের আলাদা করে: ক্লায়েন্ট আসলে যে resolver ব্যবহার করছে তার বিরুদ্ধে নামের জন্য dig চালান।

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

সময় শেষ হওয়া নেটওয়ার্ক সম্পর্কে একটি বিবৃতি। NXDOMAIN হলো DNS ভিউ সম্পর্কে বিবৃতি। সর্বজনীন উত্তর নীতি সম্পর্কে বিবৃতি। সময় শেষ হওয়ার সময় জোন রেকর্ড সম্পাদনা করা মামলার একমাত্র উপকারী প্রমাণ ফেলে দেয়।

কেন VPC-র প্লাস-দুই ঠিকানা দূরবর্তী resolver নয়

CIDR প্লাস-দুই ঠিকানা VPC-র ভিতরের রিসোর্সের জন্য স্থানীয় সেবা। AWS নথিভুক্ত করে যে স্থানীয় নেটওয়ার্ক থেকে, বা অন্য একটি VPC-র DNS সার্ভার থেকে, কোয়েরি সরাসরি সেই ঠিকানায় পাঠানো সমর্থিত নয় এবং অস্থির ফলাফল দিতে পারে।

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

পথটি সেই ক্রমে তৈরি করুন যাতে এটি পরিষ্কারভাবে ব্যর্থ হয়

তিনটি হপ থাকতে হবে, এবং প্রত্যেকের ব্যর্থ হওয়ার নিজস্ব ধরন আছে।

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

ফরওয়ার্ডারের VPN দিয়ে এন্ডপয়েন্ট ঠিকানাগুলোতে একটি রুট দরকার, আর ফেরার পথও কাজ করতে হবে। পোর্ট 53-এ প্রচলিত DNS-এর জন্য এন্ডপয়েন্ট UDP এবং TCP-তে উত্তর দেয়, তাই দুটি প্রোটোকলকেই অনুমতি দিতে হবে এবং দুটোকেই মাঝখানে কোনো স্টেটফুল পরিদর্শন পার হতে হবে।

তারপর DNS ভিউ আলাদাভাবে যাচাই করুন। একটি ব্যক্তিগত হোস্টেড জোন শুধু যে VPC-গুলোর সঙ্গে এটি সংযুক্ত তাদেরই দেখা যায়, বা ইচ্ছাকৃত শেয়ারিং ব্যবস্থার মাধ্যমে। পৌঁছনোযোগ্য এন্ডপয়েন্ট নিজে থেকে প্রতিটি ব্যক্তিগত জোনকে তার রিজলিউশন প্রসঙ্গে রিজলভযোগ্য করে না।

আউটবাউন্ড এন্ডপয়েন্ট বিপরীত দিকের সেবা দেয় এবং আপনার ল্যাপটপ থেকে আসা কোয়েরির উত্তর দেবে না।

দুই প্রান্ত থেকেই যাচাই করুন

ক্লায়েন্ট থেকে ফরওয়ার্ডারের বিরুদ্ধে কোয়েরি করুন, তারপর ফরওয়ার্ডার থেকে এন্ডপয়েন্টের বিরুদ্ধে। ক্লায়েন্ট ব্যর্থ হয়ে ফরওয়ার্ডার সফল হলে ব্যবধান ওই দুটোর মধ্যে।

দুটোই ব্যর্থ হলে এন্ডপয়েন্টের নিরাপত্তা নীতি এবং এটি যে সোর্স ঠিকানা সত্যিই দেখে তা দেখুন। NAT-এর পিছনের ফরওয়ার্ডার ল্যাপটপের VPN ঠিকানার বদলে NAT ঠিকানা উপস্থাপন করে, আর এই পার্থক্যটুকুই কোয়েরি ফেলে দেওয়ার জন্য যথেষ্ট। দুটোই সফল হলেও অ্যাপ্লিকেশন এখনো ব্যর্থ হলে অ্যাপ্লিকেশন হয়তো আপনি যেটি পরীক্ষা করেছেন তার চেয়ে ভিন্ন resolver ব্যবহার করছে।

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

যা আমি করতাম না

এমন NAT নিয়ম যোগ করতাম না যা একটি অনুসন্ধান চালু করল, আর সেটাকে ডিজাইন বলতাম না।

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

সম্পর্কিত নিবন্ধ