استقبال عميل جديد في الوكالة: قائمة التحقق من DNS والاستضافة

أول ردّ فعل لوكالة تتسلم عميلًا هو أن تسجّل الدخول إلى مكان ما وتصلح. وهذه أيضًا اللحظة التي يقع فيها أكبر قدر من الأعطال: سجل MX حُذف بالخطأ يقطع البريد، وتغيير خوادم الأسماء يُخفي منطقة لم يصدّرها أحد، وتجديد يفشل لأن بريد صاحب النطاق لم يعد يردّ.

والعميل لا يعرف دائمًا أين توجد صلاحياته. النطاق اشتراه مزوّد سابق، وDNS يخدمه طرف ثالث، والاستضافة cPanel كلمة مروره نائمة في رسالة عمرها عامان. تتعرّف الوكالة على هذه الحالة الفعلية بلمس شيء ما، وهذه أسوأ لحظة للتعرّف عليها.

تفرض قائمة الاستقبال ترتيبًا بسيطًا: نرصد الحالة العامة، ونصدّر ما يمكن تصديره، ونحصل على الصلاحيات الضرورية فقط، ونسجّل كل شيء، ثم نعدّل. وحين تتجاوز المحفظة ما يحتفظ به شخص واحد في ذهنه، يصبح هذا الطقس الذاكرة الوحيدة الموثوقة للوكالة.

يعود الاعتراض في كل استقبال: من يمسك العلاقة ومن يملك النطاق؟ الجواب واحد لكل العملاء. يبقى العميل هو صاحب النطاق المسجَّل، وتتلقى الوكالة صلاحيات مفوّضة. أنتم تديرون العلاقة والعمليات اليومية، وتبقى بنية الاستضافة التحتية من شأن المنصة، ويحتفظ العميل بملكية ما يحمل اسمه.

يحمي هذا التقسيم الطرفين. إذا انتهت المهمة يغادر العميل بنطاقه دون تفاوض. وإذا غيّر العميل جهة الاتصال لا تُحاسَب الوكالة على اسم لم تملكه قط.

يبقى الاعتراض الذي ستسمعه: طلب الصلاحيات يبدو ثقيلًا. أجيبوا بقائمة دنيا ورسالة جاهزة (أدناه). اطلبوا ما تحتاجه المهمة فقط، طبقةً طبقة، وبأدنى صلاحية تكفي. الجدول التالي هو الأساس.

قبل طلب أي كلمة مرور يمكنك أن تقرأ الكثير علنًا. نفّذ هذه الأوامر من جهازك واحتفظ بالمخرجات في ملف مؤرَّخ: هذه حالتك المرجعية.

يعيد dig +short NS example.com خوادم الأسماء التي تخدم المنطقة، عادةً من سطرين إلى أربعة. وهي تدل على من يدير DNS، وقد يختلف عن المسجّل. ويعيد dig +short A example.com عنوان IP للموقع: قارنه بالاستضافة التي يذكرها العميل. ويعيد dig +short MX example.com أولوية متبوعة باسم خادم؛ والرد الفارغ يعني أن أي بريد لا يُوجَّه عبر هذا النطاق.

يعرض dig +short TXT example.com سجل SPF الذي يبدأ بـ v=spf1 ورموز التحقق للخدمات الخارجية. وتُقرأ سياسة DMARC بالأمر dig +short TXT _dmarc.example.com. ويُقرأ مفتاح DKIM بالأمر dig +short TXT selector._domainkey.example.com، لكن يجب معرفة المحدِّد: ويظهر في ترويسة رسالة أرسلها العميل.

ثم يعطي whois example.com المسجّل وتاريخ الانتهاء والحالات. وبالنسبة للامتداد ‎.ma يكون الخرج العام أكثر محدودية: وثائق ANRT هي المرجع، ولا يجوز افتراض أنها تتبع قواعد ‎.com.

