# ওয়েবসাইট সিকিউরিটি স্ক্যান

URL: https://discuvr.org/security-scan/?hl=bn
Last updated: 2026-11-07
MCP tool: `security_scan`

একটি ডোমেইন স্ক্যান করুন অনুপস্থিত সিকিউরিটি হেডার, TLS সমস্যা এবং উন্মুক্ত ফাইলের জন্য। প্রতিটি ফলাফল প্রকৃত প্রমাণ এবং তা পুনরুৎপাদনের সঠিক কমান্ড দেখায়।

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

## এটি কী করে

- DNS ও CAA, SPF ও DMARC, TLS সার্টিফিকেট ও TLS 1.0/1.1, HTTPS রিডাইরেক্ট, সিকিউরিটি হেডার, কুকি ফ্ল্যাগ, CORS, ভার্সন ব্যানার, HTTP মেথড, মিশ্র কনটেন্ট, ২৩টি সংবেদনশীল পাথ, ডিরেক্টরি লিস্টিং, robots.txt, security.txt এবং ১২টি সার্ভিস পোর্ট পরীক্ষা করে।
- প্রতিটি ফলাফল প্রকৃত পর্যবেক্ষণ এবং সেটি পুনরুৎপাদনের একটি শেল কমান্ড বহন করে।
- যে পরীক্ষাগুলো চালানো যায়নি সেগুলো "পরীক্ষা করা হয়নি" হিসেবে রিপোর্ট করা হয় - কখনোই নীরবে পাস হিসেবে নয়।
- রিপোর্ট Markdown বা JSON হিসেবে ডাউনলোড হয়।

## এটি যেভাবে কাজ করে

1. আপনি যে ডোমেইনের জন্য দায়ী তা লিখুন।
2. স্ক্যান প্যাসিভ প্রোব চালায় - সাধারণ রিকোয়েস্ট, কোনো শোষণ নয়।
3. ফলাফলগুলো, প্রতিটির প্রমাণ সহ পড়ুন, এবং যেগুলো গুরুত্বপূর্ণ সেগুলো যাচাই করুন।

## কোনো ফলাফল বানানো নয়

স্ক্যানারে কোনো ভাষা মডেল নেই। গুরুত্ব, প্রভাব ও সমাধান প্রতিটি পরীক্ষার জন্য নির্দিষ্ট, এবং প্রতিটি ফাইন্ডিং একটি বাস্তব পর্যবেক্ষণ থেকে তৈরি। স্ক্রিনের রিপোর্ট এবং Markdown ও JSON ডাউনলোড একই ফাইন্ডিং থেকে তৈরি হয়, কোথাও কোনো মডেল নেই।

## গ্রেড কীভাবে হিসাব হয়

স্কোর ১০০ থেকে শুরু হয় এবং প্রতিটি ক্রিটিক্যাল ফাইন্ডিংয়ে ৩৪, হাইতে ১৩, মিডিয়ামে ৫ এবং লো-তে ১.৫ নম্বর কমে, প্রতিটি মাত্রার মোটের ওপর সীমা আছে (হাই ৪৫, মিডিয়াম ২২, লো ৯)। তথ্যমূলক ও পাস করা ফলাফলে কিছু কমে না। ৯০ বা তার বেশি A, ৭৫ থেকে B, ৬০ থেকে C, ৪০ থেকে D, তার নিচে F। একটি উন্মুক্ত .env ফাইল বা নাগালে থাকা ডেটাবেস পোর্ট একটি পরিচ্ছন্ন সাইটকে ১০০ থেকে ৬৬, অর্থাৎ C-তে নামিয়ে দেয়; এমন দুটি ফাইন্ডিং দেয় ৩২, অর্থাৎ F।

## ভুল সতর্কতা এড়ানো

/.git/HEAD বা /backup.sql-এর মতো পাথ পরীক্ষার আগে স্ক্যানার এমন একটি এলোমেলো ঠিকানা চায় যা থাকতেই পারে না, এবং সাইট কী উত্তর দেয় তা লিখে রাখে। কোনো পাথ তখনই উন্মুক্ত বলে জানানো হয় যখন সেটি HTTP 200 ফেরত দেয়, সেই নট-ফাউন্ড রেফারেন্স থেকে আলাদা হয় এবং ফাইলের নিজস্ব সিগনেচারের সঙ্গে মেলে। তাই যে সাইট প্রতিটি URL-এ হোমপেজ দেখায়, সেটি ক্রিটিক্যাল ফাইন্ডিংয়ে ভরে যায় না।

