> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# شرح DNS وسجلاته للمبتدئين: A وCNAME وMX وTXT وCAA وPTR بمثال حقيقي
- URL: https://arabroot.io/articles/شرح-dns-وسجلاته-للمبتدئين/
- Published: 2026-10-05T00:00:00.000Z
- Updated: 2026-10-05T06:02:33.000Z
- Description: كيف يتحول اسم نطاقك إلى عنوان سيرفرك خطوة خطوة، وما وظيفة كل سجل من A وCNAME وMX وTXT وCAA وPTR على سيرفر تستضيفه بنفسك، مع مخرجات حقيقية لأمر dig والأخطاء التي تضيع فيها الساعات عادة.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الشبكات والوصول, الاستضافة الذاتية, البريد الإلكتروني

اشتريت نطاقاً مثل `example.com`، وجهزت سيرفراً افتراضياً VPS عنوانه `203.0.113.10`، وثبت عليه أول تطبيق، والآن يطلب منك الدليل أن «توجه النطاق إلى السيرفر»، فتفتح صفحة إدارة النطاق فتجد قائمة من الأنواع: A وAAAA وCNAME وMX وTXT وCAA وSRV، وبجانب كل سجل خانة اسمها TTL، وأحياناً سحابة برتقالية لا تعرف ماذا تفعل. وبعد ذلك تأتي أدلة البريد فتطلب منك سجلات أخرى، ومعها سجل PTR الذي لن تجده في هذه الصفحة أصلاً. وأغلب المشاكل التي تقابل من يستضيف خدماته بنفسه في أيامه الأولى، من شهادة TLS لا تصدر إلى بريد لا يصل إلى أحد، تبدأ من سجل DNS ناقص أو مكتوب في المكان الخطأ.

وفي مقال [مصطلحات الاستضافة الذاتية](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%B0%D8%A7%D8%AA%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) عرفنا DNS في سطرين وذكرنا أشهر سجلاته، وفي هذا المقال سوف نتعمق فيه خطوة خطوة، فنبدأ من سؤال بسيط: لماذا نحتاج إلى الأسماء أصلاً؟ ثم نتابع ما يحدث فعلاً عندما يسأل جهازك عن اسم، وبعدها نمر على كل نوع من السجلات بمثال من سيرفر تستضيفه بنفسك، مع مخرجات حقيقية لأوامر `dig` و`nslookup` نفذناها على نطاقات عامة معروفة.

وسوف نناقش في هذا المقال ما يلي:

- لماذا نستخدم الأسماء بدل العناوين، وكيف كانت الشبكة تعمل قبل DNS.
- ما الذي يحدث بين جهازك وال Recursive Resolver وخوادم Root Servers وخوادم ال TLD والسيرفر الموثوق Authoritative Server، ودور التخزين المؤقت Caching ومدة بقاء السجل TTL.
- الفرق بين المسجل Registrar ومزود DNS والسيرفر الذي يستضيف خدماتك، وأين تعدل كل شيء.
- المنطقة Zone وشكل السجل، ثم السجلات واحداً واحداً: A وAAAA وCNAME وMX وTXT وCAA وPTR وNS وSOA وSRV والسجل العام Wildcard.
- حقيقة «انتشار» DNS، وكيف تخطط لنقل سيرفر دون أن يضيع زوارك.
- وضع ال Proxy في Cloudflare، ولماذا يجب أن تبقى سجلات البريد DNS only.
- DNSSEC باختصار، وما الذي يفعله وما لا يفعله.
- أدوات الفحص `dig` و`nslookup` وأدوات الويب، والأخطاء الشائعة وكيف تكتشفها.

## لماذا نستخدم الأسماء بدل العناوين؟

كل جهاز على الإنترنت يصل إليه الآخرون بعنوان IP مثل `203.0.113.10`، أو بعنوان IPv6 أطول مثل `2001:db8::10`، والأجهزة لا تمانع في التعامل مع هذه الأرقام، لكن الناس يتذكرون الأسماء. والسبب الأهم من التذكر أن العنوان يتغير: فإذا نقلت موقعك إلى مزود آخر أو إلى سيرفر أكبر فسوف يتغير عنوانه، ولو كان كل زوارك يحفظون العنوان لاحتاج كل واحد منهم إلى تعديله، أما مع الاسم فأنت تعدل سجلاً واحداً ويبقى الجميع يكتبون الاسم نفسه. وهذه هي الفكرة نفسها في قائمة الأسماء على هاتفك، فأنت تحفظ رقم الشخص تحت اسمه، وعندما يتغير رقمه تعدل خانة واحدة وتبقى تتصل به بالاسم.

