↩️ بحث IP العكسي
اعثر على اسم المضيف خلف أي عنوان IPv4 أو IPv6 عبر DNS العكسي (PTR) مع التحقق الأمامي.
🔐 تُرسل الاستعلامات إلى خوادم DNS-over-HTTPS عامة (Cloudflare وGoogle) التي تستقبل العنوان المفحوص. لا يخزّن 0Appz أي شيء.
📋 نتيجة DNS العكسي
كيفية استخدام هذه الأداة
نظرة عامة
بحث IP العكسي ينفّذ بحث DNS عكسي لأي عنوان IPv4 أو IPv6 عبر DNS-over-HTTPS ثم يخطو خطوة إضافية: التحقق الأمامي. أولاً يكشف سجل PTR في نطاق in-addr.arpa أو ip6.arpa اسم المضيف، ثم يحل الأداة اسم المضيف أمامياً ويتأكد من عودته إلى العنوان المُدخل. هذا التحقق (FCrDNS) هو نفسه الذي تتحقق منه خوادم البريد قبل قبول الرسائل، ما يجعله مفيداً لتشخيص قابلية التسليم وفحص إعداد الخوادم والتحقق من الزواحف وتحليل السجلات المشبوهة. تنتقل الاستعلامات إلى خوادم DoH من Cloudflare أو Google ولا يُخزَّن شيء.لماذا تهم المطابقة الأمامية
سجل PTR وحده لا يثبت الكثير: من يتحكم في DNS العكسي لكتلة يمكنه توجيه PTR إلى أي اسم مضيف. وتسدّ المطابقة الأمامية هذه الثغرة بحل الاسم العائد والتحقق من أنه يشير إلى العنوان نفسه. وتعتمد خوادم البريد على هذا الفحص تحديداً، فالتطابق المكسور سبب شائع لرفض الرسائل أو وسمها كمهملات. تفحص الأداة الاتجاهين وتُبيّن كل خطوة.
المواصفات التقنية
| الخاصية | السلوك |
|---|---|
| الإدخال | أي عنوان IPv4 أو IPv6 |
| الفحوص | PTR ثم تأكيد A/AAAA الأمامي |
| النقل | DNS over HTTPS عبر Cloudflare أو Google |
| الحكم | مؤكد (FCrDNS) أو غير متطابق |
| ما يخزنه 0Appz | لا شيء |
| التكلفة | مجاناً، بدون حساب واستعلامات غير محدودة |
الخصوصية: الاستعلامات تذهب مباشرة إلى الخوادم
تنطلق الفحوص من متصفحك إلى خادم DoH الذي يرى العناوين كأي خادم. لا يعمل 0Appz وسيطاً ولا يخزنها.
التشخيص بـDNS العكسي
- غياب PTR على عنوان خادم بريد يكسر التسليم غالباً.
- PTR بلا مطابقة أمامية أسوأ من عدمه لتقييم المهملات.
- يوفر المستضيفون ضبط PTR عادة من لوحتهم.
- تحقق من ادعاءات الزواحف عبر PTR والسجل الأمامي.
- العناوين المشتركة قد تحمل تاريخاً غريباً: افحص قبل الحجب.
اقرأ أيضاً أدوات المطورين لـDNS وIP وSSL وwhois.
DNS العكسي وسجلات PTR وتحويل الأسماء
يحول استعلام DNS العادي اسماً إلى عنوان؛ ويفعل DNS العكسي العكس سائلاً عن اسم المضيف المرتبط بعنوان. ويعمل عبر سجلات PTR المخزنة في منطقة خاصة تُبنى من الأوكتيتات المعكوسة للعنوان، ويتحكم بالإجابة مالك كتلة IP, عادة مزود الخدمة أو الاستضافة أو منصة السحابة لا صاحب الموقع. وهذه الملكية تفسر النتائج: فعنوان منزلي يحل غالباً إلى اسم عام لمزود الخدمة كمعرّف مجمّع، بينما قد يحل عنوان خادم إلى اسم ذي معنى. ولخوادم البريد يهم DNS العكسي كثيراً: تفحص معظم الأنظمة المستقبِلة وجود سجل PTR وتطابقه مع الاستعلام الأمامي للاسم نفسه، وهو فحص يُعرف بـ forward-confirmed reverse DNS. وغياب السجلات أو عدم تطابقها سبب شائع لرفض البريد المشروع أو وسمه كبريد مزعج. وغالباً تعيد الاستضافة المشتركة ونسخ السحابة اسم مزود لا علاقة له بالموقع المستضاف، وقد لا تملك العناوين خلف NAT لدى المشغل سجل PTR أصلاً. وللتشخيص يساعد DNS العكسي في تحديد مزود العنوان وهل هو منزلي أو محمول أو مركز بيانات. ولا يكشف شخصاً، وغياب السجل ليس خطأ. ويجري الاستعلام من متصفحك ولا يخزّن شيئاً.
الأسئلة الشائعة
ما هو DNS العكسي؟ +
يربط DNS العكسي (rDNS) عنوان IP باسم مضيف عبر سجلات PTR في نطاقي in-addr.arpa (IPv4) وip6.arpa (IPv6). يستعلم بحث IP العكسي عن هذه السجلات عبر DNS-over-HTTPS.
ما هو التحقق الأمامي (FCrDNS)؟ +
سجل PTR وحده لا يثبت شيئاً, فمن يتحكم بالنطاق يستطيع ضبطه. يتحقق FCrDNS من أن اسم المضيف يعود أيضاً إلى نفس العنوان. تشترط خوادم البريد غالباً FCrDNS.
لماذا لا تملك عناوين كثيرة سجل PTR؟ +
الاتصالات المنزلية لا تنشر PTR عادة، وكثير من المضيفين يضيفه عند الطلب فقط. غياب PTR طبيعي لعناوين العملاء وإشارة تحذير لخوادم البريد.
هل الاستعلام خاص؟ +
نعم. تنتقل الاستعلامات من متصفحك إلى خوادم DNS-over-HTTPS من Cloudflare أو Google مع تبديل بينهما. لا يُرسل شيء إلى 0Appz ولا يُحفظ سجل.