## একটি পরিষ্কার রিপোর্ট কোনো সার্টিফিকেট নয়

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

## শুধু আপনার নিজের জিনিসই স্ক্যান করুন

সেই ডোমেইনগুলো স্ক্যান করুন যেগুলোর আপনি মালিক বা পরীক্ষা করার জন্য যার লিখিত অনুমতি আপনার আছে। টুলটি প্রাইভেট বা ইন্টারনাল অ্যাড্রেসে রিজলভ হওয়া হোস্টগুলো প্রত্যাখ্যান করে, এবং প্রতি IP-তে রেট-লিমিটেড, কিন্তু অনুমোদন এখনও আপনার দায়িত্ব।

## প্রশ্নাবলী

**এটি কি একটি সক্রিয় আক্রমণ?**

না। এটি সাধারণ GET, HEAD ও OPTIONS অনুরোধ, TLS হ্যান্ডশেক (TLS 1.0 ও 1.1-এর চেষ্টাসহ), Cloudflare-এর DNS-over-HTTPS দিয়ে DNS লুকআপ এবং ১২টি পোর্টে সাধারণ TCP সংযোগ করে। কিছুই এক্সপ্লয়েট করা হয় না, কোনো ফর্ম জমা দেওয়া হয় না এবং কিছুই বদলানো হয় না।

**আমি কি কোনো ওয়েবসাইট স্ক্যান করতে পারি?**

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

**একটি পরীক্ষা কেন "পরীক্ষা করা হয়নি" বলে?**

কারণ এটি সম্পূর্ণ করা যায়নি - সাধারণত কারণ সেই উৎস থেকে কিছুই সাড়া দেয়নি। এটি সততার সাথে রিপোর্ট করা হয়, পাস হিসেবে নথিভুক্ত করার পরিবর্তে।

**আমি কি রিপোর্ট এক্সপোর্ট করতে পারি?**

হ্যাঁ, Markdown বা JSON হিসেবে, এক ঘণ্টা পর্যন্ত: ডাউনলোড যাতে কাজ করে সেজন্য রিপোর্ট ততক্ষণ সার্ভার ক্যাশে থাকে, তারপর মেয়াদ শেষ হয়। কোনো এক্সপোর্টেই মডেল লাগে না। ব্যবহারের রেকর্ডে ফাইন্ডিংয়ের সংখ্যা ও গ্রেড থাকে, ডোমেন নয়।

**এটি কোন ফাইল ও পোর্ট পরীক্ষা করে?**

ফাইল: 23টি নির্দিষ্ট পাথ, যার মধ্যে আছে /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env; প্রতিটি কেবল তখনই রিপোর্ট হয় যখন উত্তর সেই ফাইলের নিজস্ব সিগনেচারের সঙ্গে মেলে। /.well-known/security.txt প্রকাশিত থাকলে তা আপনার পক্ষে গণ্য হয়। পোর্ট: 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080-এ একটি সাধারণ TCP সংযোগ, কখনো লগইনের চেষ্টা নয়। ইন্টারনেট থেকে পৌঁছানো যায় এমন ডেটাবেস পোর্ট (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) বা Telnet ক্রিটিক্যাল হিসেবে ধরা হয়।

**SPF ও DMARC পরীক্ষা কী কী চিহ্নিত করে?**

দুটি রেকর্ডই পাবলিক DNS থেকে পড়া হয়, যে সাইট ইমেল পাঠায় না তার ক্ষেত্রেও, কারণ এগুলো না থাকলে যে কেউ আপনার ডোমেন থেকে আসার দাবি করে ইমেল পাঠাতে পারে। SPF রেকর্ড না থাকলে মাঝারি; +all থাকা SPF রেকর্ড, যা ইন্টারনেটের সব সার্ভারকে অনুমতি দেয়, উচ্চ। _dmarc-এ DMARC রেকর্ড না থাকলে মাঝারি; p=none (বা p= ট্যাগ না থাকলে) কেবল পর্যবেক্ষণ করে এবং নিম্ন; p=quarantine বা p=reject পাস করে। যে ডোমেন কোনো ইমেলই পাঠায় না, সেটি v=spf1 -all প্রকাশ করতে পারে।

