نظام أسماء النطاقات (DNS): كيف يعمل دفتر هاتف الإنترنت، وكيف تدير سجلاتك باحترافية

البشر يتذكّرون الأسماء، أما الآلات فتتخاطب بعناوين رقمية (IP). الـ DNS هو طبقة الترجمة التي تجعل الطرفين يتفاهمان: تكتب أنت example.com، فيتحوّل ذلك إلى عنوانٍ مثل 93.184.216.34. لهذا يُوصف الـ DNS غالبًا بأنه “دفتر هاتف الإنترنت”؛ ومع ذلك فهو أعقد وأذكى بكثير من دفترٍ بسيط، لأنه نظامٌ هرميٌّ موزّع لا تملكه جهةٌ واحدة، ويعمل بآلية تخزينٍ مؤقّتٍ تجعله سريعًا وقابلًا للتوسّع على مستوى الكوكب.

في هذا الدليل نُشرّح الـ DNS من الجذر: ما هو، وكيف يسير الاستعلام خطوةً بخطوة، وكيف تربط نطاقك بمنصة إدارة DNS، ثم نمرّ على أشهر أنواع السجلات وما تفيد به ومتى وكيف تستخدمها، مع أوامر تحقّقٍ عملية.

أولًا: ما هو الـ DNS ولماذا هو هرميّ وموزّع؟

كل جهازٍ على الشبكة يُعرَّف بعنوان IP. لكن حفظ ملايين العناوين الرقمية مستحيلٌ بشريًّا، كما أن العناوين تتغيّر باستمرار. لذا بُني الـ DNS ليؤدّي وظيفتين: ترجمة الأسماء إلى عناوين، وإتاحة تغيير العنوان دون تغيير الاسم.

لو كان الـ DNS قاعدة بياناتٍ مركزيةً واحدة، لانهار تحت ضغط مليارات الاستعلامات اليومية، ولأصبح نقطة فشلٍ وحيدة. الحلّ كان اللامركزية الهرمية: تُقسَّم مسؤولية إدارة الأسماء إلى مستوياتٍ متتالية، كلٌّ منها يعرف فقط الخطوة التالية. تخيّل مساحة الأسماء كشجرةٍ مقلوبة:

إقرأ أيضًا

المساعد الذكي من إليفانتي

النطاقات (Domains): الدليل الشامل لفهم بنية الإنترنت من الجذر إلى التسجيل والإدارة

كل ما تحتاج معرفته عن النطاقات: ما هي، وكيف نشأت الحاجة إليها، وآلية عملها داخل نظام أسماء النطاقات، ومنظومة تسجيلها…

يونيو 30, 2026

حماية البريد الإلكتروني: الدليل الاحترافي لـ SPF وDKIM وDMARC

بروتوكول SMTP وُلد بلا هوية. هذا الدليل يشرح كيف تُغلق طبقات SPF وDKIM وDMARC—ثم ARC وMTA-STS وBIMI—الثغرة التي يستغلها التصيّد…

يوليو 1, 2026

• الجذر (Root) في الأعلى.
• تحته نطاقات المستوى الأعلى (TLD) مثل com. وorg. وnet.، بالإضافة إلى نطاقات الدول مثل sy. وae. وsa..
• تحتها النطاقات الثانية التي نسجّلها نحن مثل example.com.
• ثم النطاقات الفرعية مثل mail.example.com وshop.example.com.

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

اللاعبون الأربعة في كل استعلام

أي عملية بحثٍ عن عنوان تشارك فيها أربعة أنواعٍ من الخوادم:

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

ثانيًا: رحلة الاستعلام خطوةً بخطوة

لنتتبّع ما يحدث فعليًّا عند فتح www.example.com لأول مرة (أي دون أي تخزينٍ مؤقّت سابق):

1. الطلب يبدأ من جهازك. يتحقّق نظام التشغيل أولًا من ذاكرته المحلية وملف hosts. إن لم يجد الجواب، يرسل استعلامًا إلى المُحلِّل التكراري.