وقد يتساءل البعض: كيف كانت الشبكة تعمل قبل DNS؟ والإجابة أن أسماء الأجهزة وعناوينها كانت في ملف واحد اسمه `HOSTS.TXT` يديره مركز معلومات الشبكة Network Information Center، وكل جهاز ينزل نسخته الجديدة عبر FTP، ومع زيادة عدد الأجهزة أصبح توزيع هذا الملف عبئاً على الشبكة وعلى السيرفر الذي يوزعه، كما يذكر [RFC 1034 في قسم تاريخ أسماء النطاقات](https://datatracker.ietf.org/doc/html/rfc1034?ref=arabroot.io#section-2.1). لذلك وضع Paul Mockapetris تصميم نظام أسماء النطاقات Domain Name System في [RFC 882](https://datatracker.ietf.org/doc/html/rfc882?ref=arabroot.io) عام 1983، ثم استقر التصميم في [RFC 1034](https://datatracker.ietf.org/doc/html/rfc1034?ref=arabroot.io) و[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035?ref=arabroot.io) في نوفمبر 1987، وما زال هذان المرجعان أساس DNS حتى اليوم.

والفكرة التي حلت المشكلة أن DNS قاعدة بيانات موزعة Distributed Database، فلا يوجد سيرفر واحد يعرف كل الأسماء، وإنما كل صاحب نطاق مسؤول عن أسماء نطاقه فقط، ويخبر المستوى الذي فوقه أين توجد سيرفراته، وهذا ما يسمى التفويض Delegation وسوف نراه بعد قليل بالأوامر.

وبقي أثر الطريقة القديمة في كل جهاز حتى اليوم، فالملف `/etc/hosts` في Linux والملف `C:\Windows\System32\drivers\etc\hosts` في Windows يقرؤهما النظام عادة قبل أن يسأل DNS، وهذا مفيد عندما تريد أن تختبر سيرفراً جديداً باسم موقعك قبل أن تغير سجلات DNS للجميع: تضيف سطراً مثل `203.0.113.20 example.com` على جهازك وحدك، وتفتح الموقع وتتأكد أنه يعمل، ثم تحذف السطر.

## ماذا يحدث عندما تكتب اسم موقع في المتصفح؟

عندما تكتب `example.com` في المتصفح يشترك في الإجابة أربعة أطراف، ولكل منها دور محدد:

- **ال Stub Resolver**: جزء صغير في نظام تشغيل جهازك، لا يبحث بنفسه، وإنما [يرسل السؤال إلى سيرفر واحد](https://datatracker.ietf.org/doc/html/rfc1034?ref=arabroot.io#section-5.3.1) وينتظر الجواب الكامل.
- **ال Recursive Resolver**: السيرفر الذي يبحث نيابة عنك حتى يصل إلى الجواب، ويكون عادة عند مزود الإنترنت ISP أو خدمة عامة مثل `8.8.8.8` من Google أو `1.1.1.1` من Cloudflare، ويحتفظ بكل جواب في ذاكرة مؤقتة Cache حتى لا يكرر البحث.
- **خوادم Root Servers**: قمة الشجرة، ولا تعرف عنوان موقعك، لكنها تعرف من يدير كل امتداد أعلى Top-Level Domain واختصاراً TLD مثل `.com` و`.org` و`.sa`. وبحسب [قائمة IANA](https://www.iana.org/domains/root/servers?ref=arabroot.io) فهي 13 اسماً من `a.root-servers.net` إلى `m.root-servers.net` تديرها 12 جهة مستقلة، وخلف هذه الأسماء [أكثر من ألفي نسخة](https://root-servers.org/?ref=arabroot.io) موزعة حول العالم بتقنية Anycast، أي أن العنوان نفسه تجيب عليه أقرب نسخة إليك.
- **خوادم ال TLD**: سيرفرات الامتداد، فسيرفرات `.com` مثلاً لا تعرف عنوان `example.com`، لكنها تعرف أي سيرفرات مسؤولة عنه.
- **السيرفر الموثوق Authoritative Name Server**: السيرفر الذي يحمل سجلات النطاق نفسه، وجوابه هو الجواب النهائي.

الصورة التالية تبين من يسأل من، والأرقام فيها هي ترتيب الخطوات:

![مخطط يبين جهاز Laptop يسأل ال Recursive Resolver عن example.com، فيسأل ال Resolver خوادم Root Servers ثم خوادم TLD الخاصة ب .com ثم السيرفر الموثوق hera.ns.cloudflare.com، ويعيد العنوان 203.0.113.10 إلى الجهاز ويحفظه في ال Cache لمدة TTL](https://arabroot.io/content/images/2026/10/dns-records-01-dns-resolution.webp)

ال Resolver يقوم بالبحث كله نيابة عن جهازك، ثم يحفظ الجواب حتى تنتهي مدة TTL

1. يرسل جهازك السؤال «ما عنوان `example.com`؟» إلى ال Recursive Resolver.
2. إذا لم يكن الجواب في ذاكرة ال Resolver، فإنه يسأل أحد خوادم Root.
3. يجيب سيرفر Root بأنه لا يعرف، لكنه يحيله إلى سيرفرات `.com`، وهذه الإجابة تسمى الإحالة Referral.
4. يسأل ال Resolver أحد سيرفرات `.com`.
5. يحيله سيرفر `.com` إلى السيرفرات الموثوقة للنطاق، وهي في مثالنا سيرفرات Cloudflare.
6. يسأل ال Resolver السيرفر الموثوق.
7. يجيب السيرفر الموثوق بالعنوان.
8. يعيد ال Resolver العنوان إلى جهازك، ويحفظه في ذاكرته حتى تنتهي مدة TTL، وكل من يسأل عن الاسم نفسه في هذه المدة يأخذ الجواب مباشرة دون الخطوات من 2 إلى 7.

### نفذ البحث بنفسك خطوة خطوة

الأمر `dig +trace example.com` يقوم بهذه الخطوات بدلاً منك ويطبع كل مرحلة، لكننا سوف ننفذها هنا يدوياً بثلاثة أوامر حتى ترى ما يراه ال Resolver بالضبط. والخيار `+norec` يطلب من السيرفر ألا يبحث نيابة عنك وأن يجيب بما يعرفه فقط، والخيار `+noall +authority` يعرض قسم الإحالة وحده. نبدأ بسؤال أحد خوادم Root:

```bash
dig @a.root-servers.net example.com A +norec +noall +authority
```

والمخرج سوف يكون كما يلي:

```text
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
```

سيرفر Root لم يذكر `example.com` أصلاً، وإنما قال: «اسأل أحد سيرفرات `.com` الثلاثة عشر». الآن نسأل أحدها:

```bash
dig @a.gtld-servers.net example.com A +norec +noall +authority
```

والمخرج سوف يكون كما يلي:

```text
example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.
```

وهذه هي الإحالة الثانية: سيرفرات `.com` تقول إن المسؤول عن `example.com` هما سيرفرا Cloudflare. وأخيراً نسأل أحدهما:

```bash
dig @hera.ns.cloudflare.com example.com A +norec
```

والمخرج سوف يكون كما يلي:

```text
; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> @hera.ns.cloudflare.com example.com A +norec
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16857
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243

;; Query time: 40 msec
;; SERVER: 108.162.192.162#53(hera.ns.cloudflare.com) (UDP)
;; WHEN: Mon Oct 05 05:27:38 UTC 2026
;; MSG SIZE  rcvd: 72
```

في المخرجات أعلاه لاحظ التالي:

- الإحالات في الخطوتين الأولى والثانية تأتي في قسم `AUTHORITY`، أما الجواب النهائي فيأتي في قسم `ANSWER SECTION`.
- في الجواب الأخير يظهر العلم `aa` في سطر `flags`، وهو اختصار Authoritative Answer، أي أن هذا الجواب من السيرفر المسؤول عن النطاق نفسه وليس من ذاكرة مؤقتة.
- الرقم `172800` في الإحالات هو مدة TTL بالثواني، أي يومان، ومعناه أن ال Resolver يتذكر «من المسؤول عن `example.com`» لمدة يومين، وسوف نعود لهذا الرقم عندما نتحدث عن تغيير سيرفرات NS.
- النطاق له عنوانان، وهذا طبيعي، فالعميل يختار أحدهما، وإذا فشل جرب الآخر.

### التخزين المؤقت Caching ومدة بقاء السجل TTL

لو قام كل Resolver بالخطوات السابقة مع كل زيارة لانهارت خوادم Root من الضغط، لذلك يحتفظ ال Resolver بكل جواب في ذاكرته المؤقتة طوال مدة TTL (Time To Live) التي يحددها صاحب النطاق في السجل، وعندما تنتهي المدة يحذفه ويسأل من جديد. والمثال التالي يبين ذلك، فنسأل أولاً السيرفر الموثوق ل `gmail.com` مباشرة:

```bash
dig @ns1.google.com gmail.com MX +norec +noall +answer
```

وهذه أول سطرين من المخرج:

```text
gmail.com.		3600	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	5 gmail-smtp-in.l.google.com.
```

صاحب النطاق حدد TTL بساعة كاملة `3600`. الآن نسأل Resolver عاماً مرتين بينهما عشرون ثانية، ونعرض أول سطر من كل جواب:

```bash
dig gmail.com MX +noall +answer
sleep 20
dig gmail.com MX +noall +answer
```

والمخرج سوف يكون كما يلي:

```text
gmail.com.		1222	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		1202	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
```

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

وال Resolver يتذكر أيضاً أن الاسم غير موجود، وهذا ما يسمى التخزين المؤقت السلبي Negative Caching، وتحدد مدته قيمة في سجل SOA كما في [RFC 2308](https://datatracker.ietf.org/doc/html/rfc2308?ref=arabroot.io)، وسوف ترى أثره في قسم الأخطاء الشائعة.

## المسجل ومزود DNS والسيرفر: من يفعل ماذا؟

أكثر ما يربك المبتدئ أن ثلاث جهات مختلفة تشترك في نطاقه، وقد تكون جهة واحدة أو ثلاثاً بحسب اختياره:

- **المسجل Registrar**: الشركة التي اشتريت منها النطاق، وهي تسجله عند جهة الامتداد Registry، أي عند Verisign في حالة `.com`، وترسل إليها أسماء السيرفرات الموثوقة لنطاقك (سجلات NS)، وسجل DS إذا فعلت DNSSEC. وعندها تجدد النطاق وتعدل بيانات المالك.
- **مزود DNS (DNS Hosting Provider)**: الجهة التي تشغل السيرفرات الموثوقة وتحمل المنطقة Zone بكل سجلاتها، وقد يكون المسجل نفسه، وهذا هو الوضع الافتراضي عند الشراء، أو مزوداً آخر مثل Cloudflare. فعندما تضيف نطاقك إلى Cloudflare يعطيك اسمي سيرفرين و[يطلب منك أن تضعهما عند المسجل](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/?ref=arabroot.io) مكان السيرفرات القديمة.
- **السيرفر ومزوده**: الجهاز الذي يحمل عنوان IP ويشغل خدماتك، والجهة التي تملك هذا العنوان، أي مزود ال VPS أو مزود الإنترنت، هي وحدها التي تستطيع ضبط البحث العكسي PTR له كما سيأتي.

الصورة التالية تبين أين تعدل كل شيء:

![مخطط يبين المسجل Registrar يرسل سجلات NS إلى جهة الامتداد .com، والامتداد يفوض النطاق إلى مزود DNS الذي يحمل السجلات، ومزود DNS يشير بسجل A إلى السيرفر عند مزود VPS، وتحت كل جهة ما يعدل عندها: NS وDS عند المسجل، وA وMX وTXT وCAA عند مزود DNS، وPTR عند مزود السيرفر](https://arabroot.io/content/images/2026/10/dns-records-03-registrar-dns-server.webp)

كل سجل له مكان واحد يقرؤه العالم منه، والسجلات عند المسجل لا يقرؤها أحد إذا كانت NS تشير إلى مزود آخر

والخطأ الذي يتكرر هنا أن تنقل سيرفرات NS إلى Cloudflare، ثم تعود بعد أشهر إلى لوحة المسجل لتعديل سجل، فتجد صفحة DNS ما زالت تعمل وتقبل التعديل، فتعدل وتنتظر ولا يتغير شيء، والسبب أن العالم لم يعد يسأل سيرفرات المسجل أصلاً. لذلك قبل أي تعديل اعرف أولاً من هو مزود DNS الفعلي لنطاقك بالأمر `dig NS example.com +short`، وعدل السجلات عنده فقط.

وقد يتساءل البعض: لماذا لا أشغل سيرفر DNS موثوقاً على سيرفري نفسه بدل الاعتماد على مزود؟ والإجابة أنك تستطيع ذلك ببرامج مثل BIND أو PowerDNS، لكنه غير مناسب لمن يبدأ، والسبب أن هذا السيرفر يصبح نقطة يتوقف عندها كل شيء، فإذا توقف سيرفرك توقف معه الاسم نفسه، ولا يصل البريد إلى نطاقك ولا تظهر حتى صفحة خطأ، بينما يشغل مزودو DNS سيرفراتهم على شبكات Anycast موزعة على مدن كثيرة، وكثير منهم يقدم ذلك مجاناً مع النطاق.

📌

في 4 أكتوبر 2021 توقفت Facebook عن العمل حول العالم، وشرحت الشركة في [تقريرها عن العطل](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/?ref=arabroot.io) أن أمراً أثناء صيانة دورية فصل شبكتها الرئيسية Backbone عن كل مراكز البيانات، وأن سيرفرات DNS الموثوقة عندها مصممة لتسحب إعلانات BGP عن نفسها إذا لم تستطع الوصول إلى مراكز البيانات، فأصبحت هذه السيرفرات غير قابلة للوصول رغم أنها تعمل، ولم يعد العالم يجد عنوان `facebook.com`. والدرس لمن يستضيف خدماته: إذا كانت سيرفرات DNS لنطاقك داخل الشبكة نفسها التي تصفها، فسوف يسقط الاسم مع أول عطل في هذه الشبكة.

## المنطقة Zone وشكل السجل Record

المنطقة Zone هي مجموعة السجلات التي يحملها السيرفر الموثوق لنطاقك، وكل سجل Resource Record له خمسة أجزاء: الاسم Name، ومدة البقاء TTL، والفئة Class وهي دائماً `IN` أي Internet، والنوع Type، ثم القيمة Value. والصيغة الأصلية للمنطقة هي ملف نصي بالشكل الذي [يحدده RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035?ref=arabroot.io#section-5) ويستخدمه BIND، ولوحات التحكم في الويب تعرض الحقول نفسها في جدول. والملف التالي منطقة كاملة لنطاق يستضيف موقعاً وتطبيقاً وبريداً على سيرفر واحد، وسوف نشرح كل سطر فيه في الأقسام التالية:

```text
$ORIGIN example.com.
$TTL 3600
@       IN  SOA    ns1.example.net. hostmaster.example.com. (
                   2026100501 ; Serial
                   7200       ; Refresh
                   3600       ; Retry
                   1209600    ; Expire
                   3600 )     ; Negative caching TTL
@       IN  NS     ns1.example.net.
@       IN  NS     ns2.example.net.
@       IN  A      203.0.113.10
@       IN  AAAA   2001:db8::10
www     IN  CNAME  example.com.
app     IN  CNAME  example.com.
mail    IN  A      203.0.113.10
mail    IN  AAAA   2001:db8::10
@       IN  MX     10 mail.example.com.
@       IN  TXT    "v=spf1 mx -all"
@       IN  CAA    0 issue "letsencrypt.org"
@       IN  CAA    0 issuewild "letsencrypt.org"
_caldavs._tcp  IN  SRV  0 1 443 mail.example.com.
```

ويمكنك أن تتأكد أن الملف سليم بالأداة `named-checkzone` من الحزمة `bind9-utils`:

```bash
named-checkzone example.com example.com.zone
```

والمخرج سوف يكون كما يلي:

```text
zone example.com/IN: loaded serial 2026100501
OK
```

في الملف أعلاه لاحظ التالي:

- الرمز `@` يعني النطاق نفسه `example.com`، ويسمى قمة المنطقة Zone Apex أو النطاق الرئيسي Root Domain.
- الاسم الذي ينتهي بنقطة مثل `mail.example.com.` اسم كامل Fully Qualified Domain Name واختصاراً FQDN، أما الاسم بدون نقطة مثل `www` فيضاف إليه `$ORIGIN` تلقائياً فيصبح `www.example.com.`، وهذه النقطة سبب أحد أشهر الأخطاء كما سيأتي.
- السطر `$TTL 3600` يعطي كل سجل مدة ساعة ما لم تحدد له مدة أخرى.
- السيرفرات `ns1.example.net` و`ns2.example.net` أسماء للتوضيح، وفي الواقع تضع هنا أسماء سيرفرات مزود DNS الذي تستخدمه.

وفي أغلب الحالات لن تكتب هذا الملف بيدك، وإنما تملأ الحقول نفسها في لوحة مزود DNS: النوع Type، والاسم Name، والقيمة Content، ومدة TTL.

## السجلات واحداً واحداً بمثال من سيرفرك

الصورة التالية تبين سجلات المنطقة السابقة، وما يقابل كل سجل منها على سيرفرك أو خارجه:

![مخطط يربط سجلات المنطقة example.com بما يقابلها: سجلات A وAAAA وCNAME تشير إلى ال Reverse Proxy على السيرفر 203.0.113.10، وسجل MX وسجل A للاسم mail يشيران إلى خادم البريد، وسجل TXT تقرؤه Gmail وOutlook، وسجل CAA تقرؤه Let's Encrypt، وسجل PTR مضبوط في لوحة مزود ال VPS وليس في المنطقة](https://arabroot.io/content/images/2026/10/dns-records-02-dns-records-map.webp)

سجلات الموقع والتطبيق تصل إلى ال Reverse Proxy، وسجلات البريد تصل إلى خادم البريد، وسجل PTR وحده خارج المنطقة

### سجل A وسجل AAAA: من الاسم إلى عنوان السيرفر

سجل A يربط الاسم بعنوان IPv4، وسجل AAAA يربط الاسم بعنوان IPv6 كما في [RFC 3596](https://datatracker.ietf.org/doc/html/rfc3596?ref=arabroot.io)، وهما أكثر السجلات استخداماً، فكل اسم يصل إليه الناس ينتهي في النهاية بأحدهما. المثال التالي يسأل عن سجل A للنطاق `example.com`:

```bash
dig A example.com
```

والمخرج سوف يكون كما يلي:

```text
; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31826
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		300	IN	A	172.66.147.243
example.com.		300	IN	A	104.20.23.154

;; Query time: 270 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Oct 05 05:16:15 UTC 2026
;; MSG SIZE  rcvd: 72
```

في المخرج أعلاه لاحظ التالي:

- `status: NOERROR` يعني أن الاسم موجود والسؤال نجح، وسوف ترى بعد قليل الحالة `NXDOMAIN` عندما يكون الاسم غير موجود.
- في سطر `flags` لا يوجد `aa` هذه المرة، والسبب أن الجواب جاء من ال Resolver وليس من السيرفر الموثوق، أما `ra` فتعني أن هذا السيرفر يقبل البحث نيابة عنك Recursion Available، وأما `ad` فسوف نشرحها في قسم DNSSEC.
- السطر `SERVER` يبين أي Resolver أجاب، وهو هنا `8.8.8.8`.

وللحصول على الجواب وحده بدون التفاصيل استخدم `+short`:

```bash
dig +short AAAA example.com
```

والمخرج سوف يكون كما يلي:

```text
2606:4700:10::6814:179a
2606:4700:10::ac42:93f3
```

وعلى سيرفرك تضع سجل A للنطاق `@` بعنوان السيرفر `203.0.113.10`، وإذا كان مزود ال VPS يعطيك عنوان IPv6 وكانت خدماتك وجدار الحماية Firewall تعمل عليه، فأضف سجل AAAA بعنوان `2001:db8::10`. ولا تقم بإضافة AAAA لعنوان لا تخدم عليه، والسبب أن الأجهزة التي تملك IPv6 تحاول عليه أولاً، وأن [Let's Encrypt تفضل عنوان IPv6 عند التحقق](https://letsencrypt.org/docs/ipv6-support/?ref=arabroot.io) من نطاقك إذا وجدت سجل AAAA، فإذا كان العنوان خطأ أو يشير إلى سيرفر آخر فقد يفشل إصدار الشهادة وأنت تبحث عن المشكلة في سجل A الذي لا عيب فيه.

### سجل CNAME: اسم يشير إلى اسم آخر

سجل CNAME (Canonical Name) يقول إن هذا الاسم مجرد اسم بديل Alias لاسم آخر، فيكمل ال Resolver البحث عن الاسم الآخر. المثال التالي يبين ذلك على `www.github.com`:

```bash
dig www.github.com +noall +answer
```

والمخرج سوف يكون كما يلي:

```text
www.github.com.		3543	IN	CNAME	github.com.
github.com.		60	IN	A	20.233.83.145
```

لاحظ أننا سألنا عن `www.github.com` فجاء الجواب في خطوتين: الاسم بديل ل `github.com`، وعنوان `github.com` هو كذا. وفائدته على سيرفرك أنك تضع العنوان في سجل A واحد للنطاق، ثم تجعل `www` و`app` و`git` وغيرها CNAME إليه، فإذا نقلت السيرفر عدلت سجلاً واحداً بدل عشرة.

وقد يتساءل البعض: لماذا لا أجعل النطاق الرئيسي `example.com` نفسه CNAME إلى اسم آخر؟ والإجابة أن [RFC 1034](https://datatracker.ietf.org/doc/html/rfc1034?ref=arabroot.io#section-3.6.2) يمنع أن يكون مع سجل CNAME أي سجل آخر للاسم نفسه، والسبب أن ال Resolver عندما يجد CNAME يترك كل شيء ويذهب إلى الاسم الآخر، والنطاق الرئيسي فيه دائماً سجل SOA وسجلات NS، وغالباً MX وTXT، وبالتالي فإن وضع CNAME عليه يكسر هذه السجلات. ولو جربت إضافة السطر `@ IN CNAME app.example.com.` إلى ملف المنطقة السابق فسوف يرفضه `named-checkzone` بهذه الرسالة (حذفنا الأسطر المكررة):

```text
dns_master_load: /z/bad.zone:13: example.com: CNAME and other data
zone example.com/IN: loading from master file /z/bad.zone failed: CNAME and other data
zone example.com/IN: not loaded due to errors.
```

ولوحات الويب ترفضه أيضاً أو تعالجه بطريقتها، فإذا كنت تحتاج فعلاً أن يشير النطاق الرئيسي إلى اسم يتغير عنوانه، كخدمة مستضافة تعطيك اسماً وليس عنواناً، فبعض المزودين يقدمون حلاً خاصاً: Cloudflare تسميه [CNAME Flattening](https://developers.cloudflare.com/dns/cname-flattening/?ref=arabroot.io)، فتتبع هي الاسم وتجيب الناس بسجل A عادي، ومزودون آخرون يسمونه ALIAS أو ANAME. وهذه حلول خاصة بكل مزود وليست جزءاً من معيار DNS.

وهناك قاعدة ثانية يقع فيها الكثيرون: [RFC 2181](https://datatracker.ietf.org/doc/html/rfc2181?ref=arabroot.io#section-10.3) يمنع أن تشير سجلات MX أو NS إلى اسم هو CNAME، لذلك فالاسم `mail.example.com` الذي يشير إليه MX يجب أن يكون له سجل A (وAAAA) مباشر وليس CNAME.

### سجل MX: أين يستلم نطاقك البريد

سجل MX (Mail Exchanger) يخبر أي سيرفر بريد في العالم أين يسلم الرسائل المرسلة إلى `@example.com`. المثال التالي يبين سجلات Gmail:

```bash
dig MX gmail.com
```

والمخرج سوف يكون كما يلي:

```text
; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> MX gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34145
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmail.com.			IN	MX

;; ANSWER SECTION:
gmail.com.		2077	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
gmail.com.		2077	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		2077	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
gmail.com.		2077	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		2077	IN	MX	20 alt2.gmail-smtp-in.l.google.com.

;; Query time: 70 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Oct 05 05:28:33 UTC 2026
;; MSG SIZE  rcvd: 161
```

في المخرج أعلاه لاحظ التالي:

- الرقم قبل الاسم هو الأولوية Preference، و[الرقم الأصغر يجرب أولاً](https://datatracker.ietf.org/doc/html/rfc5321?ref=arabroot.io#section-5.1)، فالسيرفر المرسل يحاول مع `gmail-smtp-in` صاحب الرقم 5، وإذا لم يستطع الوصول إليه انتقل إلى صاحب الرقم 10 ثم 20، والسجلات التي تتساوى أرقامها يوزع المرسل الرسائل بينها.
- القيمة اسم وليست عنواناً، ولكل اسم منها سجلات A وAAAA خاصة به.
- الأرقام نفسها لا معنى لها، المهم ترتيبها، فالأولويات 10 و20 مثل 1 و2 تماماً.

وعلى سيرفرك يكفي سجل واحد `@ MX 10 mail.example.com.` مع سجل A للاسم `mail`، وإذا لم يكن لنطاقك سجل MX أصلاً فإن المرسلين [يرسلون إلى عنوان سجل A للنطاق نفسه](https://datatracker.ietf.org/doc/html/rfc5321?ref=arabroot.io#section-5.1)، وهذا قد يوصل البريد إلى سيرفر الموقع دون أن تقصد. أما النطاق الذي لا يستقبل بريداً أبداً فيعلن ذلك بسجل [Null MX](https://datatracker.ietf.org/doc/html/rfc7505?ref=arabroot.io) بالقيمة `0 .`. وإذا كنت تخطط لاستضافة بريد مؤسستك فابدأ من [دليل استضافة البريد للمؤسسات](https://arabroot.io/articles/%D8%AF%D9%84%D9%8A%D9%84-%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%A8%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A5%D9%84%D9%83%D8%AA%D8%B1%D9%88%D9%86%D9%8A-%D9%84%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A7%D8%AA/) فهو يجمع كل ما يلزم بالترتيب.

### سجل TXT: نص حر تقرؤه الخدمات الأخرى

سجل TXT يحمل نصاً حراً، وDNS لا يهتم بمحتواه، لكن خدمات كثيرة اتفقت على أن تقرأ منه ما تحتاج إليه. المثال التالي يعرض سجلات TXT للنطاق `example.com`:

```bash
dig TXT example.com +noall +answer
```

والمخرج سوف يكون كما يلي:

```text
example.com.		300	IN	TXT	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com.		300	IN	TXT	"v=spf1 -all"
```

لاحظ أن للنطاق سجلين من النوع نفسه، ولكل منهما وظيفة: الأول نص عشوائي من النوع الذي تطلبه الخدمات لإثبات ملكية النطاق Domain Verification، فعندما تربط نطاقك بخدمة مثل Google Workspace أو Microsoft 365 تعطيك نصاً تضعه في سجل TXT، ثم تقرؤه هي من DNS فتعرف أنك صاحب النطاق. والثاني سياسة بريد. وأشهر استخدامات TXT لمن يستضيف خدماته ثلاثة:

- سياسات البريد SPF وDKIM وDMARC، وهي التي تحدد من يحق له الإرسال باسم نطاقك وكيف تتحقق المستقبلات من رسائلك، وقد شرحناها بالتفصيل في [شرح SPF وDKIM وDMARC للمبتدئين](https://arabroot.io/articles/%D8%B4%D8%B1%D8%AD-spf-%D9%88-dkim-%D9%88-dmarc-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/).
- إثبات ملكية النطاق للخدمات الخارجية كما في السطر الأول أعلاه.
- التحقق من ملكية النطاق عبر ال DNS (DNS Challenge) عند إصدار الشهادات، حيث يضع ال Reverse Proxy أو برنامج الشهادات سجل TXT مؤقتاً باسم `_acme-challenge.example.com`، و[هذه الطريقة وحدها](https://letsencrypt.org/docs/challenge-types/?ref=arabroot.io) تصدر شهادات Wildcard.

### سجل CAA: من يحق له إصدار شهادات لنطاقك

سجل CAA (Certification Authority Authorization) يحدد جهات إصدار الشهادات Certificate Authorities المسموح لها بإصدار شهادات TLS لنطاقك، و[RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659?ref=arabroot.io) يلزم الجهة المصدرة بأن تفحصه قبل أن تصدر الشهادة. المثال التالي يبين سجل Google:

```bash
dig CAA google.com
```

والمخرج سوف يكون كما يلي:

```text
; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> CAA google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	CAA

;; ANSWER SECTION:
google.com.		21600	IN	CAA	0 issue "pki.goog"

;; Query time: 280 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Oct 05 05:16:16 UTC 2026
;; MSG SIZE  rcvd: 66
```

Google تسمح بجهة واحدة فقط هي جهتها `pki.goog`، وأي جهة أخرى يطلب منها أحد شهادة ل `google.com` يجب أن ترفض. وفي المقابل، النطاق `letsencrypt.org` نفسه يسمح بعدة جهات:

```bash
dig CAA letsencrypt.org +short
```

والمخرج سوف يكون كما يلي:

```text
0 issue "amazon.com"
0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 issuewild "www.digicert.com"
0 issuewild "amazon.com"
0 issue "ssl.com"
0 issue "pki.goog"
0 issue "sectigo.com"
0 issuewild "ssl.com"
0 issuewild "sectigo.com"
0 issuewild "pki.goog"
0 issue "www.digicert.com"
```

في المخرج أعلاه لاحظ التالي:

- الوسم `issue` يسمح بالشهادات العادية، والوسم `issuewild` يسمح بشهادات Wildcard مثل `*.example.com`.
- السجلات تجمع ولا يلغي بعضها بعضاً، فإذا سمح أي سجل منها لجهة ما فهي مسموحة.
- إذا لم يكن لنطاقك سجل CAA أصلاً فكل جهة إصدار مسموح لها، وهذا هو الوضع الافتراضي لأغلب النطاقات.

وعلى سيرفرك الذي يأخذ شهاداته من Let's Encrypt تكفيك السطور `0 issue "letsencrypt.org"` و`0 issuewild "letsencrypt.org"`، فالمعرف `letsencrypt.org` هو [المعرف الرسمي](https://letsencrypt.org/docs/caa/?ref=arabroot.io) الذي تبحث عنه Let's Encrypt. ولاحظ أن [Caddy يستخدم Let's Encrypt وZeroSSL](https://caddyserver.com/docs/automatic-https?ref=arabroot.io) ويجرب الثانية إذا فشلت الأولى، فإذا حصرت CAA في Let's Encrypt وحدها فلن تنجح هذه المحاولة الاحتياطية، وهذا مقبول إذا كانت Let's Encrypt تكفيك، وإلا فأضف سجلاً لمعرف الجهة الأخرى أيضاً.

### سجل PTR: البحث العكسي من العنوان إلى الاسم

كل السجلات السابقة تبدأ من الاسم وتنتهي بقيمة، أما سجل PTR فيعمل بالعكس، فهو يبدأ من العنوان ويعطيك الاسم، وهذا ما يسمى البحث العكسي Reverse DNS. المثال التالي يسأل عن اسم العنوان `8.8.8.8`:

```bash
dig -x 8.8.8.8
```

والمخرج سوف يكون كما يلي:

```text
; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.		IN	PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.	10410	IN	PTR	dns.google.

;; Query time: 180 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Oct 05 05:16:16 UTC 2026
;; MSG SIZE  rcvd: 73
```

لاحظ أن `dig -x` حول العنوان إلى اسم خاص هو `8.8.8.8.in-addr.arpa`، فالأرقام تكتب بالعكس تحت النطاق `in-addr.arpa` كما [يحدد RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035?ref=arabroot.io#section-3.5)، والسبب أن DNS يقرأ الأسماء من اليمين إلى اليسار، من العام إلى الخاص، والعناوين تقرأ من اليسار إلى اليمين.

وهنا النقطة الأهم في هذا السجل: المنطقة `in-addr.arpa` الخاصة بعنوانك يملكها صاحب العنوان وليس صاحب النطاق، أي مزود ال VPS، لذلك لا تضبط PTR في لوحة مزود DNS، وإنما في لوحة مزود السيرفر، ففي Hetzner مثلاً [تعدله من صفحة Networking للسيرفر](https://docs.hetzner.com/cloud/servers/cloud-server-rdns/?ref=arabroot.io) بجانب العنوان. وسيرفرات البريد التي تستقبل رسائلك تفحص هذا السجل، فتسأل عن اسم العنوان الذي أرسل الرسالة، ثم تسأل عن عنوان هذا الاسم، وتتوقع أن تصل إلى العنوان نفسه، وهذا ما يسمى Forward-confirmed reverse DNS، و[إرشادات Google للمرسلين](https://support.google.com/a/answer/81126?ref=arabroot.io) تشترطه. لذلك فالإعداد الصحيح لسيرفر بريد على العنوان `203.0.113.10` هو PTR من `203.0.113.10` إلى `mail.example.com`، وسجل A من `mail.example.com` إلى `203.0.113.10`، واسم السيرفر في إعداد خادم البريد هو `mail.example.com` أيضاً. وأغلب مزودي الإنترنت المنزلي لا يسمحون لك بضبط PTR لعنوانك، وهذا من أسباب أخرى تجعل إرسال البريد من المنزل غير مناسب.

### سجل NS وسجل SOA: من يدير المنطقة

سجلات NS (Name Server) تحدد السيرفرات الموثوقة للنطاق، ورأيتها في الإحالات في بداية المقال، والمثال التالي يسأل عنها مباشرة:

```bash
dig NS example.com +noall +answer
```

والمخرج سوف يكون كما يلي:

```text
example.com.		21600	IN	NS	hera.ns.cloudflare.com.
example.com.		21600	IN	NS	elliott.ns.cloudflare.com.
```

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

```bash
dig SOA example.com +short
```

والمخرج سوف يكون كما يلي:

```text
elliott.ns.cloudflare.com. dns.cloudflare.com. 2416374680 10000 2400 604800 1800
```

والحقول بالترتيب كما [يحددها RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035?ref=arabroot.io#section-3.3.13): السيرفر الرئيسي للمنطقة، ثم بريد المسؤول مكتوباً بنقطة بدل `@` أي `dns@cloudflare.com`، ثم الرقم التسلسلي Serial الذي يزيد مع كل تعديل، ثم ثلاث مدد تستخدمها السيرفرات الثانوية Secondary Servers لمزامنة المنطقة (Refresh وRetry وExpire)، وآخر رقم هو مدة التخزين المؤقت السلبي، أي المدة التي يتذكر فيها ال Resolver أن اسماً غير موجود. ومزود DNS يدير هذا السجل بنفسه، فلن تحتاج إلى تعديله إلا إذا شغلت سيرفر DNS خاصاً بك.

### سجل SRV: أين تجد البرامج خدمة معينة

سجل SRV (Service) يخبر البرامج أين تجد خدمة معينة لنطاقك، بالاسم والمنفذ معاً، وصيغته [في RFC 2782](https://datatracker.ietf.org/doc/html/rfc2782?ref=arabroot.io)، واسمه يبدأ بالخدمة والبروتوكول مثل `_caldavs._tcp`. المثال التالي يسأل عن خدمة التقويم CalDAV عند Fastmail:

```bash
dig SRV _caldavs._tcp.fastmail.com +noall +answer
```

والمخرج سوف يكون كما يلي:

```text
_caldavs._tcp.fastmail.com. 3600 IN	SRV	0 1 443 d277161.caldav.fastmail.com.
```

والأرقام بالترتيب هي الأولوية Priority ثم الوزن Weight ثم المنفذ Port ثم اسم السيرفر، أي أن تطبيق التقويم الذي تعطيه عنوان بريدك فقط يستطيع أن يكتشف وحده أن خدمة التقويم على هذا السيرفر والمنفذ 443\. وتستخدم برامج التقويم وجهات الاتصال هذه السجلات [كما في RFC 6764](https://datatracker.ietf.org/doc/html/rfc6764?ref=arabroot.io)، وبرامج البريد تستخدم سجلات مثل `_submission._tcp` و`_imaps._tcp` [كما في RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186?ref=arabroot.io)، وهناك أيضاً `_autodiscover._tcp` للإعداد التلقائي Autodiscover في برامج البريد. ولن تكتب هذه السجلات من ذاكرتك، فخادم البريد الذي تثبته يعطيك قائمتها، و[توثيق mailcow](https://docs.mailcow.email/getstarted/prerequisite-dns/?ref=arabroot.io) مثلاً يذكرها كلها مع قيمها.

### السجل العام Wildcard: كل النطاقات الفرعية مرة واحدة

السجل الذي اسمه `*` مثل `*.example.com A 203.0.113.10` يجيب عن أي اسم تحت النطاق ليس له سجل خاص به، فيصل `wiki.example.com` و`test.example.com` وأي اسم آخر إلى سيرفرك دون أن تضيف له سجلاً، والقواعد التفصيلية [في RFC 4592](https://datatracker.ietf.org/doc/html/rfc4592?ref=arabroot.io). وفي المقابل، النطاق الذي ليس عنده Wildcard يجيب عن الاسم غير الموجود بالحالة `NXDOMAIN`:

```bash
dig random-name-123.wikipedia.org A +noall +comments +authority
```

وهذه الأسطر المهمة من المخرج:

```text
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6428
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
wikipedia.org.		1800	IN	SOA	ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600
```

في الإعداد الذي نشرحه لاحظ التالي:

- السجل الخاص يغلب السجل العام، فإذا كان عندك `mail.example.com` بسجل A خاص فهو الذي يستخدم.
- ال Wildcard لا يغطي النطاق الرئيسي `example.com` نفسه، فهو يحتاج سجله الخاص.
- مع Reverse Proxy مثل [Nginx Proxy Manager](https://arabroot.io/articles/nginx-proxy-manager-%D9%86%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-tls/) يصبح إطلاق تطبيق جديد على اسم فرعي جديد خطوة في ال Reverse Proxy وحده، وإذا أضفت إليه شهادة Wildcard عبر التحقق من ملكية النطاق عبر ال DNS فلن تحتاج إلى شهادة لكل اسم.
- كل خطأ إملائي في اسم فرعي يصل إلى سيرفرك أيضاً، لذلك اجعل ال Reverse Proxy يرفض الأسماء التي لا يعرفها بدل أن يعرض أول تطبيق عنده.

## «انتشار» DNS: الحقيقة أنه تخزين مؤقت

ستقرأ في كل مكان أن تعديل DNS «يحتاج إلى 24 أو 48 ساعة حتى ينتشر»، وكأن التعديل ينتقل من سيرفر إلى آخر حول العالم. والحقيقة أنه لا يوجد انتشار، فالسيرفر الموثوق يعطي القيمة الجديدة فوراً بعد التعديل، والذي يتأخر هو ال Resolvers التي حفظت القيمة القديمة، فكل واحد منها يبقى عليها حتى تنتهي مدة TTL التي رأيتها تنقص في مثال `gmail.com`، ثم يسأل من جديد. وبالتالي فمدة الانتظار هي مدة TTL القديمة لا أكثر: إذا كانت 300 ثانية فخلال خمس دقائق يرى الجميع التعديل، وإذا كانت 86400 فقد يبقى بعض الزوار على السيرفر القديم يوماً كاملاً.

أما تغيير سيرفرات NS نفسها فهو الذي يأخذ وقتاً أطول فعلاً، والسبب الرقم `172800` الذي رأيته في إحالة سيرفرات `.com`، فال Resolvers قد تتذكر السيرفرات القديمة يومين كاملين، ولا تستطيع أنت تقصير هذه المدة لأنها تأتي من جهة الامتداد وليس من منطقتك.

لذلك عندما تنقل موقعك إلى سيرفر جديد، كما في دليل [نقل ال Containers إلى خادم جديد](https://arabroot.io/articles/%D9%86%D9%82%D9%84-containers-%D8%A5%D9%84%D9%89-%D8%AE%D8%A7%D8%AF%D9%85-%D8%AC%D8%AF%D9%8A%D8%AF/)، خطط لسجلات DNS قبل النقل بهذا الترتيب:

1. قبل النقل بمدة لا تقل عن TTL الحالية، أي قبل يوم إذا كانت 86400، قم بتقليل TTL للسجلات التي سوف تتغير إلى 300 ثانية.
2. جهز السيرفر الجديد، واختبره باسم الموقع من جهازك عبر ملف `hosts` كما شرحنا في بداية المقال.
3. غير سجلات A وAAAA إلى العناوين الجديدة، ولا تنس AAAA.
4. تأكد من القيمة عند السيرفر الموثوق بالأمر `dig @hera.ns.cloudflare.com example.com A +short` (ضع اسم سيرفرك الموثوق)، ثم عند Resolvers مختلفة.
5. اترك السيرفر القديم يعمل يوماً على الأقل، فبعض ال Resolvers لا تلتزم بمدة TTL بدقة.
6. بعد أن يستقر كل شيء أعد TTL إلى قيمة أطول مثل 3600.

## السحابة البرتقالية: Proxied أم DNS only؟

إذا كان مزود DNS عندك Cloudflare فسوف ترى بجانب سجلات A وAAAA وCNAME خانة [Proxy status](https://developers.cloudflare.com/dns/proxy-status/?ref=arabroot.io) بسحابة برتقالية أو رمادية، وهذه الخانة لا تخص DNS وحده، وإنما تحدد طريق الحركة نفسها:

- **Proxied (السحابة البرتقالية)**: يجيب Cloudflare عن الاسم بعناوينه هو وليس بعنوان سيرفرك، فتمر حركة HTTP وHTTPS عبر شبكته، وتحصل على الحماية والتخزين المؤقت، ولا يظهر عنوان سيرفرك في DNS.
- **DNS only (السحابة الرمادية)**: يجيب Cloudflare بعنوان سيرفرك الحقيقي، ويتصل الناس به مباشرة.

ولاحظ أن عنواني `example.com` اللذين رأيتهما في بداية المقال، `104.20.23.154` و`172.66.147.243`، يقعان ضمن [نطاقات العناوين التي تنشرها Cloudflare](https://www.cloudflare.com/ips/?ref=arabroot.io)، أي أن ما رأيته هو عناوين Cloudflare وليس عنوان السيرفر الذي خلفها.

والقاعدة المهمة هنا أن ال Proxy يحمل حركة الويب فقط، ف Cloudflare تقول في التوثيق إن سجلات MX وTXT DNS only دائماً، وإن [سجل A لسيرفر البريد](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/?ref=arabroot.io) يجب أن يكون DNS only كذلك، والسبب أن البريد يعمل على المنافذ 25 و587 و993 ببروتوكولات ليست HTTP، فلو جعلت `mail.example.com` Proxied لأجاب الاسم بعنوان Cloudflare، ولوصلت إليه سيرفرات البريد فلا تجد من يستقبل الرسائل. والأمر نفسه مع SSH وWireGuard وأي خدمة ليست ويب. ويجدر الإشارة هنا إلى نتيجة لا ينتبه لها الكثيرون: إذا كان البريد والموقع على السيرفر نفسه فإن سجل `mail` يكشف عنوان السيرفر لأي شخص، فلا تعتمد على ال Proxy لإخفائه، وإنما قم [بتأمين السيرفر](https://arabroot.io/articles/%D8%AA%D8%A3%D9%85%D9%8A%D9%86-%D8%AE%D8%A7%D8%AF%D9%85-vps-%D9%85%D9%86-%D8%A3%D9%88%D9%84-%D8%AF%D8%AE%D9%88%D9%84/) كأن عنوانه معروف للجميع.

## DNSSEC باختصار وبصراحة

صمم DNS في الثمانينات بدون أي توقيع، فال Resolver يقبل الجواب الذي يصله دون أن يتأكد ممن أرسله، وهذا يسمح نظرياً بتسميم الذاكرة المؤقتة Cache Poisoning، أي أن يحفظ ال Resolver جواباً مزوراً يرسل الناس إلى عنوان آخر. والحل هو DNSSEC ([DNS Security Extensions](https://datatracker.ietf.org/doc/html/rfc4033?ref=arabroot.io))، حيث يوقع مزود DNS كل مجموعة سجلات توقيعاً رقمياً Digital Signature يأتي معها في سجل RRSIG، ويضع المسجل عند جهة الامتداد سجل DS يربط مفتاح منطقتك بالمستوى الذي فوقها، وهكذا حتى خوادم Root، وبالتالي يستطيع ال Resolver أن يتحقق من أن الجواب لم يعدل في الطريق. المثال التالي يطلب التوقيع مع الجواب:

```bash
dig +dnssec A example.com +noall +answer +comments
```

وهذه الأسطر المهمة من المخرج:

```text
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243
example.com.		300	IN	RRSIG	A 13 2 300 20261006061632 20261004041632 34505 example.com. 7s8QOZyZ1yWjx+8RUELjCTEw0xXqJ9XpcHPPOAOldsItwqL6wCgJJ5yW 19ds35R0PilD2besdSQfJPDviiMhNA==
```

لاحظ العلم `ad` (Authenticated Data) في سطر `flags`، ومعناه أن ال Resolver تحقق من التوقيع ونجح، وسجل `RRSIG` هو التوقيع نفسه. والآن لنكسر الأمر لنفهمه، فالنطاق التالي نطاق اختبار توقيعه مكسور عمداً:

```bash
dig A dnssec-failed.org +noall +comments
```

وهذه الأسطر المهمة من المخرج:

```text
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1192
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
```

ال Resolver رفض أن يعطيك أي عنوان، وأجاب بالحالة `SERVFAIL` مع سبب واضح: سجل DS عند جهة الامتداد لا يطابق أي مفتاح في المنطقة. وهذا بالضبط ما سوف يحدث لنطاقك إذا فعلت DNSSEC ثم نقلت النطاق إلى مزود DNS آخر وتركت سجل DS القديم عند المسجل، فكل من يستخدم Resolver يتحقق من التوقيع، ومنها `8.8.8.8` الذي نفذنا عليه هذا المثال، لن يصل إلى موقعك ولا إلى بريدك.

وبصراحة: DNSSEC لا يشفر الأسئلة ولا يخفيها عن مزود الإنترنت، فهذا عمل بروتوكولات مثل DNS over HTTPS، ولا يحمي سيرفرك ولا يظهر للزائر أي علامة في المتصفح، وإنما يحمي صحة الأجوبة فقط. والحل الأنسب لمن يبدأ أن يفعله إذا كان مزود DNS يوفره بزر واحد، ويضيف سجل DS عند المسجل كما يطلب المزود، ثم يتذكر قاعدة واحدة: قبل نقل النطاق إلى مزود DNS آخر احذف سجل DS من عند المسجل أولاً وانتظر، وCloudflare مثلاً [لا تسمح لك بحذف إعداد DNSSEC](https://developers.cloudflare.com/dns/dnssec/dnssec-states/?ref=arabroot.io) قبل أن يحذف سجل DS لهذا السبب، وتشرح طريقة النقل الآمن في [صفحة DNSSEC](https://developers.cloudflare.com/dns/dnssec/?ref=arabroot.io).

## أدوات الفحص: dig وnslookup وأدوات الويب

الأداة `dig` هي التي استخدمناها في كل الأمثلة، وتأتي في Ubuntu وDebian ضمن الحزمة `bind9-dnsutils`:

```bash
sudo apt install bind9-dnsutils
```

وأكثر الصيغ التي سوف تحتاجها في عملك:

| الأمر                                            | ماذا يفعل                                                            |
| ------------------------------------------------ | -------------------------------------------------------------------- |
| dig +short A example.com                         | الجواب وحده بدون تفاصيل                                              |
| dig @8.8.8.8 MX example.com                      | يسأل Resolver محدداً بدل Resolver جهازك                              |
| dig @hera.ns.cloudflare.com example.com A +norec | يسأل السيرفر الموثوق مباشرة، فترى القيمة الحالية بدون أي ذاكرة مؤقتة |
| dig -x 203.0.113.10                              | البحث العكسي PTR                                                     |
| dig +trace example.com                           | يتتبع الطريق من خوادم Root حتى السيرفر الموثوق                       |
| dig +dnssec A example.com                        | يطلب التوقيع ويبين هل تحقق منه ال Resolver                           |

وفي Windows تجد `nslookup` جاهزاً، والمثال التالي يسأل عن سجلات MX عبر `8.8.8.8`:

```powershell
nslookup -type=mx gmail.com 8.8.8.8
```

والمخرج سوف يكون كما يلي:

```text
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
gmail.com	MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com	MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com	MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com	MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
gmail.com	MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
```

لاحظ عبارة `Non-authoritative answer`، وهي تقول بطريقة أخرى ما قاله غياب العلم `aa` في `dig`: الجواب من ذاكرة Resolver وليس من السيرفر الموثوق.

وإذا لم يكن عندك سطر أوامر، أو أردت أن ترى نطاقك من خارج شبكتك، فهناك أدوات ويب مفيدة:

- [Google Admin Toolbox Dig](https://toolbox.googleapps.com/apps/dig/?ref=arabroot.io): واجهة ويب لأمر `dig` من Google، تختار فيها نوع السجل وترى الجواب.
- [MXToolbox SuperTool](https://mxtoolbox.com/SuperTool.aspx?ref=arabroot.io): تفحص سجلات MX وPTR وغيرها، وتفيد كثيراً عند إعداد البريد.
- مواقع فحص «الانتشار» مثل dnschecker.org وwhatsmydns.net: تسأل Resolvers في دول مختلفة في الوقت نفسه، فترى أي منها ما زال يحمل القيمة القديمة في ذاكرته.

وتذكر أن جهازك نفسه يحتفظ بذاكرة مؤقتة، فإذا عدلت سجلاً وما زال جهازك يرى القيمة القديمة فقم بمسحها، في Windows بالأمر `ipconfig /flushdns`، وفي Ubuntu التي تستخدم systemd-resolved بالأمر `resolvectl flush-caches`، والمتصفح له ذاكرته الخاصة أيضاً.

## أخطاء شائعة وكيف تكتشفها

- **CNAME على النطاق الرئيسي**: لا تقم بإضافته، والسبب أنه يكسر SOA وNS وMX كما رأيت في رسالة `named-checkzone`، واستخدم سجل A، أو CNAME Flattening إذا كان مزودك يوفره.
- **النقطة في آخر الاسم**: في ملف المنطقة، القيمة `mail.example.com` بدون نقطة تصبح `mail.example.com.example.com.` لأن `$ORIGIN` يضاف إليها، أما لوحات الويب فتضيف النطاق إلى خانة الاسم تلقائياً، فإذا كتبت فيها `mail.example.com` بدل `mail` فقد تحصل في بعض اللوحات على `mail.example.com.example.com`. وبعد أي إضافة تأكد بالأمر `dig +short A mail.example.com` أن الاسم الذي تريده هو الذي يجيب.
- **نسيان AAAA أو بقاء AAAA قديم**: عندما تنقل السيرفر وتغير سجل A وحده، يبقى سجل AAAA يشير إلى السيرفر القديم، فيصل مستخدمو IPv6 و[Let's Encrypt](https://letsencrypt.org/docs/ipv6-support/?ref=arabroot.io) إلى سيرفر لم يعد موجوداً، لذلك اسأل عن النوعين بعد كل تغيير.
- **TTL طويل قبل النقل**: إذا تركت TTL على يوم كامل وغيرت العنوان، فسوف يبقى جزء من زوارك على السيرفر القديم يوماً كاملاً ولا تستطيع أن تفعل شيئاً، لذلك قم بتقليله قبل النقل كما في الخطوات أعلاه.
- **التعديل عند المسجل وسيرفرات NS عند مزود آخر**: نفذ `dig NS example.com +short` أولاً، وعدل عند المزود الذي تظهر أسماء سيرفراته فقط.
- **MX يشير إلى عنوان IP أو إلى CNAME**: قيمة MX اسم، وهذا الاسم يجب أن يكون له سجل A مباشر.
- **سجل البريد Proxied في Cloudflare**: اجعل `mail.example.com` DNS only، وإلا فلن تصل الرسائل إلى سيرفرك.
- **السؤال عن الاسم قبل إنشائه**: إذا فتحت `app.example.com` في المتصفح قبل أن تضيف سجله، فإن ال Resolver يحفظ الجواب `NXDOMAIN` المدة التي رأيتها في سطر SOA في مثال `wikipedia.org`، أي 1800 ثانية هناك، فيبقى الاسم «غير موجود» عندك حتى بعد أن تضيفه. لذلك أضف السجل أولاً ثم افتح الاسم، وإذا وقعت في هذا فاسأل السيرفر الموثوق مباشرة لتتأكد أن السجل موجود، ثم امسح ذاكرة جهازك أو انتظر المدة.

## أين تستخدم هذا؟

كل دليل تثبيت على الموقع يبدأ بخطوة DNS، والأدلة التالية هي التي تحتاج فيها ما شرحناه هنا أكثر من غيرها: ال Reverse Proxy مع سجلات A وCNAME والشهادات، والبريد مع MX وTXT وPTR، واختيار السيرفر الذي سوف تشير إليه كل هذه السجلات:

[![](https://arabroot.io/content/images/2026/10/nginx-proxy-manager-cover-cover.webp)دليلNginx Proxy Manager: نطاقات وشهادات TLS لكل خدماتكبدلاً من فتح منفذ مستقل لكل تطبيق، يتيح لك Nginx Proxy Manager أن تربط كل خدمة بنطاقها وتمنحها شهادة HTTPS مجانية من واجهة بسيطة، دون أن تكتب إعدادات Nginx بنفسك.](https://arabroot.io/articles/nginx-proxy-manager-%D9%86%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-tls/)[![](https://arabroot.io/content/images/2026/10/email-hosting-guide-cover-cover.webp)دليلكيف تستضيف بريد مؤسستك بنفسك: دليل عملي من القرار إلى التشغيلمتى تستضيف بريد شركتك أو جامعتك بنفسك ومتى يكون البريد المستضاف أنسب، وما الذي تجهزه قبل البدء، وكيف تنقل المستخدمين على مراحل دون أن تضيع رسالة، مع مسار قراءة يجمع كل أدلة البريد على الموقع.](https://arabroot.io/articles/%D8%AF%D9%84%D9%8A%D9%84-%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%A8%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A5%D9%84%D9%83%D8%AA%D8%B1%D9%88%D9%86%D9%8A-%D9%84%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/email-authentication-cover-cover.webp)دليلشرح SPF وDKIM وDMARC للمبتدئين: كيف تثبت أن رسائلك منك فعلاًلماذا يستطيع أي شخص أن يرسل باسم نطاقك، وكيف جاء كل من SPF وDKIM وDMARC ليسد ثغرة تركها الذي قبله، مع قراءة السجلات جزءاً جزءاً وطرق اختبار بريدك بالخدمات المجانية.](https://arabroot.io/articles/%D8%B4%D8%B1%D8%AD-spf-%D9%88-dkim-%D9%88-dmarc-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/mailcow-cover-cover.webp)دليلتثبيت خادم البريد mailcow باستخدام Dockerأن تدير خادم بريدك بنفسك يعني أن تضمن وصول رسائلك إلى صندوق الوارد لا إلى الرسائل المزعجة. يشرح هذا الدليل تثبيت mailcow، وضبط سجلات DNS المطلوبة، وحل مشكلات التسليم الشائعة.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-%D8%AE%D8%A7%D8%AF%D9%85-%D8%A8%D8%B1%D9%8A%D8%AF-mailcow/)[![](https://arabroot.io/content/images/2026/10/choose-vps-cover-cover-2.webp)دليلكيف تختار خادماً افتراضياً VPSكم تحتاج من المعالج والذاكرة والقرص؟ وما الذي يميز مزوداً عن آخر غير السعر؟ يساعدك هذا الدليل على اختيار خادم VPS يناسب احتياجك، مع مقارنة بأبرز المزودين القريبين من المنطقة.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/)

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- DNS قاعدة بيانات موزعة، وال Recursive Resolver يبحث نيابة عنك من خوادم Root إلى خوادم ال TLD حتى السيرفر الموثوق، ثم يحفظ الجواب طوال مدة TTL.
- لا يوجد «انتشار»، وإنما ذاكرة مؤقتة تنتهي بانتهاء TTL القديمة، لذلك قلل TTL قبل أي نقل بمدة لا تقل عنها.
- اعرف مزود DNS الفعلي بالأمر `dig NS` قبل أي تعديل، فالسجلات عند المسجل لا يقرؤها أحد إذا كانت NS تشير إلى مزود آخر.
- A وAAAA للعناوين، وCNAME للأسماء الفرعية وليس للنطاق الرئيسي، وMX يشير إلى اسم له سجل A مباشر.
- TXT حاوية تقرؤها الخدمات الأخرى، وCAA يحدد من يصدر شهاداتك، وPTR تضبطه عند مزود السيرفر وليس عند مزود DNS.
- سجلات البريد وكل خدمة ليست ويب تبقى DNS only في Cloudflare.
- DNSSEC يحمي صحة الأجوبة فقط، واحذف سجل DS قبل نقل النطاق إلى مزود آخر.

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، وتنفيذ أوامر `dig` و`nslookup` و`named-checkzone` على نطاقات عامة وعلى ملف منطقة تجريبي.