DNS চেকার গাইড: রেকর্ড, TTL ও সমস্যা সমাধান

DNS লুকআপ করার পদ্ধতি

DNS চেকার খুলুন এবং সংযোগের কনফিগারেশন লোড হওয়া পর্যন্ত অপেক্ষা করুন। www.example.com-এর মতো একটি নাম লিখুন, রেকর্ডের ধরন বেছে নিন, এক বা উভয় প্রোভাইডার এবং উপলব্ধ কোয়েরি স্থান নির্বাচন করুন। অনুরোধ পাঠাতে “DNS যাচাই করুন” চাপুন। পেজ খোলা বা নাম বদলানোয় রেকর্ড স্বয়ংক্রিয়ভাবে খোঁজা হয় না।

মানের অর্থ বোঝার আগে প্রোভাইডার, স্থান, অবস্থা ও সময় দেখুন। প্রয়োজনীয় মান জানা থাকলে ঐচ্ছিক প্রত্যাশিত-মান ঘরে লিখুন এবং “হুবহু মিলে যায়” বা “অন্তর্ভুক্ত করে” নির্বাচন করুন। “DNS প্রতিবেদন ডাউনলোড করুন” বর্তমান ফলাফল dns-results.json হিসেবে রাখে; পরিবর্তনের আগে ও পরে তুলনার জন্য ফাইলটি রাখুন।

• প্রতিটি যাচাইয়ে একটি DNS নাম ও একটি রেকর্ডের ধরন ব্যবহৃত হয়। দুই ঠিকানা পরিবার পরীক্ষা করলে A ও AAAA আলাদাভাবে চালান।
• ডিফল্ট হিসেবে A, দুই প্রোভাইডার ও ToolMellow-এর মূল স্থান নির্বাচিত থাকে। উপলব্ধ স্থান আসে পরিষেবার বর্তমান কনফিগারেশন থেকে।
• নাম, ধরন, প্রোভাইডার বা স্থান বদলালে আগের ফলাফল মুছে যায়। প্রত্যাশিত মান বা তুলনার পদ্ধতি বদলালে বর্তমান ফলাফল শুধু স্থানীয়ভাবে আবার তুলনা করা হয়।

কাজ অনুযায়ী DNS রেকর্ডের ধরন নির্বাচন

DNS রেকর্ড ভিন্ন প্রশ্নের উত্তর দেয়। A লুকআপ কোনো ডোমেনের সব রেকর্ড চায় না, এবং MX লুকআপ পরীক্ষামূলক ইমেইল পাঠায় না। তালিকায় নয়টি ধরন রয়েছে। প্রত্যাশিত মানের তুলনা নিচের আটটি সরাসরি লুকআপের ধরনের জন্য কাজ করে; PTR ফলাফল দেখা ও ডাউনলোড করা যায়, কিন্তু প্রত্যাশিত-মান তুলনা পাওয়া যায় না।

RFC 1035: DNS বাস্তবায়ন ও রেকর্ডের রূপRFC 3596: IPv6-এর জন্য DNS সম্প্রসারণRFC 8659: সার্টিফিকেট কর্তৃপক্ষের অনুমোদন

TXT নাম ও আন্তর্জাতিক ডোমেনসহ সঠিক DNS নাম লেখা

যে DNS নামের অধীনে রেকর্ড রয়েছে, সেটি দিন; URL স্কিম, পাথ, ইমেইল ঠিকানা বা পোর্ট দেবেন না। মূল ডোমেন ও তার www নাম আলাদা ইনপুট। যাচাইয়ের নির্দেশে সাবডোমেন বা আন্ডারস্কোর দিয়ে শুরু হওয়া নাম লাগতে পারে; মূল ডোমেনে TXT খুঁজলে অন্য নামের TXT স্বয়ংক্রিয়ভাবে পাওয়া যায় না।