2. المُحلِّل يسأل الجذر. المحلّل لا يعرف العنوان، فيسأل أحد خوادم الجذر: «أين www.example.com؟». يردّ الجذر: «لا أعرف العنوان، لكن نطاقات com. يديرها خوادم الـ TLD التالية».

3. المُحلِّل يسأل خادم الـ TLD. يتوجّه إلى خادم com. ويسأل عن النطاق نفسه. يردّ: «لا أملك العنوان، لكن example.com خوادمه المرجعية هي ns1.… وns2.…؛ اسألها».

4. المُحلِّل يسأل الخادم المرجعي. هنا تنتهي الرحلة: الخادم المرجعي يفحص سجلاته ويردّ بالعنوان الفعلي، مثل 93.184.216.34.

5. الجواب يعود إليك. يمرّر المحلّل العنوان إلى جهازك، فيفتح المتصفح اتصال HTTP/HTTPS مع الخادم ويبدأ تحميل الصفحة.

اللافت أن هذه الجولة كاملةً تكتمل عادةً في عشرات الميلي ثانية. والسرّ في السرعة هو التخزين المؤقّت.

التخزين المؤقّت و TTL: لماذا لا تتكرّر الرحلة في كل مرة

لو أُعيدت الجولة الكاملة عند كل طلب، لأصبح الإنترنت بطيئًا ولأُغرِقت خوادم الجذر. لذا يخزّن المحلّل التكراري كل جوابٍ يحصل عليه لمدةٍ زمنيةٍ محدّدة تُسمّى TTL (Time To Live)، وهي قيمةٌ بالثواني تُرفَق بكل سجل.

• TTL قصيرة (مثل 300 ثانية) = انتشار التغييرات أسرع، لكن استعلاماتٌ أكثر وحملٌ أعلى.
• TTL طويلة (مثل 86400 ثانية = يوم كامل) = أداءٌ واستقرارٌ أعلى، لكن التعديلات تأخذ وقتًا أطول لتظهر.

ذكاءٌ إضافيّ: إذا كان المحلّل يحتفظ بسجل NS للخادم المرجعي ولكنه لا يملك سجل A، فإنه يسأل الخادم المرجعي مباشرةً متجاوزًا الجذر والـ TLD، ما يختصر الرحلة كثيرًا.

قاعدة عملية: قبل أي تعديلٍ مخطّطٍ على سجلاتك (كنقل الموقع أو تغيير المزوّد)، اخفض قيمة الـ TTL إلى 300 ثانية قبل 24–48 ساعة من التغيير. بذلك تنتشر التحديثات بسرعةٍ عند التنفيذ. وبعد استقرار الوضع، يمكنك رفعها مجدّدًا.

ثالثًا: ربط النطاق بمنصة إدارة الـ DNS

هنا يخلط كثيرون بين مفهومين منفصلين تمامًا، ويجب فصلهما بوضوح:

• المُسجِّل (Registrar): الجهة التي سجّلت لديها اسم النطاق وتملك حقّ إدارة تفويضه.
• مزوّد استضافة الـ DNS (DNS Host): المنصة التي تستضيف ملف المنطقة (Zone File) الخاص بك وتدير سجلاتك فعليًّا.

قد تكون الجهتان واحدة، وقد تكونان مختلفتين تمامًا. فقد تسجّل النطاق في مكان وتدير سجلاته في منصةٍ أخرى متخصّصة. الرابط بينهما هو سجلات خوادم الأسماء (NS).

آلية التفويض (Delegation)

عند التسجيل، يخزّن سجلّ نطاق المستوى الأعلى (TLD) سجلات NS التي تشير إلى الخوادم المرجعية المسؤولة عن نطاقك. عندما تربط نطاقك بمنصة إدارة DNS، فأنت عمليًّا تخبر المُسجِّل: «حوِّل المسؤولية إلى هذه الخوادم». هذا ما يُعرف بـ التفويض.

الطريق الأول: تغيير خوادم الأسماء (تفويض كامل)

هذا الخيار يسلّم المنطقة بأكملها إلى المنصة الجديدة، وهو الأنسب عندما تريد إدارة كل سجلاتك من لوحةٍ واحدة، أو تحتاج ميزاتٍ متقدّمة مثل توجيه الزيارات أو التحويل الآلي عبر API.

