ما هو الفرق بين الـ Domain Name والـ Nameservers والـ DNS Record؟

اشتريت Domain جديدة، فتحت لوحة التحكم، ثم ظهرت أمامك كلمات مثل:

Nameservers
DNS
A Record
CNAME
MX
TXT

وبعد دقائق يبدأ الخلط:

هل الـNameservers هي DNS؟

هل A Record هي التي تربط الدومين بالسيرفر؟

إذا غيرت Nameservers، هل نقلت الدومين؟

وأين أضع IP السيرفر أصلًا؟

لفهم الموضوع بسهولة، يجب فصل ثلاث طبقات مختلفة:

لنبدأ بمثال واحد

لنفترض أنك تملك:

example.com

ولديك VPS عنوانها:

203.0.113.50

وتريد أن يعمل موقعك على:

example.com

والمتجر على:

shop.example.com

والبريد تستخدم له شركة منفصلة.

هذه حالة واحدة، لكنها تحتوي الأجزاء الثلاثة كلها.

أولًا: ما هو Domain Name؟

الـDomain هو الاسم الذي يستطيع الإنسان تذكره واستخدامه بدل التعامل مباشرة مع عنوان IP.

مثل:

example.com

بدل:

203.0.113.50

لكن شراء Domain لا يعني تلقائيًا أنك اشتريت:

• Hosting.
• VPS.
• Email Hosting.
• Website.
• Database.

أنت حصلت على حق استخدام وإدارة ذلك الاسم خلال فترة التسجيل، وفق شروط الـRegistrar والامتداد.

من هو الـRegistrar؟

الـRegistrar هي الشركة التي سجلت Domain من خلالها.

داخل حساب الـRegistrar عادة تستطيع إدارة أشياء مثل:

• تجديد الدومين.
• بيانات التسجيل.
• قفل أو فتح الدومين للنقل.
• Nameservers المستخدمة.

وقد تكون الشركة نفسها أيضًا DNS Provider، لكنها ليست مضطرة أن تكون كذلك.

وهنا يأتي دور Nameservers

Nameservers تجيب عن سؤال مهم:

أي DNS Provider هي المصدر الموثوق الذي نذهب إليه لمعرفة Records الخاصة بهذا الدومين؟

قد ترى مثلًا:

ns1.provider.example
ns2.provider.example

أو إذا كنت تستخدم مزود DNS آخر، يعطيك Nameservers خاصة به.

أنت تدخل هذه Nameservers عادة في لوحة الـRegistrar.

ماذا يعني تغيير Nameservers؟

تغيير Nameservers لا يعني أنك نقلت ملكية Domain إلى شركة أخرى.

ولا يعني بالضرورة أنك غيرت Web Hosting.

أنت تقول لنظام DNS:

من الآن، اسأل هذه الخوادم عن سجلات example.com.

يمكن أن يكون السيناريو:

Registrar:
Company A

Authoritative DNS:
Company B

Web Hosting:
Company C

Email:
Company D

ولا يوجد تعارض في ذلك.

إذًا ما هي DNS Records؟

بعد أن نعرف أي Nameservers مسؤولة عن Domain، نصل إلى Records الموجودة داخل DNS Zone.

هذه Records هي التعليمات الفعلية.

مثل:

example.com
→ 203.0.113.50

أو:

shop.example.com
→ 203.0.113.50

أو:

mail for example.com
→ mail provider

أو:

this TXT value
→ proves ownership / configures email authentication

العلاقة بين الثلاثة

تخيلها بهذا الشكل:

Domain Name
example.com
      ↓
Nameservers
من المسؤول عن DNS؟
      ↓
DNS Zone
      ↓
DNS Records
A / AAAA / CNAME / MX / TXT / ...
      ↓
Website / Email / Other Services

هذه هي الصورة الأساسية التي إذا فهمتها، ستصبح معظم لوحات DNS منطقية.

ماذا يحدث عندما تكتب example.com في المتصفح؟

المتصفح يحتاج في النهاية إلى عنوان يستطيع الاتصال به.

بشكل مبسط، رحلة DNS تكون كالتالي:

User
  ↓
example.com
  ↓
DNS Resolver
  ↓
DNS hierarchy / delegation
  ↓
Authoritative Nameservers
  ↓
A or AAAA Record
  ↓
Server IP
  ↓
Web Server

هناك تفاصيل إضافية مثل Cache وRecursive Resolution، لكن هذه الصورة تكفي لفهم مسؤولية كل جزء.

A Record: ربط اسم بعنوان IPv4

هذه من أكثر Records استخدامًا للمواقع.

مثال:

Type: A
Name: @
Value: 203.0.113.50

في كثير من لوحات DNS، الرمز:

@

يعني Root Domain نفسها:

example.com

وبذلك يصبح المعنى:

example.com
→ 203.0.113.50

وماذا عن www؟

يمكن أن يكون لديك مثلًا:

Type: CNAME
Name: www
Target: example.com

وبهذا:

www.example.com

تتبع الاسم:

example.com

بحسب إعدادات DNS المستخدمة.

ما الفرق بين A وCNAME؟

A Record تشير مباشرة إلى IPv4:

app.example.com
→ 203.0.113.50

أما CNAME فتشير إلى اسم DNS آخر:

app.example.com
→ service.example.net

ثم يتم حل الاسم الهدف للحصول على عنوان الاتصال النهائي.

AAAA Record

AAAA تؤدي دورًا شبيهًا بـA Record، لكن لـIPv6.

مثال:

Type: AAAA
Name: @
Value: 2001:db8::50

إذا لم تكن خدمتك تعمل على IPv6 بصورة صحيحة، لا تضف AAAA فقط لأن لديك خيارًا لها في لوحة DNS.

وجود Record يعني أن Clients قد يحاولون استخدامها.

MX Record للبريد

MX لا تخبر Browser أين يوجد الموقع.

هي تحدد Servers المسؤولة عن استقبال البريد لـDomain.

مثال توضيحي:

Type: MX
Name: @
Priority: 10
Target: mail.example.net

إذا كنت تستخدم Google Workspace أو Microsoft 365 أو مزود Email آخر، سيعطيك هو MX Records الصحيحة.

لا تنسخ MX من مثال عشوائي.

TXT Record ليست مخصصة لشيء واحد

TXT تستطيع حمل نصوص تستخدمها خدمات مختلفة للتحقق أو السياسات.

ستجدها مثلًا مع:

• SPF.
• DMARC.
• Domain Verification.
• بعض إعدادات الخدمات الخارجية.

مثال توضيحي:

Type: TXT
Name: @
Value: verification-code-example

القيمة الحقيقية دائمًا تأتي من الخدمة التي تحاول إعدادها.

وNS نفسها هي أيضًا نوع DNS Record

هنا يوجد سبب إضافي للارتباك.

مصطلح Nameservers الذي تراه داخل Registrar يرتبط في النهاية بسجلات NS في DNS.

لكن في الاستخدام اليومي عندما يقول لك مزود:

غيّر Nameservers إلى خوادمنا

فهو عادة يقصد تغيير Delegation للدومين حتى تصبح خوادمه هي الـAuthoritative DNS.

أما NS Records داخل Zone فقد تستخدم أيضًا لتحديد الخوادم المسؤولة عن Zone أو تفويض Subdomain في تصميمات DNS أكثر تقدمًا.

خطأ مشهور: تعديل Records في المكان الخطأ

لنفترض أن Domain مسجلة عند Registrar A.

لكن Nameservers الحالية هي:

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

ثم تذهب إلى DNS Editor داخل Registrar A وتغير:

A Record

ولا يحدث شيء.

لماذا؟

لأن الإنترنت لا يسأل DNS Zone الموجودة عند Registrar A أصلًا.

الـNameservers الحالية تقول إن المصدر الموثوق هو Provider B.

كيف أعرف Nameservers الحالية؟

على Linux تستطيع استخدام:

dig NS example.com +short

وقد ترى:

ns1.provider.example.
ns2.provider.example.

كما تستطيع استخدام أدوات DNS Lookup المختلفة على الإنترنت.

كيف أفحص A Record؟

dig A example.com +short

ولـSubdomain:

dig A shop.example.com +short

وIPv6:

dig AAAA example.com +short

كيف أفحص بقية Records؟

dig MX example.com +short

dig TXT example.com +short

dig TXT _dmarc.example.com +short

وعلى Windows تستطيع استخدام:

nslookup -type=ns example.com

nslookup -type=a example.com

nslookup -type=mx example.com

nslookup -type=txt example.com

ماذا يحدث إذا غيرت Nameservers؟

هذه نقطة تحتاج حذرًا.

لنفترض أن DNS الحالية تحتوي:

A
www
MX
SPF
DKIM
DMARC
Verification Records

ثم غيرت Nameservers إلى Provider جديدة.

السجلات القديمة لا تنتقل تلقائيًا دائمًا إلى الـDNS Provider الجديدة.

إذا كانت Zone الجديدة ناقصة، قد يعمل الموقع بينما يتوقف البريد.

أو يعمل البريد ويتوقف Subdomain.