يحوي whois أربع معلومات تحدد ما يلي. الأولى هي المسجّل، وهو يدل على المكان الفعلي للنطاق. والثانية تاريخ الانتهاء: النطاق القريب من الانتهاء يتقدم على كل شيء آخر.

والثالثة هي الحالة. clientTransferProhibited هو قفل النقل: يرفض السجل أي طلب لنقل النطاق إلى مسجّل آخر. وهو طبيعي ووقائي، لكن يجب أن تطلب من المسجّل رفعه قبل النقل. ويمنع clientUpdateProhibited التعديلات. ويوقف clientHold حل DNS، ويشير redemptionPeriod أو pendingDelete إلى نطاق قيد الحذف: هذه حالة طارئة وليست بندًا من بنود الاستقبال. وتنشر ICANN تعريف كل حالة.

والرابعة هي صاحب النطاق وبريد اتصاله. إذا كان صاحب النطاق مزوّدًا سابقًا أو موظفًا غادر فدوّن ذلك: على العميل تسوية الوضع. وبريد الاتصال الميت يمنع التحقق من نقل أو تجديد، لأن رسائل التأكيد تذهب إلى عنوان لا يقرأه أحد. أما رمز النقل فلا يظهر في whois: يُطلب من المسجّل، وتؤطر سياسة النقل الصادرة عن ICANN القواعد المطبَّقة.

يجب أن تكون الرسالة قصيرة ومتوقعة. إليكم نموذجًا للتكييف: «مرحبًا، لبدء المهمة نحتاج إلى خمسة عناصر: اسم صاحب نطاقكم، والوصول إلى إدارة النطاق لدى المسجّل، والوصول إلى منطقة DNS، والوصول إلى الاستضافة وإلى لوحة البريد. نطلب فقط الصلاحية اللازمة لكل طبقة، ونقترح إيداع الصلاحيات في خزنة مشتركة ننشئها باسمكم. تبقون أصحاب النطاق، ولا نعدّل شيئًا قبل رصد الموجود وتصديره.»

يقول هذا النص ما المطلوب، ولماذا، وكيف يُنقل، وما الذي يحتفظ به العميل. وهو يجيب عن الاعتراض قبل أن يُطرح. أرسله مع رابط خزنتك، وليس مع الصلاحيات نفسها.

تعني status: NXDOMAIN في مخرجات dig أن الاسم غير موجود في DNS العام. تحقق أولًا من الإملاء ثم من whois: النطاق المنتهي أو الموجود في clientHold يردّ بهذه الطريقة. والعلاج لدى المسجّل وليس في المنطقة.

تشير status: SERVFAIL غالبًا إلى خوادم أسماء لا يمكن بلوغها أو إلى DNSSEC معطّل. أعد التنفيذ بالأمر dig +cd example.com: إذا عادت الإجابة بهذا الخيار فالسبب هو التحقق من DNSSEC، ويجب فحص سجل DS لدى المسجّل.

إذا ردّ whois بعبارة No match for فهذا يعني اسمًا غير مسجّل، أو امتدادًا لا يستطيع عميل whois الخاص بك الاستعلام عنه. جرّب خدمة whois الخاصة بالسجل المعني قبل الاستنتاج.

رفض تسجيل الدخول إلى cPanel مع أن كلمة المرور صحيحة يأتي غالبًا من جدار حماية المضيف الذي يحظر عنوان IP الخاص بالوكالة بعد محاولات فاشلة قليلة، أو من حساب معلَّق. اطلب من المضيف رفع الحظر ولا تضاعف المحاولات.

وأخيرًا، نقل مرفوض بينما كل شيء يبدو جاهزًا يعود في الغالب إلى أن clientTransferProhibited ما زال نشطًا، أو إلى بريد اتصال لا يتلقى رسالة التأكيد.

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

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

احفظ الترتيب: الرصد، ثم التصدير، ثم طلب أدنى الحقوق، ثم الاختبار بالقراءة، ثم التسجيل، ثم التعديل.