1. أنشئ المنطقة (Zone) للنطاق في منصة الـ DNS الجديدة، وأضِف فيها كل السجلات المطلوبة مسبقًا (A, AAAA, CNAME, MX, TXT…).

2. احصل من المنصة على أسماء خوادمها، عادةً بالشكل:

ns1.dns-provider.example
ns2.dns-provider.example

3. ادخل إلى لوحة المُسجِّل، واستبدل خوادم الأسماء الحالية بالخوادم الجديدة.

4. انتظر انتشار التغيير. تغيير خوادم الأسماء قد يستغرق حتى 24–48 ساعة ليُرى عالميًّا.

الطريق الثاني: تعديل سجلاتٍ مفردة

إذا كانت خوادم الأسماء تشير بالفعل إلى منصتك، فلست بحاجةٍ لتغييرها. يكفي الدخول إلى لوحة إدارة الـ DNS وتعديل السجل المطلوب مباشرةً (مثلًا تغيير سجل A لتوجيه الموقع إلى خادمٍ جديد). هذا التعديل ينتشر عادةً خلال دقائق إلى ساعات بحسب الـ TTL، وهو أسرع بكثير من تغيير خوادم الأسماء.

القاعدة: بدّل خوادم الأسماء عندما تريد جهةً واحدة تدير المنطقة بالكامل. وعدّل السجلات المفردة عندما تحتاج تغييرًا محدودًا وسريعًا فقط.

ملف المنطقة (Zone File)

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

$TTL 3600
@       IN  SOA   ns1.example.com. admin.example.com. (
                  2026062901  ; Serial
                  7200        ; Refresh
                  3600        ; Retry
                  1209600     ; Expire
                  300 )       ; Negative TTL
@       IN  NS    ns1.example.com.
@       IN  NS    ns2.example.com.
@       IN  A     93.184.216.34
www     IN  A     93.184.216.34
@       IN  MX 10 mail.example.com.
@       IN  TXT   "v=spf1 include:_spf.example.com -all"

رابعًا: أشهر سجلات الـ DNS، وفيمَ تفيد، وكيف تُستخدم

كل سجل DNS في جوهره رباعيّ: اسم (الاستضافة المسؤول عنها)، نوع (يحدّد شكل القيمة)، قيمة، وTTL. الاسم @ يشير إلى النطاق الجذر (Apex) نفسه. إليك أكثر الأنواع استخدامًا عمليًّا.

1. سجل A — العمود الفقري للويب

يربط اسم الاستضافة بعنوان IPv4. هو السجل الأساسي الذي يحدّد «أين يعيش موقعك».

example.com.      3600  IN  A   93.184.216.34
www.example.com.  3600  IN  A   93.184.216.34

• يفيد في: توجيه النطاق والنطاقات الفرعية إلى خادمٍ يحمل عنوان IPv4.
• ملاحظة: يمكن أن يحمل الاسم نفسه عدّة سجلات A (توزيع حِمل بأسلوب round-robin).

2. سجل AAAA — نسخة الجيل الجديد

نظير A لكن لعناوين IPv6. أهمّيته تتصاعد مع تحوّل المشغّلين الكبار إلى IPv6.

example.com.  3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

• يفيد في: إتاحة موقعك للعملاء الذين يعملون عبر IPv6.
• تحذير عملي: لا تنشر سجل AAAA إلا إذا كان الخادم يستجيب فعلًا على IPv6؛ السجل المعطوب يُسبّب تأخيرًا في التحميل قبل أن يرجع العميل إلى IPv4.

3. سجل CNAME — الاسم المستعار

يوجّه اسمًا إلى اسمٍ آخر بدل عنوان IP. مفيدٌ لتوجيه نطاقٍ فرعيٍّ إلى خدمةٍ مُدارة.

www.example.com.  3600  IN  CNAME  example.com.
blog.example.com. 3600  IN  CNAME  hosting-platform.example.

