لا يزال نظام DNS يعمل: خوادم الأسماء والبريد الإلكتروني وDNSSEC على النطاق المرمز

مصدر قلق شائع حول ترميز النطاق (Tokenizing): "هل سيظل موقع الويب الخاص بي يعمل؟ هل سيظل بريدي الإلكتروني يعمل؟ هل سأضطر إلى تعلم بنية DNS جديدة بالكامل؟"

الإجابة المختصرة: نعم، نعم، لا. لا يزال النطاق المرمز نطاق ICANN حقيقياً. ويستمر نظام DNS في القيام بما يفعله بالضبط. يمثل هذا المقال جولة توضح ما يتغير (قليلاً) وما لا يتغير (معظمه).

الفكرة الوحيدة التي يجب أن تضعها في اعتبارك

يحتوي النطاق المرمز على طبقتين:

1. طبقة DNS / السجل (Registry) — وهي نفس الطبقة التي كان يتواجد فيها نطاق .com الخاص بك دائماً. ICANN، مسجل النطاق (Registrar)، خوادم الجذر (root servers)، والمحللات التكرارية (recursive resolvers).
2. الطبقة على السلسلة (On-chain) — عبارة عن رمز غير قابل للاستبدال (NFT) في محفظتك يمثل الملكية.

عملية تحليل DNS — تحويل example.com إلى عنوان IP — تتم بالكامل في الطبقة الأولى. تتعلق الطبقة التي على السلسلة بـ من يتحكم في النطاق، وليس بكيفية تحليله. لا تحتاج المتصفحات، وخوادم البريد الإلكتروني، وشبكات توصيل المحتوى (CDNs)، وسلطات الشهادات (Certificate Authorities) إلى معرفة وجود شبكة البلوكتشين (blockchain) على الإطلاق.

لهذا السبب "لا يزال نظام DNS يعمل". إنه ليس سحراً؛ بل هو نفس نظام DNS المعتاد.

ما الذي لا يتغير

خوادم الأسماء (Nameservers)

لا يزال بإمكانك إعداد خوادم الأسماء لنطاقك. استخدم Cloudflare، Route53، Namecheap، Google Cloud DNS، أو dnsimple — أي خيار كنت تستخدمه من قبل سيكون مناسباً. يترك العديد من الأشخاص مزود DNS الخاص بهم تماماً كما كان عند إجراء عملية الترميز ولا يغيرونه أبداً بعد ذلك.

سجلات A، و AAAA، و CNAME، و ALIAS

جميعها قياسية. سيتم تحليل (resolve) موقع الويب الخاص بك بنفس الطريقة التي كان يتم بها بالأمس.

سجلات MX، و SPF، و DKIM، و DMARC

يستمر البريد الإلكتروني في العمل. عملية الترميز ليس لها أي تأثير على تسليم البريد. إذا كنت تستخدم Google Workspace، أو Microsoft 365، أو Fastmail، أو ProtonMail، أو خادم بريد مستضاف ذاتياً، فلن يتغير أي من ذلك.

سجلات TXT

التحقق من النطاق لأدوات SaaS (مثل Stripe، Slack، GitHub، Atlassian، وغيرها) سيستمر في العمل. يمكنك إضافة وإزالة سجلات TXT حسب الحاجة.

سجلات CAA