**এটি কোন কোন সিকিউরিটি হেডার পরীক্ষা করে, আর কোন মান পাস করে?**

আপনার হোমপেজের রেসপন্সের ছয়টি হেডার। না থাকলে HSTS ও Content-Security-Policy উচ্চ, X-Content-Type-Options ও X-Frame-Options মাঝারি, Referrer-Policy ও Permissions-Policy নিম্ন। Strict-Transport-Security-এ max-age অন্তত 15552000 (১৮০ দিন) হতে হবে: কম হলে নিম্ন, max-age=0 হলে মাঝারি। script-src যদি 'unsafe-inline' অনুমতি দেয়, পলিসি যদি 'unsafe-eval' অনুমতি দেয়, অথবা default-src বা script-src-এ যদি একক * ওয়াইল্ডকার্ড থাকে, তবে Content-Security-Policy দুর্বল (মাঝারি) হিসেবে চিহ্নিত হয়। X-Content-Type-Options হুবহু nosniff হতে হবে। X-Frame-Options হতে হবে DENY বা SAMEORIGIN, আর CSP-তে frame-ancestors থাকলে এটি লাগে না। Referrer-Policy কেবল unsafe-url বা no-referrer-when-downgrade হলে চিহ্নিত হয়। Permissions-Policy শুধু থাকলেই হয়। প্রতিটি অনুপস্থিত বা দুর্বল হেডারের সঙ্গে একটি curl -sI কমান্ড থাকে, যাতে আপনি নিজে যাচাই করতে পারেন।

**এটি কুকির ফ্ল্যাগ (Secure, HttpOnly, SameSite) কীভাবে যাচাই করে?**

এটি আপনার হোমপেজের রেসপন্সের প্রতিটি Set-Cookie হেডার পড়ে (সর্বোচ্চ 12টি কুকি) এবং প্রতিটিতে Secure, HttpOnly ও SameSite যাচাই করে। Secure বা HttpOnly না থাকলে মাঝারি; শুধু SameSite না থাকলে নিম্ন, আর Secure ছাড়া SameSite=None আলাদা করে জানানো হয়, কারণ ব্রাউজার এমন কুকি প্রত্যাখ্যান করে। তিনটিই থাকলে কুকিটি পাস করে। সাধারণ সমাধান Secure; HttpOnly; SameSite=Lax (Django-তে: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY ও SESSION_COOKIE_SAMESITE)। স্ক্যান লগ ইন করে না, তাই শুধু লগইনের পরে তৈরি হওয়া কুকি এটি দেখে না। নিজে যাচাই করুন: curl -sI https://your-site/ | grep -i set-cookie

**CORS যাচাই কীভাবে কাজ করে, আর কখন এটি গুরুতর?**

এটি আপনার হোমপেজে Origin: https://scanner-probe.example সহ একটি GET অনুরোধ পাঠায় এবং উত্তরে Access-Control-Allow-Origin ও Access-Control-Allow-Credentials পড়ে। Access-Control-Allow-Origin হেডার না থাকলে, অথবা এমন নির্দিষ্ট origin থাকলে যা পরীক্ষার origin ফেরত দেয় না, পাস। পরীক্ষার origin Access-Control-Allow-Credentials: true সহ ফেরত দেওয়া গুরুতর, কারণ লগ ইন করা ব্যবহারকারী যে সাইটেই যান সেটি তাঁর রেসপন্স পড়তে পারে। ক্রেডেনশিয়াল ছাড়া origin ফেরত দেওয়া মাঝারি। ওয়াইল্ডকার্ড * নিম্ন, তবে ক্রেডেনশিয়ালও অনুমোদিত হলে মাঝারি (ব্রাউজার এই সমন্বয় প্রত্যাখ্যান করে)। শুধু হোমপেজ পরীক্ষা করা হয় এবং OPTIONS প্রিফ্লাইট পাঠানো হয় না, তাই আপনার API রুট আলাদাভাবে পরীক্ষা করুন: curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control