• يفيد في: ربط www بالنطاق الجذر، أو ربط نطاقٍ فرعيٍّ بمنصةٍ خارجية (SaaS) تعطيك هدف CNAME.
• لقاعدة الحديدية: لا يمكن لسجل CNAME أن يتعايش مع أي سجلٍ آخر بالاسم نفسه. لذلك لا يجوز وضع CNAME على النطاق الجذر (Apex)، لأنه يحوي بالضرورة سجلات NS وSOA. البديل في هذه الحالة ميزة ALIAS / ANAME التي يوفّرها بعض المزوّدين (تُعرف أيضًا بـ CNAME Flattening).

4. سجل MX — موجّه البريد

يحدّد الخادم المسؤول عن استقبال البريد الإلكتروني للنطاق، مع أولوية (الرقم الأصغر = أعلى أولوية) لتوفير التحويل الاحتياطي.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

• يفيد في: ضمان وصول البريد إلى الخادم الصحيح. ضروريّ لأي نطاقٍ يستقبل بريدًا، حتى لو كنت تستخدم خدمة بريدٍ خارجية.
• خطأ شائع: سجل MX يجب أن يشير إلى اسم استضافة (Hostname) لا إلى عنوان IP، وذلك الاسم يحتاج بدوره إلى سجل A خاصّ به.

5. سجل TXT — النصّ متعدّد الأغراض، وعمود أمان البريد

أُنشئ في الأصل لتخزين نصٍّ حر، لكنه أصبح أساس أمان البريد الإلكتروني والتحقق من الملكية. أشهر استخداماته ثلاثيّة الحماية:

; SPF — تحدّد الخوادم المخوّلة بإرسال بريدٍ باسم نطاقك
example.com.            IN  TXT  "v=spf1 include:_spf.example.com -all"

; DKIM — توقيعٌ تشفيريّ يثبت أن الرسالة لم تُعدَّل
sel._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC — السياسة التي تحدّد ما يحدث للرسائل التي تفشل في التحقق
_dmarc.example.com.     IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; التحقق من الملكية لخدمات خارجية
example.com.            IN  TXT  "google-site-verification=abc123..."

• يفيد في: مكافحة انتحال البريد (Spoofing) والتصيّد، وإثبات ملكية النطاق لمنصاتٍ خارجية.
• نصيحة: ابدأ DMARC بسياسة p=none للمراقبة، ثم تدرّج نحو quarantine فـ reject.

6. سجل NS — من يملك السلطة

يحدّد الخوادم المرجعية المسؤولة عن المنطقة. هو حلقة الوصل بين المُسجِّل ومنصة إدارة الـ DNS، ويُضبط غالبًا عند المُسجِّل.

example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

• يفيد في: تفويض المنطقة كاملةً (أو نطاقٍ فرعيٍّ منها) إلى خوادم أسماءٍ معيّنة.
• قاعدة الاعتمادية: لا تعتمد أبدًا على خادم أسماءٍ وحيد؛ سقوطه يعني سقوط نطاقك بالكامل. استخدم خادمين على الأقل.

7. سجل SOA — بطاقة هوية المنطقة

اختصار Start of Authority. سجلٌّ واحدٌ فريدٌ في رأس كل منطقة، يحمل بياناتها الإدارية: الخادم المرجعي الأساسي، بريد المسؤول، الرقم التسلسلي (Serial) الذي يتغيّر مع كل تعديل، ومؤقّتات المزامنة بين الخوادم.

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
              2026062901  ; Serial (تقليدًا YYYYMMDDnn)
              7200 3600 1209600 300 )

يفيد في: إدارة المزامنة بين الخادم المرجعي الأساسي والثانويّ. عادةً تديره المنصة نيابةً عنك، ونادرًا ما تحرّره يدويًّا.

8. سجل CAA — حارس الشهادات

اختصار Certification Authority Authorization. يحدّد جهات إصدار الشهادات (CA) المخوّلة بإصدار شهادات SSL/TLS لنطاقك. غيابه يعني أن أي جهةٍ تستطيع الإصدار باسمك.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:[email protected]"

يفيد في: تقليل خطر إصدار شهادةٍ احتياليّة لنطاقك. إجراء أمنيّ منخفض الكلفة عالي الأثر.