تفويض سلطة الشهادات (CAA) — وهي السجلات التي تخبر سلطات الشهادات (مثل Let's Encrypt، وDigiCert) بمن يُسمح له بإصدار شهادات لنطاقك — تستمر في العمل دون تغيير.

شهادات TLS / SSL

لا تزال تحصل على الشهادات من نفس الجهة التي كنت تحصل عليها منها. سواء كانت Let's Encrypt، أو مزود CDN الخاص بك، أو موازن الأحمال (load balancer) الخاص بك — فهو نفس سير العمل. تعمل تحديات ACME (مثل DNS-01 أو HTTP-01) بنفس الطريقة.

التجديدات

لا يزال النطاق يُجدد من خلال المسجل (registrar)، وبنفس الجدول الزمني، ويتم إعداد الفواتير بنفس الطريقة. لا تُدخل عملية الترميز أي آلية تجديد جديدة.

ما الذي يتغير (قليلاً)

من يتحكم في النطاق

قبل الترميز: من يمتلك بيانات تسجيل الدخول إلى حساب المسجل (registrar). بعد الترميز: من يمتلك رمز NFT على السلسلة له السيطرة المطلقة. تربط لوحة تحكم Namefi رمز NFT بحساب المسجل عبر البروتوكول، لذا فإن المحفظة هي مصدر الحقيقة (المرجع الأساسي).

هذا هو الهدف الأساسي من العملية بأكملها. وهو أيضاً السبب الذي يجعلك تأخذ أمان المحفظة على محمل الجد — انظر استرداد النطاق المرمز بعد فقدان المحفظة.

أين تنقر لإدارة DNS

يدير معظم المالكين سجلات DNS داخل لوحة تحكم Namefi بعد الترميز — حيث تتواصل لوحة التحكم مع المسجل نيابةً عنك. إذا كنت تفضل الاحتفاظ بإدارة DNS الخاصة بك في Cloudflare أو Route53 وما إلى ذلك، فما عليك سوى ترك خوادم الأسماء الخاصة بك موجهة إلى هناك وتجاهل واجهة مستخدم DNS داخل التطبيق. كلا الطريقتين تعملان.

نقل النطاق

قبل الترميز: مسار نقل النطاق بين المسجلين (cross-registrar transfer)، باستخدام رموز المصادقة (auth codes) وفترات انتظار تصل إلى 60 يوماً. بعد الترميز: يتم نقل رمز NFT. معاملة واحدة على السلسلة تنقل الملكية. يتم الحفاظ على مزامنة السجل من جانب المسجل بواسطة البروتوكول. هذا أسرع بكثير — وهذا هو السبب في أن أسواق النطاقات المرمزة لا تحتاج إلى نظام الضمان (escrow) التقليدي (انظر من الإدراج إلى التسوية).

لا يزال بإمكانك إجراء عملية نقل تقليدية عبر المسجل إذا أردت؛ فالطبقة التي على السلسلة لا تمنع ذلك.

بروتوكول DNSSEC على النطاق المرمز

يعمل بروتوكول الامتدادات الأمنية لنظام أسماء النطاقات (DNSSEC) بشكل طبيعي. إذا قمت بتمكينه من قبل، فسيبقى ممكّناً. وإذا لم تكن قد فعلت ذلك، فيمكنك تمكينه بعد الترميز. تمر سلسلة الثقة (chain of trust) عبر السجل (registry) كالمعتاد — ولا تقع الطبقة التي على السلسلة في أي مكان على هذا المسار. (خلفية: تُعرّف وثيقة RFC 4033 البروتوكول؛ وتصف شروحات حفل KSK الخاص بـ ICANN عملية جذر الثقة).

بعض الملاحظات العملية:

• إذا كان نظام DNS الخاص بك في Cloudflare أو Route53، فإن هؤلاء المزودين يتولون توقيع DNSSEC نيابةً عنك. ما عليك سوى تفعيله من جانب المسجل، وهو ما يمكنك القيام به من خلال لوحة تحكم Namefi.
• يتم إدارة سجلات DS على مستوى المسجل / السجل (registrar / registry). إذا قمت بتدوير مفاتيح KSK، فستقوم بنشر سجلات DS جديدة من خلال نفس مسار العمل الذي استخدمته دائماً.
• تكون إخفاقات DNSSEC مرئية في الأدوات القياسية (مثل dig +dnssec، وdnsviz.net، ومحلل DNSSEC من Verisign). لا تؤدي عملية الترميز إلى ظهور أي نمط فشل جديد.

إمكانية تسليم البريد الإلكتروني بعد الترميز

يشعر مستخدمو البريد الإلكتروني بالقلق أكثر من غيرهم، لذا لنكن واضحين: لا شيء يتغير فيما يخص البريد الإلكتروني.

لا تزال سجلات MX الخاصة بك توجه البريد إلى مزودك. ولا يزال SPF يصرح للمرسلين. ولا يزال DKIM يوقع الرسائل الصادرة. ولا يزال DMARC يفرض التوافق (alignment). تظل السمعة (Reputation) مرتبطة بعنوان IP المُرسل / النطاق، ولا يزال نطاقك هو نطاقك — بنفس الاسم، وبنفس العمر، وبنفس السجل التاريخي.

إذا كنت تقوم بتغيير مزودي البريد في نفس وقت إجراء الترميز تقريباً (وهي مناسبة شائعة لتنظيم الأمور)، فقم بإجراء هذه التغييرات واحداً تلو الآخر. ليس لأن الترميز يعطل أي شيء؛ بل إنها مجرد ممارسة تشغيلية جيدة أن تقوم بتغيير متغير واحد في كل مرة.

مرجع سريع: السجلات الشائعة

الطبقة "المرمزة" بأكملها تتواجد بجانب نظام DNS، وليس فوقه.

أين يخطئ الناس في الواقع

• نسيان المحفظة التي تحتوي على رمز NFT. هذه ليست مشكلة في DNS، ولكنها السبب الأول لفقدان الأشخاص لإمكانية الوصول إلى نطاق مرمز. قم بتدوينها وحفظها جيداً.
• تبديل خوادم الأسماء ومزود DNS في نفس الوقت. هذا أمر مغرٍ، ولكنه يؤدي إلى مخاطر غير ضرورية. قم بالترميز أولاً، ثم غيّر مزودي DNS لاحقاً إذا أردت.
• افتراض أن الطبقة التي على السلسلة تدفع تغييرات DNS تلقائياً. هذا غير صحيح. لا تزال تغييرات DNS تمر عبر مزودي DNS وتستغرق وقت الانتشار الطبيعي (من دقائق إلى بضع ساعات، بناءً على قيم TTL).
• تعطيل DNSSEC أثناء عملية النقل. إذا قمت بإيقاف تشغيل DNSSEC ثم تشغيله، فافعل ذلك بشكل سليم مع تحديثات سجل DS المناسبة. حيث إن تطبيق DNSSEC بشكل غير مكتمل (Half-rolled) يؤدي إلى كسر عملية التحليل (resolution) في كل مكان.

إخلاء مسؤولية ودي (اقرأني!)

نحن لسنا محامين، أو محاسبين، أو مستشارين ماليين، أو أطباء — ولا يوجد أي شيء في هذا المقال يمثل نصيحة قانونية، أو مالية، أو ضريبية، أو محاسبية، أو طبية، أو أي نوع آخر من النصائح المهنية. نحن نكتب هذه المقالات لتثقيف أنفسنا وكوسيلة راحة لعملائنا. قد تكون المعلومات الواردة هنا قديمة، أو خاصة بمنطقة جغرافية معينة، أو مجرد معلومات خاطئة — فنحن نخطئ أيضاً.

لاتخاذ أي قرار مهم، يرجى استشارة محترف حقيقي (بجدية!). أو إذا لم يكن هذا أسلوبك، فاسأل صديقاً، أو اسأل منصة X (تويتر سابقاً)، أو Reddit، أو اسأل الذكاء الاصطناعي، أو اسأل وسيطاً روحياً. باختصار: قم بالبحث الخاص بك (DOYR - Do Your Own Research). دعونا نتعلم ونستمتع.

الخلاصة

• ترميز النطاق لا يحل محل نظام DNS. يستمر نظام DNS في أداء عمله المعتاد.
• تستمر جميع خوادم الأسماء الخاصة بك، وموقع الويب، والبريد الإلكتروني (MX/SPF/DKIM/DMARC)، وDNSSEC، وCAA، وشهادات TLS في العمل دون تغيير.
• ما يتغير هو الملكية: رمز NFT الموجود في محفظتك هو نقطة التحكم المطلقة الجديدة. تتم عمليات النقل على السلسلة بدلاً من المرور عبر بيروقراطية مسجل النطاق.
• يمكنك الاحتفاظ بإدارة DNS الخاصة بك في Cloudflare، أو Route53، أو في أي مكان توجد فيه. أو إدارتها من خلال Namefi. كلا الخيارين صحيحان.
• الآثار العملية: لا يمكن التمييز تشغيلياً بين نطاق .com المرمز ونطاق .com غير المرمز، حتى تنتقل إلى مرحلة بيعه أو نقله — وفي هذه النقطة، تجعل الطبقة التي على السلسلة كل شيء أسرع بشكل كبير.

للحصول على شرح تفصيلي على مستوى المشغل حول كيفية الترميز في المقام الأول، انظر كيفية ترميز نطاق .com الخاص بك.