أو تتعطل خدمة تحقق خارجية.

إذن قبل تغيير Nameservers انسخ Zone المهمة

راجع على الأقل:

• A.
• AAAA.
• CNAME.
• MX.
• TXT.
• SPF.
• DKIM.
• DMARC.
• أي Records لخدمات خارجية.

ثم جهزها لدى Provider الجديدة قبل أو أثناء عملية الانتقال بالطريقة المناسبة.

تغيير Nameservers ليس تغيير A Record

هاتان عمليتان مختلفتان تمامًا.

إذا أردت فقط نقل الموقع من Server قديمة إلى Server جديدة، وكان DNS Provider الحالي مناسبًا، فقد تحتاج فقط إلى تغيير:

A Record
Old IP
→
New IP

ولا يوجد سبب لتغيير Nameservers.

أما إذا أردت نقل إدارة DNS نفسها إلى Provider أخرى، هنا تغير Nameservers.

مثال: نقل الموقع فقط

الوضع الحالي:

Domain:
example.com

Nameservers:
Cloud DNS Provider

A:
203.0.113.10

اشتريت VPS جديدة:

203.0.113.50

إذا كنت ستبقي DNS Provider نفسها، فالتغيير قد يكون فقط:

A
203.0.113.10
→
203.0.113.50

Nameservers تبقى كما هي.

مثال: نقل إدارة DNS نفسها

إذا كانت Domain تستخدم:

ns1.old-provider.example
ns2.old-provider.example

وقررت نقل DNS إلى Provider جديدة، قد تعطيك:

ns1.new-provider.example
ns2.new-provider.example

هنا تغير Nameservers عند الـRegistrar.

لكن قبل ذلك يجب أن تتأكد أن Records المطلوبة أصبحت موجودة في Zone الجديدة.

ما هو TTL؟

داخل DNS Records ستجد قيمة:

TTL

اختصار:

Time To Live

وهي مرتبطة بالمدة التي يمكن أن تحتفظ خلالها DNS Resolvers بالنتيجة في Cache قبل الحاجة إلى الاستعلام عنها من جديد.

إذا كانت TTL:

300

فهذا يعني عادة 300 ثانية:

5 minutes

لكن لا يعني ذلك أن كل تغيير على الإنترنت سيظهر حرفيًا لجميع المستخدمين بعد خمس دقائق فقط؛ هناك أكثر من طبقة Cache وسلوك Resolver، كما أن تغيير Delegation وNameservers يختلف عن تعديل Record داخل Zone.

هل DNS Propagation تعني أن DNS تنسخ نفسها حول العالم؟

هذا وصف شائع لكنه مبسط أكثر من اللازم.

كثير مما نسميه:

DNS Propagation

هو في الواقع انتظار انتهاء Cached Answers القديمة لدى Resolvers مختلفة، ثم حصولها على الإجابة الجديدة.

ولهذا قد يرى شخص Record الجديدة بينما شخص آخر ما زال يرى القديمة لبعض الوقت.

ما علاقة DNS بـNginx Proxy Manager؟

لنفترض أن لديك VPS واحدة عليها عدة تطبيقات:

Nextcloud
n8n
Uptime Kuma

يمكنك إنشاء:

cloud.example.com
n8n.example.com
status.example.com

وفي DNS تجعلها تصل إلى Public IP الخاصة بالسيرفر.

بعد وصول الاتصال إلى الـServer، يأتي دور Reverse Proxy مثل Nginx Proxy Manager لتمييز اسم الـHost وتوجيه الطلب إلى التطبيق الصحيح.

بمعنى:

DNS
يجيب:
أين توجد السيرفر؟

Reverse Proxy
يجيب:
أي تطبيق داخل السيرفر يجب أن يستقبل الطلب؟

DNS لا تعرف Port تطبيق Docker

هذه نقطة مهمة.

لا تستطيع إنشاء A Record تقول:

app.example.com
→ 203.0.113.50:3000

A Record تخزن IP، وليست HTTP URL مع Port.

يمكن أن تجعل:

app.example.com
→ 203.0.113.50

ثم Reverse Proxy على Server تستقبل HTTP/HTTPS وتوجه الطلب داخليًا إلى:

myapp:3000

DNS لا تنقل ملفات موقعك أيضًا

إذا غيرت A Record من Server إلى أخرى، أنت لم تنقل:

• ملفات الموقع.
• Database.
• Uploads.
• Docker Volumes.

أنت فقط غيرت الوجهة التي يصل إليها الاسم.

يجب أن تكون Server الجديدة مجهزة مسبقًا.

ما علاقة SSL بالموضوع؟