9. سجل SRV — تحديد موقع الخدمات

يحدّد مضيف ومنفذ خدمةٍ معيّنة، مع أولويةٍ ووزن. يُستخدم في بروتوكولاتٍ مثل SIP وXMPP وبعض خدمات Microsoft 365. صيغة الاسم منظّمة: _service._proto.name.

_sip._tcp.example.com.  3600  IN  SRV  10  60  5060 
 sipserver.example.com.

يفيد في: اكتشاف الخدمات وتوجيهها إلى منافذ غير قياسية.

10. سجل PTR — البحث العكسيّ

عكس سجل A: يربط عنوان IP باسم استضافة، ضمن منطقة in-addr.arpa. مهمّ خصوصًا لخوادم البريد، إذ يرفض كثيرٌ من المستقبلين الرسائل القادمة من عناوين بلا PTR صحيح.

34.216.184.93.in-addr.arpa.  IN  PTR  mail.example.com.

• يفيد في: سمعة خوادم البريد والتشخيص الأمنيّ.
• ملاحظة: غالبًا لا تضبط PTR بنفسك، بل الجهة المالكة لكتلة عناوين IP (المزوّد).

خامسًا: التحقّق العمليّ بأمر dig

أفضل طريقةٍ لفهم الـ DNS هي ملاحظته حيًّا. أداة dig (متوفّرة على لينكس و macOS) تكشف لك السجلات مباشرةً:

# عنوان IPv4 للموقع
dig example.com A +short

# عنوان IPv6
dig example.com AAAA +short

# خوادم البريد
dig example.com MX +short

# خوادم الأسماء المرجعية
dig example.com NS +short

# سجلات النصّ (SPF/DKIM/DMARC وغيرها)
dig example.com TXT +short

# سجل SOA كاملًا
dig example.com SOA

# بحث عكسيّ من عنوان IP إلى اسم
dig -x 93.184.216.34

# تتبّع الرحلة الكاملة من الجذر حتى الخادم المرجعي
dig example.com +trace

# الاستعلام من محلّلٍ عامٍّ محدّد للتحقق من الانتشار
dig @8.8.8.8 example.com A +short

خيار +trace تحديدًا يجعلك تشاهد بعينيك الجولة التي شرحناها: من الجذر، إلى الـ TLD، إلى الخادم المرجعي.

سادسًا: طبقة الأمان — لمحة عن DNSSEC

الـ DNS التقليديّ لم يُصمَّم مع التحقق من الأصالة، ما يجعله عرضةً لهجماتٍ مثل تسميم الذاكرة المؤقّتة (Cache Poisoning) وتزوير الردود. تعالج DNSSEC ذلك بتوقيع بيانات الـ DNS تشفيريًّا، فيتمكّن المحلّل المتحقّق من التأكد أن الجواب لم يُعبَث به.

تعمل DNSSEC عبر سلسلة ثقة (Chain of Trust) تمتدّ من الجذر، إلى الـ TLD، إلى نطاقك. حلقة الوصل الحاسمة هي سجل DS (Delegation Signer) الذي يُضاف عند المُسجِّل، ويحوي بصمةً (Hash) للمفتاح العام لنطاقك، فيربط منطقتك الموقّعة بالسلسلة العالمية. لتفعيلها بنجاح يجب توفّر ثلاثة شروط: أن يكون نطاق المستوى الأعلى موقّعًا، وأن يدعم المُسجِّل سجلات DS، وأن يدعم مزوّد استضافة الـ DNS التوقيع.

تنبيه عند نقل المزوّد: إذا غيّرت خوادم الأسماء دون تحديث أو إزالة سجلات DS القديمة عند المُسجِّل، فقد ينكسر تحليل نطاقك بالكامل (أخطاء SERVFAIL). نسّق بين المُسجِّل والمزوّدين القديم والجديد عند أي ترحيلٍ لمنطقةٍ مفعَّل عليها DNSSEC.

سابعًا: أخطاء شائعة عليك تجنّبها