চেকার দুই প্রান্তের ফাঁকা স্থান সরায়, সমর্থিত Unicode ডটের রূপ চিনতে পারে, শেষের রুট ডট বাদ দেয়, Node-এর domainToASCII দিয়ে সমর্থিত আন্তর্জাতিক নাম ASCII-তে বদলায় এবং কোয়েরি নাম লোয়ারকেস করে। অন্তত দুটি লেবেল লাগে; রূপান্তরের পরে প্রতি লেবেলে সর্বোচ্চ 63 ASCII ক্যারেক্টার এবং পুরো নামে সর্বোচ্চ 253 থাকে। সাধারণ লেবেলে অক্ষর, সংখ্যা ও মাঝখানে হাইফেন চলে। সমর্থিত আন্ডারস্কোর-শুরু পরিষেবা লেবেল গ্রহণ করা হয়, কিন্তু সাধারণ লেবেলের ভেতরে ইচ্ছামতো আন্ডারস্কোর চলে না।

RFC 5891: আন্তর্জাতিক ডোমেন নামNode.js: URL domainToASCII রূপান্তরRFC 1035: DNS বাস্তবায়ন ও রেকর্ডের রূপRFC 6376: DKIM স্বাক্ষর ও সিলেক্টর দিয়ে কী খোঁজাRFC 9989: DMARC নীতি অনুসন্ধান ও পরিচয়ের সামঞ্জস্য

রিকার্সিভ প্রোভাইডার ও কর্তৃত্বপূর্ণ নেমসার্ভারের ভূমিকা আলাদা

কর্তৃত্বপূর্ণ নেমসার্ভার একটি DNS জোনের তথ্য প্রকাশ করে। রিকার্সিভ রিজলভার ক্লায়েন্টের হয়ে উত্তর সংগ্রহ করে এবং ক্যাশের তথ্য আবার ব্যবহার করতে পারে। Google Public DNS বা Cloudflare নির্বাচন করলে এই ফলাফলের জন্য রিকার্সিভ পরিষেবা বেছে নেওয়া হয়; তার মানে পরিষেবাটি আপনার জোন হোস্ট করে বা সেটিই ডোমেনের কর্তৃত্বপূর্ণ নেমসার্ভার, তা নয়।

ToolMellow তার সার্ভার বা কনফিগার করা প্রোব থেকে প্রোভাইডারের নির্দিষ্ট HTTPS প্রান্তে অনুরোধ পাঠায় এবং JSON উত্তর পড়ে। প্রোভাইডারের এই JSON রূপ DNS over HTTPS-এর জন্য মান নির্ধারিত DNS বাইনারি বার্তা থেকে আলাদা। লুকআপ ডিভাইসের DNS সেটিং বদলায় না, আপনার দেওয়া যেকোনো নেমসার্ভার সরাসরি পরীক্ষা করে না এবং রুট থেকে প্রতিটি ডেলিগেশন ট্রেস করে না।

RFC 1034: ডোমেন নাম, রিজলিউশন ও ক্যাশRFC 8484: HTTPS-এর মাধ্যমে DNS কোয়েরিGoogle Public DNS: DNS over HTTPS-এর JSON APICloudflare 1.1.1.1: JSON DNS over HTTPS অনুরোধ

রেকর্ড নাম, TTL ও ফলাফলের তথ্য একসঙ্গে পড়ুন

উত্তরের প্রতি সারিতে রেকর্ডের নাম, ধরন, ফেরত আসা TTL সেকেন্ডে এবং টেক্সট তথ্য থাকে। মানের সঙ্গে নামও পড়ুন: রিকার্সিভ উত্তরে অ্যালিয়াসের শৃঙ্খল এবং অ্যালিয়াসের লক্ষ্যের ঠিকানা থাকতে পারে। সহায়ক CNAME বা অন্য ফেরত আসা ধরন আপনার চাওয়া ধরনের বিকল্প নয়। নেতিবাচক বা রেফারাল উত্তরের প্রসঙ্গ বুঝতে “কর্তৃত্বের রেকর্ড” খুলুন।

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

RFC 1035: DNS বাস্তবায়ন ও রেকর্ডের রূপRFC 2308: DNS কোয়েরির নেতিবাচক ক্যাশিং

DNS-এ তথ্য না থাকা ও অনুরোধ ব্যর্থ হওয়া আলাদা করে বুঝুন