**TLS পরীক্ষা কী যাচাই করে (সার্টিফিকেটের মেয়াদ, TLS 1.0 ও 1.1)?**

এটি পোর্ট 443-এ সংযোগ করে এবং সার্টিফিকেট চেইন ও হোস্টনেম যাচাই করে। যে সার্টিফিকেট যাচাইয়ে টেকে না তার তীব্রতা উচ্চ, মেয়াদোত্তীর্ণ সার্টিফিকেট এর পাশাপাশি ক্রিটিকাল হিসেবে চিহ্নিত হয়, আর যার 15 দিনের কম বাকি সেটি মাঝারি; অন্যথায় সাবজেক্ট, ইস্যুকারী, মেয়াদ শেষের তারিখ ও SAN নামগুলো পাস হিসেবে দেখানো হয়। আলোচনায় ঠিক হওয়া প্রোটোকল TLS 1.2 বা TLS 1.3 হতে হবে, এর চেয়ে পুরোনো যেকোনোটি উচ্চ। এরপর এটি আলাদাভাবে একটি TLS 1.0 ও একটি TLS 1.1 হ্যান্ডশেক চেষ্টা করে: যে সার্ভার এর কোনোটি গ্রহণ করে সেটি মাঝারি ফাইন্ডিং পায়, কারণ RFC 8996 দুটিকেই অপ্রচলিত ঘোষণা করেছে। স্ক্যানারের নিজের OpenSSL পুরোনো সংস্করণ দিতে না পারলে অনুমান না করে কিছুই রিপোর্ট করা হয় না। nginx-এ সমাধান হলো ssl_protocols TLSv1.2 TLSv1.3; তারিখগুলো নিজে এই কমান্ডে দেখুন: echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates

**এটি কি যাচাই করে যে HTTP থেকে HTTPS-এ রিডাইরেক্ট হয়?**

হ্যাঁ। এটি রিডাইরেক্ট অনুসরণ না করে http://your-site/ অনুরোধ করে। কোনো https:// ঠিকানায় 301 বা 308 পাস। HTTPS-এ 302, 303 বা 307 নিম্ন, কারণ ব্রাউজার অস্থায়ী রিডাইরেক্ট মনে রাখে না, তাই প্রতিটি নতুন ভিজিট একটি এনক্রিপশনহীন অনুরোধ দিয়ে শুরু হয়। এনক্রিপশনহীন HTTP-তে পরিবেশিত পেজ (2xx উত্তর) উচ্চ। পোর্ট 80 একেবারেই সাড়া না দিলে সেটি তথ্যমূলক, ব্যর্থতা নয়। nginx-এ সমাধান হলো server { listen 80; return 301 https://$host$request_uri; }, তারপর Strict-Transport-Security যোগ করুন। নিজে এই কমান্ডে দেখুন: curl -I http://your-site/

**এটি কোন HTTP মেথডগুলো চিহ্নিত করে (TRACE, PUT, DELETE)?**

এটি আপনার হোমপেজে একটি OPTIONS অনুরোধ পাঠায় এবং Allow হেডার পড়ে, Allow না থাকলে Access-Control-Allow-Methods। TRACE, TRACK, PUT বা DELETE ঘোষিত থাকলে তীব্রতা মাঝারি; শুধু PATCH বা CONNECT নিম্ন; কেবল সাধারণ পড়ার মেথড থাকলে পাস। সার্ভার এই দুটি হেডারের কোনোটিই না পাঠালে কিছু রিপোর্ট হয় না। কোনো মেথড ঘোষিত থাকলেই তা কাজ করে এমন প্রমাণ হয় না, তাই কিছু বদলানোর আগে নিশ্চিত হয়ে নিন। TRACE অনুরোধের হেডার, কুকি সহ, প্রেরকের কাছে ফেরত পাঠাতে পারে (Cross-Site Tracing)। nginx ডিফল্টভাবে TRACE প্রত্যাখ্যান করে; Apache-এ TraceEnable Off সেট করুন। PUT ও DELETE কেবল যেসব API রুটের দরকার সেগুলোতে সীমিত রাখুন, অথেনটিকেশনের পেছনে। নিজে এই কমান্ডে দেখুন: curl -X OPTIONS -i https://your-site/