• وضع CNAME على النطاق الجذر: غير صالحٍ تقنيًّا؛ استخدم A/AAAA أو ميزة ALIAS/ANAME.
• خادم أسماءٍ وحيد: نقطة فشلٍ واحدة؛ استخدم خادمين على الأقل في شبكاتٍ مختلفة.
• MX يشير إلى عنوان IP: يجب أن يشير إلى اسم استضافةٍ له سجل A.
• TTL مرتفعة قبل الترحيل: اخفضها إلى 300 ثانية قبل 24–48 ساعة من أي تغييرٍ مخطّط.
• غياب سجل CAA: يترك بابك مفتوحًا لإصدار شهاداتٍ من أي جهة.
• تعدّد سجلات SPF: يجب أن يكون لديك سجل SPF واحدٌ فقط؛ تعدّده يكسر التحقق.
• نسيان الرقم التسلسلي في SOA: بعض الأنظمة لا تتزامن إن لم يُزَد الرقم عند كل تعديل.

الخلاصة والخطوات التالية

الـ DNS ليس صندوقًا أسود، بل نظامٌ هرميٌّ منطقيّ يمكن إتقانه: استعلامٌ يبدأ من جهازك، يمرّ عبر محلّلٍ تكراريّ يطارد الجواب من الجذر إلى الـ TLD إلى الخادم المرجعي، وتخزينٌ مؤقّتٌ ذكيّ يحكمه الـ TTL يجعل كل ذلك يحدث في لمح البصر. وفهمك للفرق بين المُسجِّل ومزوّد استضافة الـ DNS، ولدور سجلات NS في التفويض، هو ما يمنحك السيطرة الكاملة على بنيتك.

أما السجلات فهي لوحة التحكّم الفعلية: A/AAAA تحدّد مكان موقعك، MX يوجّه بريدك، CNAME ينشئ الأسماء المستعارة، TXT يحمي بريدك ويثبت ملكيتك، وCAA وDNSSEC يضيفان طبقات الأمان.

خطوات عملية للبدء اليوم:

1. شغّل dig yourdomain.com ANY +noall +answer (أو استعلم عن كل نوعٍ على حدة) لجرد سجلاتك الحالية.
2. تأكّد أن لديك خادمَي أسماءٍ على الأقل، وأن سجلات البريد (MX + SPF + DKIM + DMARC) مكتملة.
3. أضِف سجل CAA لحصر إصدار الشهادات على جهةٍ موثوقة.
4. قبل أي تغييرٍ كبير، اخفض الـ TTL مسبقًا، ونفّذ التعديل، ثم تحقّق من الانتشار عبر محلّلاتٍ عامة مختلفة.
5. إن كان أمن النطاق أولويةً لديك، خطّط لتفعيل DNSSEC بالتنسيق بين المُسجِّل والمزوّد.
بإتقان هذه الأساسيات تنتقل من مجرّد «توجيه نطاقٍ إلى خادم» إلى إدارةٍ واعيةٍ لبنيةٍ تحتيةٍ مستقرّة وآمنة وقابلة

مقالات ذات صلة

المساعد الذكي من إليفانتي

النطاقات (Domains): الدليل الشامل لفهم بنية الإنترنت من الجذر إلى التسجيل والإدارة

كل ما تحتاج معرفته عن النطاقات: ما هي، وكيف نشأت الحاجة إليها، وآلية عملها داخل نظام أسماء النطاقات، ومنظومة تسجيلها وإدارتها وتأمينها، مع نظرة على…

70.5% match يونيو 30, 2026

حماية البريد الإلكتروني: الدليل الاحترافي لـ SPF وDKIM وDMARC

بروتوكول SMTP وُلد بلا هوية. هذا الدليل يشرح كيف تُغلق طبقات SPF وDKIM وDMARC—ثم ARC وMTA-STS وBIMI—الثغرة التي يستغلها التصيّد وانتحال النطاق، مع سجلات DNS…

58.8% match يوليو 1, 2026

المقال التالي

المساعد الذكي من إليفانتي

أسرار النطاقات

حماية البريد المتقدمة

اختيار مزود DNS

حجز النطاق السوري