একটি বৈধ নেতিবাচক উত্তর এবং শেষ করা যায়নি এমন অনুরোধের পরবর্তী পদক্ষেপ আলাদা। ToolMellow-এ ইতিবাচক NOERROR শ্রেণিতে চাওয়া ধরনের উত্তর থাকে। অন্য সফল DNS উত্তর SOA, CNAME বা NS প্রসঙ্গ দেখে শ্রেণিবদ্ধ হয়। নিচের তালিকা দৃশ্যমান অবস্থা ব্যাখ্যা করে, যাতে প্রতিটি খালি উত্তরকে অনুপস্থিত ডোমেন মনে না করেন।

কাটা উত্তর অসম্পূর্ণ, এমনকি তার এক অংশে প্রত্যাশিত টেক্সট থাকলেও। কাটা উত্তর বা কার্যগত ব্যর্থতায় তুলনার ফল অনির্ণায়ক হয়। এক প্রোভাইডার সফল হলেও অন্যটি ব্যর্থ হতে পারে; দুই ফল রাখুন, ব্যর্থতাকে রেকর্ড অনুপস্থিতির প্রমাণ ভাববেন না।

RFC 2308: DNS কোয়েরির নেতিবাচক ক্যাশিংGoogle Public DNS: DNS over HTTPS-এর JSON APICloudflare 1.1.1.1: JSON DNS over HTTPS অনুরোধ

রেকর্ড বদলানোর পরে DNS TTL-এর অর্থ

TTL ক্যাশের মেয়াদ সেকেন্ডে বোঝায়। রিকার্সিভ রিজলভার ক্যাশে থাকা তথ্যের বাকি সময় ফেরত দিতে পারে, তাই অন্য তথ্য একই হলেও দুই উত্তরে TTL আলাদা হতে পারে। সংখ্যাটি বিশ্বের সব রিজলভার নতুন মান ব্যবহার করবে কখন, তার কাউন্টডাউন নয়।

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

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

RFC 2181, অংশ 8: কার্যকর মেয়াদRFC 2308: DNS কোয়েরির নেতিবাচক ক্যাশিংRFC 8767: মেয়াদ ফুরোনো DNS তথ্য ফেরত দেওয়া

প্রোভাইডারের সম্মতি বিশ্বজুড়ে DNS পরিবর্তন প্রমাণ করে না কেন

Google ও Cloudflare আলাদা ক্যাশ ফল বা রিজলিউশন আচরণের জন্য ভিন্ন উত্তর দিতে পারে। অবস্থাননির্ভর কর্তৃত্বপূর্ণ উত্তরও প্রভাব ফেলতে পারে। প্রথমে নথিবদ্ধ সময়ে একই স্বাভাবিকীকৃত নাম ও ধরন তুলনা করুন, তারপর অবস্থা, নাম, মান ও TTL দেখুন। পার্থক্য নিজে থেকে সঠিক উত্তরটি চিহ্নিত করে না।

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

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

RFC 1034: ডোমেন নাম, রিজলিউশন ও ক্যাশRFC 8767: মেয়াদ ফুরোনো DNS তথ্য ফেরত দেওয়া

প্রত্যাশিত মান হুবহু বা অন্তর্ভুক্ত থাকার ভিত্তিতে তুলনা করুন

প্রত্যাশিত-মান তুলনা Answer অংশে চাওয়া এবং তুলনার জন্য সমর্থিত ধরনের মান খোঁজে। “হুবহু মিলে যায়” হলে পুরো ফেরত আসা টেক্সট প্রত্যাশিত টেক্সটের সমান হতে হবে; “অন্তর্ভুক্ত করে” হলে প্রত্যাশিত উপ-পাঠ তার মধ্যে থাকতে হবে। দুই পদ্ধতিই আপারকেস ও লোয়ারকেস আলাদা করে। একটি মান মিললেই সেই প্রোভাইডার ও স্থানের ফল মিলে যায়, যদিও অন্য মান আলাদা হয়। পুরো রেকর্ড সেট প্রত্যাশিত কনফিগারেশনের সমান, তা এতে প্রমাণ হয় না।

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