**এটি ডিরেক্টরি লিস্টিং ("Index of /") কীভাবে ধরে?**

এটি 7টি পাথ অনুরোধ করে: /, /static/, /assets/, /uploads/, /images/, /files/ এবং /backup/। যে পাথ HTTP 200 দিয়ে এমন পেজ ফেরত দেয় যার টাইটেল বা প্রধান হেডিং "Index of /" দিয়ে শুরু, সেটি মাঝারি তীব্রতায় রিপোর্ট হয় (CWE-548), কারণ লিস্টিং এমন ফাইল দেখিয়ে দেয় যেগুলোর কোথাও লিংক নেই, যেমন ব্যাকআপ, এক্সপোর্ট ও পুরোনো সংস্করণ। কোনো পাথ এমন না করলে পরীক্ষা পাস; সাইটে পৌঁছানো না গেলে এটি সম্পন্ন হয়নি হিসেবে দেখানো হয়। nginx-এ সমাধান হলো autoindex off; (এটিই ডিফল্ট, তাই স্পষ্টভাবে লেখা autoindex on খুঁজুন), Apache-এ Options -Indexes, তারপর সংবেদনশীল সবকিছু ওয়েব রুটের বাইরে সরান। নিজে এই কমান্ডে দেখুন: curl -s https://your-site/uploads/ | head -20

**এটি কি মিশ্র কনটেন্ট আর HTTP দিয়ে পাঠানো ফর্ম ধরে?**

হ্যাঁ, হোমপেজে। সার্ভার যেভাবে HTML পাঠায় সেভাবেই এটি পড়ে (কোনো JavaScript চালানো হয় না) এবং যেসব script, link, iframe বা img ট্যাগের src বা href http:// দিয়ে শুরু, সেগুলোর তালিকা দেয়। এর কোনোটি .js বা .css ফাইল হলে ফলাফল মাঝারি, কারণ পথে বদলে দেওয়া স্ক্রিপ্ট বা স্টাইলশিট আপনার HTTPS পেজের ভেতরে চলে; শুধু ছবি ও ফ্রেম হলে নিম্ন; একটিও না থাকলে পাস (CWE-311)। যে ফর্মের action http:// দিয়ে শুরু, সেটি উচ্চ হিসেবে দেখানো হয় (CWE-319), কারণ এতে যা লেখা হয়, পাসওয়ার্ডসহ, সব এনক্রিপশন ছাড়া যায়। সমাধান: এই URLগুলো https:// করুন বা রিলেটিভ করুন, আর নিরাপত্তা জাল হিসেবে Content-Security-Policy: upgrade-insecure-requests হেডার যোগ করুন। নিজে যাচাই করুন: curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"

**এটি robots.txt আর security.txt-এ কী পরীক্ষা করে?**

robots.txt: এটি /robots.txt আনে এবং উত্তর HTTP 200 সহ টেক্সট ফাইল হলে প্রথম 8000 অক্ষরের Disallow লাইনগুলো পড়ে। যে Disallow পাথে admin, internal, private, backup, config, staging, test, api, secret, dev শব্দগুলোর কোনোটি থাকে সেটি নিম্ন হিসেবে দেখানো হয় (CWE-200): robots.txt সবার জন্য খোলা এবং শুধু নিয়ম মানা ক্রলারদের দূরে থাকতে বলে, তাই এই পাথগুলো লিখে রাখা মানে সেগুলোর বিজ্ঞাপন দেওয়া। লগইন দিয়ে সেগুলো সুরক্ষিত করুন, আর পেজ সার্চের বাইরে রাখতে noindex ব্যবহার করুন। security.txt: এটি /.well-known/security.txt চায়, যা RFC 9116 নির্ধারিত জায়গা, এবং ফাইলে Contact: লাইন থাকলে তা আপনার পক্ষে গোনে। ফাইল না থাকলে নম্বর কাটে না। RFC 9116 একটি Expires: ফিল্ডও বাধ্যতামূলক করে, যা স্ক্যান যাচাই করে না, তাই দুটোই প্রকাশ করুন, যেমন Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z। নিজে যাচাই করুন: curl -s https://your-site/.well-known/security.txt

