في القصة المستمرة: أكدت لي شركة Network Solutions أنهم لم يروا أي سجلات DNSSEC مرتبطة بالنطاق من جانبهم… لذا… هل هذا شبح في الآلة من مسجّل النطاق السابق؟
على أي حال، بما أنهم لا يستطيعون حذف ما غير موجود، فإننا نحاول إضافة سجلات جديدة ونأمل أن تحل محل السجلات الشبحية وتعيد كل شيء إلى ما ينبغي أن يكون عليه.
هذه بالتأكيد أغرب مشكلة DNS واجهتها على الإطلاق.
أوافقك الرأي ![]()
هذا خادم أسماء (nameserver) تابع لـ .org
يجب تنفيذ ضوابط DNSSEC عند مسجّل النطاق الخاص بك، لأن سجلات DS الخاصة بنطاقك، مثل سجلات اللاصق (glue records)، يجب أن تكون موجودة على خوادم أسماء نطاق المستوى الأعلى (TLD nameservers). لن يكون لمزوّد خدمة DNS الخاص بك أي سيطرة على ذلك.
ما زلت أرى السجلات موجودة هناك:
pidforum.org. 86400 IN DS 30311 8 2 A75DEB1CF7CE3EE94899941C7E92B72A7E83A7B5DCD3717D6731804B 4D851E46
pidforum.org. 86400 IN RRSIG DS 8 2 86400 20211008152857 20210917142857 39681 org. goYqP/QgI0+8jN/pL3yVhZfeWAGXoibV/DHDduL+DWj47b9U18nRKctf OJB+TNznVcQeEtG67UM5O+nr5FmrfzowCHvgRsUaanVlo1nCXjlOg9eV KqZmkVcN2no1oklqbQBtN7GDqtX+G1BYmQCaIWbZ38PGBAnc2aQ0Ftr8 cAg=
;; Received 252 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 93 ms
ولا يزال المحلّل يُظهر خطأً:
يجب أن تضايقهم حتى يحصلوا على شخص من جانبهم لإصلاح هذا الأمر - هذه هي مسؤولية مسجّل النطاق تصحيحها.
قد تنجح أيضاً بالتحدث إلى مسجّل النطاق السابق وطلب منهم التوقف عن تقديم سجلات اللاصق وسجلات DS لمنطقتك.
تعديل:
في الوقت الحالي، سجلات منطقة .org المنشورة لديك هي:
pidforum.org. 86400 in ns lee.ns.cloudflare.com.
pidforum.org. 86400 in ns jillian.ns.cloudflare.com.
pidforum.org. 86400 in ds 30311 8 2 (a75deb1cf7ce3ee94899941c7e92b72a7e83a7b5dcd3717d6731804b4d851e46 )
pidforum.org. 86400 in rrsig ds 8 2 86400 20211005151127 20210914141127 39681 org. bDTwz7kYTRJXb7LuN1qj1mCBtiq0DMUM9dNzppGgR/+pTX6b0cWuMhFngI1zMk870aJU6BozFxwuv/AhUHl3y3/PHrjDOsSVA1SubPZM/tC/ylWSUexcVxVhQkQRLkpKPUlL61sZTX8VNca3MBWXx/kFSt7uThR0IYeW+2fQXqQ=
لقد حصلت صباح اليوم على تأكيد من مسجل النطاق السابق (Argeweb في هولندا) بأنه أزال أخيرًا سجلات DS الخاصة بهذا النطاق من نظامه.
لذا، في هذه المرحلة، أؤكد أن Network Solutions (المسجل) قد تأكد من وجود سجلات DS صحيحة (جديدة) من Cloudflare (خادم الأسماء)، وأن المسجل السابق (Argeweb) قد أزال سجلاته.
آمل ألا يتبقى سوى انتظار استقرار كل ذلك على مستوى العالم. تم تأكيد Network Solutions و Cloudflare في وقت متأخر من يوم الأربعاء، بينما جاء تأكيد Argeweb هذا الصباح. ربما يتسنى حل كل هذا خلال عطلة نهاية الأسبوع. أصابع متقاطعة
من المفترض ألا يستغرق الأمر أكثر من يوم.
يوجد الكثير من ‘كان ينبغي’ في كل هذا… كان ينبغي على Argeweb تعطيل DNSSEC قبل نقل النطاق من الأساس. كان ينبغي أن تكون Network Solutions قادرة على رؤيته وتعطيله من جانبهم عند نقله.
‘كان ينبغي’ هو لعنة هذا المشروع بأكمله. ![]()
لا أعرف بالضبط الواجهة خلف مسجّر السجلات ومشغّلي منطقة الجذر؛ سواء كانوا يرسلون فروقًا أو تحديثات يومية كاملة. لكن يجب أن يكونوا على دراية بالعملية وقد قاموا بالشيء الصحيح.
وبالمثل، كان على Network Solutions استيراد سجلات DS السابقة إلى واجهتهم أثناء نقل المنطقة. من المفترض أنهم نقلوا أيضًا سجلات NS، لكن ربما كان عليك توفيرها؟
إن إدارة DNS صعبة، وإدارة DNSSEC أكثر صعوبة.
كان ينبغي / كان يمكن / كان سيحدث
على الأقل أنت تعرف ما هي المشكلة وكيفية إصلاحها.
الموردون يكادون يلومون الشخص الآخر.
أرى اليوم أن بيانات DS الخاصة بـ pidforum.org لم تتغير.
هل قمت بإضافة السجلات الصحيحة إلى واجهة Network Solutions؟
نعم، تمت إضافة السجلات الصحيحة في أواخر الأسبوع الماضي إلى Network Solutions، وانتظرنا طوال عطلة نهاية الأسبوع… دون أي تغيير. سجل DS الخبيث 30311 لا يزال مختبئًا في مكان ما، ولا يبدو أن أي شخص قادر على تغييره.
يمكنك رؤية السجلات الصحيحة والخاطئة معًا في ذلك…
السجل الصحيح غير موجود على مستوى .org، وهو المستوى الذي يهم.
يجب أن تلح على Network Solutions لنشر السجل الصحيح.
هل تملك لقطة شاشة لهذا الجزء من إعدادات النطاق لديك؟
لا تقدم حلول الشبكة واجهة إدارة عامة لأي جانب من جوانب DNSSEC. هناك مجموعة واحدة فقط ضمن فريق الدعم تتعامل مع هذا الأمر، ويجب عليك التفاعل معهم عبر البريد الإلكتروني.
لا، لستُ أمزح.
تمكنتُ اليوم من الوصول إلى مستوى دعم قد يكون لديه بعض المعلومات، وأخبروني بأنهم سيعطونني إجابة خلال 24 إلى 48 ساعة أخرى.
لا يزال هذا غير مرتب. أوه، أشعر بآلامك يا @griffey
شغّلت فحصًا هنا. يمكنك رؤية مكان KeyTag 30311 في النتائج.
خطأ: يوقّع DNSKEY 2371 مجموعة سجلات DNSKEY، لكن لم يُعثر على سجل DS مؤكد في المنطقة الأصلية. لم تُنشأ سلسلة الثقة.
خطأ فادح: تحتوي المنطقة الأصلية على سجل DS موقّع (الخوارزمية 8، KeyTag 30311، نوع البصمة 2، البصمة p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=)، لكن سجل DNSKEY الوجهة غير موجود أو لا يوفّق مجموعة سجلات DNSKEY. لم تُنشأ سلسلة الثقة.
لم يتم الحل بعد. لنفترض أن حلول الشبكة عديمة الفائدة تمامًا عندما يتعلق الأمر بـ DNSSEC ومشاكل النطاقات المعقدة. إنها بالتأكيد تتعلق بـ DNSSEC، وهناك مفتاح dSKEY (30311) واحد عالق في مكان ما في الفضاء، ولا يبدو أن أحدًا يعتقد أنه يمكن إزالته.
انقل نطاقك إلى Google Cloud.
يمكنك بعد ذلك التحكم في إعدادات DNSSEC بنفسك
كآخر تحديث لهذا الأمر… الأمر غير مُرضٍ، لكن شيئًا ما تم تنظيفه وبدأ النطاق في الانتشار. ليس واضحًا ما الذي تغير بالضبط، إذ لا يزال بإمكانني رؤية إدخال DSKEY 30311. ولكن مهما حدث من جانب مسجل النطاق، فإن الأمر يعمل الآن.
شكرًا لك على التحديث

