ضبط DNS العكسي على عناوينك

أين يقع السجل

لكل عنوان يتم توجيهه إلى نسختك سجل PTR قابل للتحرير. تعرض اللوحة هذه السجلات تحت النسخة، صف واحد لكل عنوان. تكشف واجهة برمجة التطبيقات نفس الشيء:

curl -s https://paragonvps.com/api/v1/instances/<instance-id>/addresses -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[].ptr'

تعيين واحد:

curl -s -X PUT https://paragonvps.com/api/v1/addresses/<address-id>/ptr -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"ptr":"mail.example.com"}'

يجب أن يكون السجل الأمامي موجودًا أولاً

سجل PTR يشير إلى اسم لا يحتوي على سجل A أو AAAA مطابق أسوأ من عدم وجود سجل PTR على الإطلاق. تقرأ خوادم استقبال البريد عدم التطابق كإشارة، وقد ترفض القليل منها الاتصال بناءً على ذلك. انشر السجل الأمامي، وتأكد من تحليله، ثم عيّن سجل PTR.

dig +short mail.example.com A
dig +short mail.example.com AAAA

ثم تحقق من أن الزوج يتوافق في كلا الاتجاهين:

dig +short -x <ipv4>
dig +short -x <ipv6>

يقوم dig -x بتجميع الاسم in-addr.arpa أو ip6.arpa لك، مما يوفر عكس اثنين وثلاثين nibble يدويًا وارتكاب خطأ في أحدها.

الانتشار

تلتقط مناطقنا الموثوقة التغيير في غضون دقيقة تقريبًا. ما يستغرق وقتًا أطول هو التخزين المؤقت السلبي: أي محلل طلب سجل PTR قبل تعيينه قد يحتفظ بالإجابة الفارغة لمدة تساوي الحد الأدنى لـ SOA، وهو في المناطق العكسية ساعة. لا يمكن لأي منا تقصير ذلك، وإعادة محاولة الاستعلام تثبت ذلك فقط.

IPv6

شبكة /64 الموجهة تحتوي على عناوين أكثر مما ستسميها على الإطلاق، واللوحة لن تعرض لك حقل نصي لكل واحد. نهجان عمليان:

• عيّن سجل PTR على العناوين الفردية التي تستخدمها فعليًا. معظم الناس يحتاجون واحدًا بالضبط، للمرسل البريدي.
• اطلب تفويض منطقة ip6.arpa التي تغطي /64 الخاصة بك إلى خوادم الأسماء الخاصة بك، وبعدها يمكنك توليد ما تشاء. التفويض هو تذكرة، يستغرق حوالي يوم، ويتطلب خادمي أسماء يستجيبان بالفعل للمنطقة.

تفاصيل البريد

المنفذ 25 الصادر مغلق على الحسابات الجديدة. اسأل، وقل ما ترسله النسخة وكم تقريبًا، وسنفتحه. يوجد الفحص لأن الخوادم المفتوحة هي واحدة من ثلاثة أشياء تحظرها سياسة الاستخدام المقبول صراحةً.

بمجرد فتحه، يجب أن تتطابق أربع سلاسل: اسم المضيف المرسل، وسجل PTR، واسم HELO، وأي شيء يصرح به سجل SPF الخاص بك. جعل HELO مطابقًا لسجل PTR يزيل السبب الأكثر شيوعًا للرفض الناعم.

swaks --to [email protected] --server localhost --helo mail.example.com

عندما لا يثبت

ثلاثة أسباب، بالترتيب الذي تحدث به:

1. السجل الأمامي مفقود أو خاطئ أو لم ينتشر بعد.
2. العنوان الذي عدلته ينتمي إلى نسخة مختلفة عن تلك التي ترسل حركة المرور.
3. الخفي الخاص بك يربط عنوانًا مختلفًا في /64 عن الذي عينت عليه سجل PTR.

الثالث سهل تفويته وسهل التحقق منه:

ip -brief addr
ss -tlnp

إذا كان عنوان المصدر في اتصال صادر ليس هو الذي يحمل سجل PTR الخاص بك، اربط الخفي بشكل صريح بدلاً من الأمل في أن يختار النواة العنوان الذي كان في ذهنك.