• চাওয়া মান না থাকলে NXDOMAIN ও NODATA সাধারণত আলাদা হিসেবে তুলনা হয়; এগুলো বৈধ নেতিবাচক ফল, অনুরোধের ব্যর্থতা নয়।
• ব্যর্থ বা কাটা ফল অনির্ণায়ক। প্রত্যাশিত টেক্সট খালি, 4096 JavaScript স্ট্রিং ইউনিটের বেশি বা PTR তুলনা হলে তুলনা পাওয়া যায় না।
• প্রত্যাশিত টেক্সট এই ট্যাব ও ডাউনলোড প্রতিবেদনে থাকে; DNS কোয়েরির সঙ্গে যায় না। টেক্সট মেলা একা DNSSEC যাচাই বা ডোমেনের মালিকানা প্রমাণ করে না।

RFC 4343: DNS নামের তুলনায় কেস উপেক্ষা

DNSSEC প্রমাণিত-তথ্য নির্দেশক তার উৎসসহ পড়ুন

“প্রমাণিত” নির্দেশক নির্বাচিত রিকার্সিভ রিজলভারের AD ফ্ল্যাগ বোঝায়। সেই রিজলভার তথ্য প্রমাণিত বলে জানাচ্ছে; ToolMellow স্বাধীনভাবে DNSSEC স্বাক্ষর বা আস্থার শৃঙ্খল যাচাই করে না। দাবিটি বিশ্বাস করতে রিজলভার ও উত্তর বহন করা যোগাযোগের পথকেও বিশ্বাস করতে হয়।

“অপ্রমাণিত” মানে প্রোভাইডার AD ফ্ল্যাগ সেট করেনি। স্বাক্ষরহীন তথ্যেও এই ফল হতে পারে, তাই নির্দেশক একা খারাপ বা ক্ষতিকর ডোমেন প্রমাণ করে না। SERVFAIL-ও অনুসন্ধান চায়, স্বয়ংক্রিয় DNSSEC সিদ্ধান্ত নয়। চেকার প্রোভাইডারে যাচাই চালু রেখে DNSSEC-সংক্রান্ত উত্তরের তথ্য চায়, কিন্তু পূর্ণ DNSSEC অডিট বা ব্রাউজারের DNS লিক পরীক্ষা করে না।

RFC 4035: DNSSEC ও প্রমাণিত-তথ্য দাবিGoogle Public DNS: DNS over HTTPS-এর JSON APICloudflare 1.1.1.1: JSON DNS over HTTPS অনুরোধ

হোস্টিং ও HTTPS-এর আগে ওয়েবসাইটের DNS দেখুন

সাইট পুরোনো গন্তব্যে গেলে দর্শকের ব্যবহৃত সঠিক হোস্টনাম পরীক্ষা করুন। A ও AAAA আলাদা করে মিলান, আর www-এর মতো অ্যালিয়াসের জন্য CNAME দেখুন। মূল ডোমেন ও www একই কনফিগারেশন ধরে নেবেন না। ফলাফল হোস্টিং পরিষেবার নথিতে থাকা প্রত্যাশিত রেকর্ডের সঙ্গে মিলান, যার মধ্যে দরকারি অ্যালিয়াস লক্ষ্যও থাকে।

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

RFC 1035: DNS বাস্তবায়ন ও রেকর্ডের রূপRFC 8659: সার্টিফিকেট কর্তৃপক্ষের অনুমোদন

সঠিক নামে TXT যাচাই, SPF, DKIM ও DMARC খুঁজুন

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

SPF নীতিতে সংশ্লিষ্ট মেইল ডোমেনে TXT ব্যবহৃত হয়। DKIM কী লুকআপ সিলেক্টরভিত্তিক নামে হয়, যেমন selector._domainkey.example.com; সিলেক্টর মেইল পরিষেবা থেকে নিন, অনুমান করবেন না। DMARC-সংক্রান্ত পরীক্ষা প্রায়ই _dmarc.example.com-এর TXT দিয়ে শুরু হয়। আধুনিক DMARC নীতি অনুসন্ধান ও পরিচয়গুলোর সামঞ্জস্যে আরও নিয়ম আছে, যেগুলো একটিমাত্র TXT ফল মূল্যায়ন করে না।