SSL Certificate شيء منفصل عن DNS، لكن DNS الصحيحة غالبًا جزء أساسي من إصدار الشهادة واستخدامها.

مثلًا إذا:

app.example.com

تشير إلى Server خاطئة، فإن محاولة إصدار Certificate على Server الجديدة قد تفشل في طرق التحقق التي تعتمد على الوصول إلى الخدمة.

وبعض طرق التحقق الأخرى تعتمد مباشرة على DNS Records مخصصة.

لذلك:

Domain
DNS
Web Server
SSL

أنظمة مرتبطة ببعضها، لكنها ليست الشيء نفسه.

هل يمكن أن يكون الدومين عند شركة والاستضافة عند شركة ثانية؟

نعم.

وهذا طبيعي جدًا.

مثلًا:

Domain Registrar:
Company A

DNS:
Company B

Web Hosting:
Company C

Transactional Email:
Company D

المهم أن تكون العلاقات بين هذه الأنظمة مضبوطة من خلال DNS Records الصحيحة.

Subdomain لا تحتاج شراء Domain جديدة

إذا تملك:

example.com

يمكنك إنشاء أسماء مثل:

shop.example.com
api.example.com
cloud.example.com
status.example.com
panel.example.com

عن طريق DNS دون شراء Domain منفصلة لكل واحد منها.

هل يجب أن يكون لكل Subdomain A Record؟

ليس بالضرورة.

قد تستخدم:

A
CNAME
AAAA

أو تصميمات DNS أخرى حسب الخدمة.

مثلًا:

Type: A
Name: app
Value: 203.0.113.50

أو:

Type: CNAME
Name: app
Target: host.example.net

ماذا عن Wildcard DNS؟

يمكن إنشاء Record مثل:

*.example.com

بحسب احتياجك ومزود DNS.

هذه قد تسمح لأسماء Subdomains غير المعرفة بصورة أكثر تحديدًا بأن تطابق Wildcard Record.

لكن لا تستخدم Wildcard كبديل عن فهم البنية.

في الأنظمة المهمة، Explicit Records تكون أحيانًا أوضح وأسهل في التدقيق.

خمسة أخطاء تسبب معظم مشاكل DNS للمبتدئين

إذا كان الموقع لا يعمل، افحص بهذا الترتيب

ابدأ من الخارج إلى الداخل.

1. هل Domain مسجلة وما زالت فعالة؟

2. ما Nameservers الحالية؟

3. هل أعدل DNS في الـProvider الصحيحة؟

4. ماذا تعيد A / AAAA Record؟

5. هل IP هي IP السيرفر المطلوبة؟

6. هل Server نفسها تعمل؟

7. هل Ports 80 و443 متاحة؟

8. هل Web Server / Reverse Proxy يعرف Domain؟

9. هل SSL سليمة؟

بهذا لا تضيع ساعة داخل Nginx بينما المشكلة أصلًا A Record تشير إلى IP قديمة.

وإذا البريد توقف بعد تعديل DNS؟

لا تبدأ بتغيير إعدادات الموقع.

افحص:

MX
SPF
DKIM
DMARC

خصوصًا إذا كانت المشكلة بدأت مباشرة بعد تغيير Nameservers.

طريقة سريعة لحفظ الفرق

إذا نسيت كل التفاصيل، تذكر هذا المثال:

Domain Name
=
example.com
الاسم

Nameservers
=
أين نسأل عن DNS الخاصة بالاسم؟

DNS Records
=
ماذا تقول DNS عن الموقع والبريد والخدمات؟

ثم:

A / AAAA
→ أين يوجد السيرفر؟

CNAME
→ إلى أي اسم DNS آخر يشير هذا الاسم؟

MX
→ أين يستقبل البريد؟

TXT
→ معلومات تحقق وسياسات وإعدادات نصية مختلفة؟

قبل تعديل أي شيء في Domain حقيقية

خذ Snapshot أو Export للسجلات الموجودة إذا كان مزودك يدعم ذلك، أو على الأقل احفظ نسخة منها.

ثم حدد:

Registrar الحالي
Nameservers الحالية
DNS Provider الفعلية
Web Server IP
Email Provider
السجلات التي ستتغير فقط

بعدها نفذ أقل تغيير مطلوب.

إذا كنت تنقل الموقع فقط، غيّر Record المطلوبة.

إذا كنت تنقل DNS نفسها، جهز Zone كاملة ثم غيّر Nameservers.

هذه التفرقة الصغيرة تمنع نسبة كبيرة من مشاكل «الدومين توقف فجأة» بعد عمليات النقل.