**CAA যাচাই কী খোঁজে এবং CAA রেকর্ড কীভাবে যোগ করব?**

এটি আপনার দেওয়া হোস্ট নামের CAA রেকর্ড (RFC 8659) Cloudflare-এর DNS-over-HTTPS দিয়ে খোঁজে। রেকর্ড পেলে যাচাই পাস হয় এবং প্রমাণে সর্বোচ্চ 5টি দেখায়; একটিও না পেলে "No CAA record" কম গুরুত্বে জানায়, কারণ তখন যেকোনো পাবলিক সার্টিফিকেট কর্তৃপক্ষ (CA) ওই নামের জন্য সার্টিফিকেট দিতে পারে। CAA রেকর্ডে আপনি আসলে যে CA ব্যবহার করেন সেগুলোর তালিকা থাকে, যেমন your-site. IN CAA 0 issue "letsencrypt.org", সঙ্গে রিপোর্ট পেতে 0 iodef "mailto:security@your-site"। প্রতিটি ব্যবহৃত CA-এর জন্য একটি issue লাইন যোগ করুন, আর ওয়াইল্ডকার্ড সার্টিফিকেট অন্য CA থেকে আসার কথা হলে একটি issuewild লাইন। নিজে যাচাই করুন: dig CAA your-site

**www বা কোনো সাবডোমেন স্ক্যান করলে CAA, SPF বা DMARC নেই বলে কেন দেখায়?**

প্রতিটি DNS যাচাই ঠিক আপনার দেওয়া নামেই চলে, তাই www.example.com খোঁজা হয় www.example.com হিসেবেই, example.com হিসেবে নয়, আর তিনটি রেকর্ড আলাদাভাবে উত্তরাধিকার পায়। CAA: যে সার্টিফিকেট কর্তৃপক্ষ www.example.com-এ CAA রেকর্ড পায় না, সে উপরে example.com-এ গিয়ে সেটি ব্যবহার করে (RFC 8659, অনুচ্ছেদ 3), তাই সাবডোমেনে "No CAA record" ভুল সতর্কতা হতে পারে। DMARC: প্রাপকেরা সাংগঠনিক ডোমেনের নীতিতে ফিরে যায়, যা sp= দিয়ে সাবডোমেনের জন্য আলাদা নীতি ঠিক করতে পারে (RFC 9989, যা RFC 7489-এর জায়গা নিয়েছে), তাই _dmarc.www.example.com-এ রেকর্ড না থাকলেও সাধারণত _dmarc.example.com সেটি ঢেকে দেয়। SPF: এতে উত্তরাধিকার নেই (RFC 7208), তাই ওই নামের জন্য "No SPF record" ঠিক; যে হোস্ট নাম ইমেইল পাঠায় না সেটি v=spf1 -all প্রকাশ করতে পারে। ব্যর্থ DNS খোঁজও রেকর্ড নেই হিসেবে দেখায়। www ছাড়া মূল ডোমেনও স্ক্যান করুন, অথবা dig CAA example.com ও dig TXT _dmarc.example.com দিয়ে নিশ্চিত হন

## গোপনীয়তা ও নিরাপত্তা-এ আরও

- [Image Scrub](https://discuvr.org/image-scrub/?hl=bn)

## প্রায়ই এগুলোর সঙ্গে ব্যবহৃত হয়

- [আমার IP কী](https://discuvr.org/what-is-my-ip/?hl=bn)
- [পাসওয়ার্ড জেনারেটর](https://discuvr.org/password-generator/?hl=bn)

---

Part of Discuvr (https://discuvr.org/): Discuvr is a collection of free, focused tools for day-to-day professional work - office and data utilities, legal and compliance helpers, privacy and security checks, and developer formatters. Every tool has its own page, and most can also be called from ChatGPT or Claude over MCP.