MX মেইল রুটিং বর্ণনা করে, আর TXT ভিত্তিক ব্যবস্থাগুলোর ভূমিকা আলাদা। চেকার সব SPF include অনুসরণ করে না, স্বাক্ষরিত বার্তা যাচাই করে না, পূর্ণ DMARC নীতি অনুসন্ধান মূল্যায়ন করে না, DMARC প্রতিবেদন বিশ্লেষণ বা মেইল সরবরাহের পরীক্ষা করে না। রেকর্ড থাকা বা উপ-পাঠ মেলা এই পরীক্ষাগুলোর বিকল্প নয়।

RFC 7208, অংশ 3.1: TXT-তে SPF নীতিRFC 6376: DKIM স্বাক্ষর ও সিলেক্টর দিয়ে কী খোঁজাRFC 9989: DMARC নীতি অনুসন্ধান ও পরিচয়ের সামঞ্জস্য

কোয়েরির গোপনীয়তা বুঝুন এবং উপযোগী DNS প্রতিবেদন দিন

চাওয়া নাম ও ধরন ToolMellow-এর ব্রোকার বা নির্বাচিত প্রোব হয়ে নির্বাচিত পাবলিক রিজলভারে যায়। রিজলভার প্রোবের নেটওয়ার্ক ঠিকানা দেখে; ToolMellow দর্শকের ক্লায়েন্ট-IP হেডার সেখানে পাঠায় না। হোস্টিং স্বাভাবিক অনুরোধের মেটাডেটা পায়। HTTPS পুরো কাজকে পরিচয়হীন করে না বা শূন্য-লগ নীতি প্রমাণ করে না; নাম নিজেও সংবেদনশীল হতে পারে।

প্রত্যাশিত টেক্সট স্থানীয়ভাবে তুলনা হয় এবং dns-results.json-এ expectedComparison হিসেবে থাকতে পারে। প্রতিবেদন দেওয়ার আগে কোয়েরি নাম, ফেরত আসা তথ্য ও প্রত্যাশিত টেক্সট দেখুন, বিশেষ করে যাচাই টোকেন। সংশ্লিষ্ট ফল নির্দিষ্ট প্রাপককে দিন; প্রতিটি রপ্তানি করা মান সর্বসাধারণের জন্য প্রকাশযোগ্য ধরে নেবেন না।

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

অনুপস্থিত বা অপ্রত্যাশিত DNS উত্তর ধাপে ধাপে দেখুন

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

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

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

প্রায়শই জিজ্ঞাসিত প্রশ্ন

তথ্যসূত্র ও আরও পড়ুন

• RFC 1034: ডোমেন নাম, রিজলিউশন ও ক্যাশ
• RFC 1035: DNS বাস্তবায়ন ও রেকর্ডের রূপ
• RFC 3596: IPv6-এর জন্য DNS সম্প্রসারণ
• RFC 8659: সার্টিফিকেট কর্তৃপক্ষের অনুমোদন
• RFC 2181, অংশ 8: কার্যকর মেয়াদ
• RFC 2308: DNS কোয়েরির নেতিবাচক ক্যাশিং
• RFC 8767: মেয়াদ ফুরোনো DNS তথ্য ফেরত দেওয়া
• RFC 4035: DNSSEC ও প্রমাণিত-তথ্য দাবি
• RFC 8484: HTTPS-এর মাধ্যমে DNS কোয়েরি
• Google Public DNS: DNS over HTTPS-এর JSON API
• Cloudflare 1.1.1.1: JSON DNS over HTTPS অনুরোধ
• RFC 4343: DNS নামের তুলনায় কেস উপেক্ষা
• RFC 5891: আন্তর্জাতিক ডোমেন নাম
• Node.js: URL domainToASCII রূপান্তর
• RFC 7208, অংশ 3.1: TXT-তে SPF নীতি
• RFC 6376: DKIM স্বাক্ষর ও সিলেক্টর দিয়ে কী খোঁজা
• RFC 9989: DMARC নীতি অনুসন্ধান ও পরিচয়ের সামঞ্জস্য