شرح DNS وسجلاته للمبتدئين: A وCNAME وMX وTXT وCAA وPTR بمثال حقيقي

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

وفي مقال مصطلحات الاستضافة الذاتية عرفنا 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 في قسم تاريخ أسماء النطاقات. لذلك وضع Paul Mockapetris تصميم نظام أسماء النطاقات Domain Name System في RFC 882 عام 1983، ثم استقر التصميم في RFC 1034 وRFC 1035 في نوفمبر 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: جزء صغير في نظام تشغيل جهازك، لا يبحث بنفسه، وإنما يرسل السؤال إلى سيرفر واحد وينتظر الجواب الكامل.
• ال Recursive Resolver: السيرفر الذي يبحث نيابة عنك حتى يصل إلى الجواب، ويكون عادة عند مزود الإنترنت ISP أو خدمة عامة مثل 8.8.8.8 من Google أو 1.1.1.1 من Cloudflare، ويحتفظ بكل جواب في ذاكرة مؤقتة Cache حتى لا يكرر البحث.
• خوادم Root Servers: قمة الشجرة، ولا تعرف عنوان موقعك، لكنها تعرف من يدير كل امتداد أعلى Top-Level Domain واختصاراً TLD مثل .com و.org و.sa. وبحسب قائمة IANA فهي 13 اسماً من a.root-servers.net إلى m.root-servers.net تديرها 12 جهة مستقلة، وخلف هذه الأسماء أكثر من ألفي نسخة موزعة حول العالم بتقنية Anycast، أي أن العنوان نفسه تجيب عليه أقرب نسخة إليك.
• خوادم ال TLD: سيرفرات الامتداد، فسيرفرات .com مثلاً لا تعرف عنوان example.com، لكنها تعرف أي سيرفرات مسؤولة عنه.
• السيرفر الموثوق Authoritative Name Server: السيرفر الذي يحمل سجلات النطاق نفسه، وجوابه هو الجواب النهائي.

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

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:

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

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

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 الثلاثة عشر». الآن نسأل أحدها:

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

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

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

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

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

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

; <<>> 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 مباشرة:

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

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

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 عاماً مرتين بينهما عشرون ثانية، ونعرض أول سطر من كل جواب:

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

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

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، وسوف ترى أثره في قسم الأخطاء الشائعة.

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

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

• المسجل Registrar: الشركة التي اشتريت منها النطاق، وهي تسجله عند جهة الامتداد Registry، أي عند Verisign في حالة .com، وترسل إليها أسماء السيرفرات الموثوقة لنطاقك (سجلات NS)، وسجل DS إذا فعلت DNSSEC. وعندها تجدد النطاق وتعدل بيانات المالك.
• مزود DNS (DNS Hosting Provider): الجهة التي تشغل السيرفرات الموثوقة وتحمل المنطقة Zone بكل سجلاتها، وقد يكون المسجل نفسه، وهذا هو الوضع الافتراضي عند الشراء، أو مزوداً آخر مثل Cloudflare. فعندما تضيف نطاقك إلى Cloudflare يعطيك اسمي سيرفرين ويطلب منك أن تضعهما عند المسجل مكان السيرفرات القديمة.
• السيرفر ومزوده: الجهاز الذي يحمل عنوان IP ويشغل خدماتك، والجهة التي تملك هذا العنوان، أي مزود ال VPS أو مزود الإنترنت، هي وحدها التي تستطيع ضبط البحث العكسي PTR له كما سيأتي.

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

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

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

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

المنطقة Zone هي مجموعة السجلات التي يحملها السيرفر الموثوق لنطاقك، وكل سجل Resource Record له خمسة أجزاء: الاسم Name، ومدة البقاء TTL، والفئة Class وهي دائماً IN أي Internet، والنوع Type، ثم القيمة Value. والصيغة الأصلية للمنطقة هي ملف نصي بالشكل الذي يحدده RFC 1035 ويستخدمه BIND، ولوحات التحكم في الويب تعرض الحقول نفسها في جدول. والملف التالي منطقة كاملة لنطاق يستضيف موقعاً وتطبيقاً وبريداً على سيرفر واحد، وسوف نشرح كل سطر فيه في الأقسام التالية:

$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:

named-checkzone example.com example.com.zone

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

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.

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

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

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

سجل A يربط الاسم بعنوان IPv4، وسجل AAAA يربط الاسم بعنوان IPv6 كما في RFC 3596، وهما أكثر السجلات استخداماً، فكل اسم يصل إليه الناس ينتهي في النهاية بأحدهما. المثال التالي يسأل عن سجل A للنطاق example.com:

dig A example.com

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

; <<>> 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:

dig +short AAAA example.com

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

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 عند التحقق من نطاقك إذا وجدت سجل AAAA، فإذا كان العنوان خطأ أو يشير إلى سيرفر آخر فقد يفشل إصدار الشهادة وأنت تبحث عن المشكلة في سجل A الذي لا عيب فيه.

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

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

dig www.github.com +noall +answer

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

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 يمنع أن يكون مع سجل CNAME أي سجل آخر للاسم نفسه، والسبب أن ال Resolver عندما يجد CNAME يترك كل شيء ويذهب إلى الاسم الآخر، والنطاق الرئيسي فيه دائماً سجل SOA وسجلات NS، وغالباً MX وTXT، وبالتالي فإن وضع CNAME عليه يكسر هذه السجلات. ولو جربت إضافة السطر @ IN CNAME app.example.com. إلى ملف المنطقة السابق فسوف يرفضه named-checkzone بهذه الرسالة (حذفنا الأسطر المكررة):

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، فتتبع هي الاسم وتجيب الناس بسجل A عادي، ومزودون آخرون يسمونه ALIAS أو ANAME. وهذه حلول خاصة بكل مزود وليست جزءاً من معيار DNS.

وهناك قاعدة ثانية يقع فيها الكثيرون: RFC 2181 يمنع أن تشير سجلات MX أو NS إلى اسم هو CNAME، لذلك فالاسم mail.example.com الذي يشير إليه MX يجب أن يكون له سجل A (وAAAA) مباشر وليس CNAME.

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

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

dig MX gmail.com

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

; <<>> 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، والرقم الأصغر يجرب أولاً، فالسيرفر المرسل يحاول مع gmail-smtp-in صاحب الرقم 5، وإذا لم يستطع الوصول إليه انتقل إلى صاحب الرقم 10 ثم 20، والسجلات التي تتساوى أرقامها يوزع المرسل الرسائل بينها.
• القيمة اسم وليست عنواناً، ولكل اسم منها سجلات A وAAAA خاصة به.
• الأرقام نفسها لا معنى لها، المهم ترتيبها، فالأولويات 10 و20 مثل 1 و2 تماماً.

وعلى سيرفرك يكفي سجل واحد @ MX 10 mail.example.com. مع سجل A للاسم mail، وإذا لم يكن لنطاقك سجل MX أصلاً فإن المرسلين يرسلون إلى عنوان سجل A للنطاق نفسه، وهذا قد يوصل البريد إلى سيرفر الموقع دون أن تقصد. أما النطاق الذي لا يستقبل بريداً أبداً فيعلن ذلك بسجل Null MX بالقيمة 0 .. وإذا كنت تخطط لاستضافة بريد مؤسستك فابدأ من دليل استضافة البريد للمؤسسات فهو يجمع كل ما يلزم بالترتيب.

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

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

dig TXT example.com +noall +answer

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

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 للمبتدئين.
• إثبات ملكية النطاق للخدمات الخارجية كما في السطر الأول أعلاه.
• التحقق من ملكية النطاق عبر ال DNS (DNS Challenge) عند إصدار الشهادات، حيث يضع ال Reverse Proxy أو برنامج الشهادات سجل TXT مؤقتاً باسم _acme-challenge.example.com، وهذه الطريقة وحدها تصدر شهادات Wildcard.

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

سجل CAA (Certification Authority Authorization) يحدد جهات إصدار الشهادات Certificate Authorities المسموح لها بإصدار شهادات TLS لنطاقك، وRFC 8659 يلزم الجهة المصدرة بأن تفحصه قبل أن تصدر الشهادة. المثال التالي يبين سجل Google:

dig CAA google.com

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

; <<>> 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 نفسه يسمح بعدة جهات:

dig CAA letsencrypt.org +short

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

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 هو المعرف الرسمي الذي تبحث عنه Let's Encrypt. ولاحظ أن Caddy يستخدم Let's Encrypt وZeroSSL ويجرب الثانية إذا فشلت الأولى، فإذا حصرت CAA في Let's Encrypt وحدها فلن تنجح هذه المحاولة الاحتياطية، وهذا مقبول إذا كانت Let's Encrypt تكفيك، وإلا فأضف سجلاً لمعرف الجهة الأخرى أيضاً.

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

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

dig -x 8.8.8.8

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

; <<>> 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، والسبب أن DNS يقرأ الأسماء من اليمين إلى اليسار، من العام إلى الخاص، والعناوين تقرأ من اليسار إلى اليمين.

وهنا النقطة الأهم في هذا السجل: المنطقة in-addr.arpa الخاصة بعنوانك يملكها صاحب العنوان وليس صاحب النطاق، أي مزود ال VPS، لذلك لا تضبط PTR في لوحة مزود DNS، وإنما في لوحة مزود السيرفر، ففي Hetzner مثلاً تعدله من صفحة Networking للسيرفر بجانب العنوان. وسيرفرات البريد التي تستقبل رسائلك تفحص هذا السجل، فتسأل عن اسم العنوان الذي أرسل الرسالة، ثم تسأل عن عنوان هذا الاسم، وتتوقع أن تصل إلى العنوان نفسه، وهذا ما يسمى Forward-confirmed reverse DNS، وإرشادات Google للمرسلين تشترطه. لذلك فالإعداد الصحيح لسيرفر بريد على العنوان 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) تحدد السيرفرات الموثوقة للنطاق، ورأيتها في الإحالات في بداية المقال، والمثال التالي يسأل عنها مباشرة:

dig NS example.com +noall +answer

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

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

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

dig SOA example.com +short

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

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

والحقول بالترتيب كما يحددها RFC 1035: السيرفر الرئيسي للمنطقة، ثم بريد المسؤول مكتوباً بنقطة بدل @ أي [email protected]، ثم الرقم التسلسلي Serial الذي يزيد مع كل تعديل، ثم ثلاث مدد تستخدمها السيرفرات الثانوية Secondary Servers لمزامنة المنطقة (Refresh وRetry وExpire)، وآخر رقم هو مدة التخزين المؤقت السلبي، أي المدة التي يتذكر فيها ال Resolver أن اسماً غير موجود. ومزود DNS يدير هذا السجل بنفسه، فلن تحتاج إلى تعديله إلا إذا شغلت سيرفر DNS خاصاً بك.

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

سجل SRV (Service) يخبر البرامج أين تجد خدمة معينة لنطاقك، بالاسم والمنفذ معاً، وصيغته في RFC 2782، واسمه يبدأ بالخدمة والبروتوكول مثل _caldavs._tcp. المثال التالي يسأل عن خدمة التقويم CalDAV عند Fastmail:

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

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

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

والأرقام بالترتيب هي الأولوية Priority ثم الوزن Weight ثم المنفذ Port ثم اسم السيرفر، أي أن تطبيق التقويم الذي تعطيه عنوان بريدك فقط يستطيع أن يكتشف وحده أن خدمة التقويم على هذا السيرفر والمنفذ 443. وتستخدم برامج التقويم وجهات الاتصال هذه السجلات كما في RFC 6764، وبرامج البريد تستخدم سجلات مثل _submission._tcp و_imaps._tcp كما في RFC 6186، وهناك أيضاً _autodiscover._tcp للإعداد التلقائي Autodiscover في برامج البريد. ولن تكتب هذه السجلات من ذاكرتك، فخادم البريد الذي تثبته يعطيك قائمتها، وتوثيق mailcow مثلاً يذكرها كلها مع قيمها.

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

السجل الذي اسمه * مثل *.example.com A 203.0.113.10 يجيب عن أي اسم تحت النطاق ليس له سجل خاص به، فيصل wiki.example.com وtest.example.com وأي اسم آخر إلى سيرفرك دون أن تضيف له سجلاً، والقواعد التفصيلية في RFC 4592. وفي المقابل، النطاق الذي ليس عنده Wildcard يجيب عن الاسم غير الموجود بالحالة NXDOMAIN:

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

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

;; 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 يصبح إطلاق تطبيق جديد على اسم فرعي جديد خطوة في ال Reverse Proxy وحده، وإذا أضفت إليه شهادة Wildcard عبر التحقق من ملكية النطاق عبر ال DNS فلن تحتاج إلى شهادة لكل اسم.
• كل خطأ إملائي في اسم فرعي يصل إلى سيرفرك أيضاً، لذلك اجعل ال Reverse Proxy يرفض الأسماء التي لا يعرفها بدل أن يعرض أول تطبيق عنده.

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

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

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

لذلك عندما تنقل موقعك إلى سيرفر جديد، كما في دليل نقل ال Containers إلى خادم جديد، خطط لسجلات 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 بسحابة برتقالية أو رمادية، وهذه الخانة لا تخص DNS وحده، وإنما تحدد طريق الحركة نفسها:

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

ولاحظ أن عنواني example.com اللذين رأيتهما في بداية المقال، 104.20.23.154 و172.66.147.243، يقعان ضمن نطاقات العناوين التي تنشرها Cloudflare، أي أن ما رأيته هو عناوين Cloudflare وليس عنوان السيرفر الذي خلفها.

والقاعدة المهمة هنا أن ال Proxy يحمل حركة الويب فقط، ف Cloudflare تقول في التوثيق إن سجلات MX وTXT DNS only دائماً، وإن سجل A لسيرفر البريد يجب أن يكون DNS only كذلك، والسبب أن البريد يعمل على المنافذ 25 و587 و993 ببروتوكولات ليست HTTP، فلو جعلت mail.example.com Proxied لأجاب الاسم بعنوان Cloudflare، ولوصلت إليه سيرفرات البريد فلا تجد من يستقبل الرسائل. والأمر نفسه مع SSH وWireGuard وأي خدمة ليست ويب. ويجدر الإشارة هنا إلى نتيجة لا ينتبه لها الكثيرون: إذا كان البريد والموقع على السيرفر نفسه فإن سجل mail يكشف عنوان السيرفر لأي شخص، فلا تعتمد على ال Proxy لإخفائه، وإنما قم بتأمين السيرفر كأن عنوانه معروف للجميع.

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

صمم DNS في الثمانينات بدون أي توقيع، فال Resolver يقبل الجواب الذي يصله دون أن يتأكد ممن أرسله، وهذا يسمح نظرياً بتسميم الذاكرة المؤقتة Cache Poisoning، أي أن يحفظ ال Resolver جواباً مزوراً يرسل الناس إلى عنوان آخر. والحل هو DNSSEC (DNS Security Extensions)، حيث يوقع مزود DNS كل مجموعة سجلات توقيعاً رقمياً Digital Signature يأتي معها في سجل RRSIG، ويضع المسجل عند جهة الامتداد سجل DS يربط مفتاح منطقتك بالمستوى الذي فوقها، وهكذا حتى خوادم Root، وبالتالي يستطيع ال Resolver أن يتحقق من أن الجواب لم يعدل في الطريق. المثال التالي يطلب التوقيع مع الجواب:

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

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

;; ->>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 هو التوقيع نفسه. والآن لنكسر الأمر لنفهمه، فالنطاق التالي نطاق اختبار توقيعه مكسور عمداً:

dig A dnssec-failed.org +noall +comments

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

;; ->>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 قبل أن يحذف سجل DS لهذا السبب، وتشرح طريقة النقل الآمن في صفحة DNSSEC.

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

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

sudo apt install bind9-dnsutils

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

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

nslookup -type=mx gmail.com 8.8.8.8

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

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: واجهة ويب لأمر dig من Google، تختار فيها نوع السجل وترى الجواب.
• MXToolbox SuperTool: تفحص سجلات 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 إلى سيرفر لم يعد موجوداً، لذلك اسأل عن النوعين بعد كل تغيير.
• 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، واختيار السيرفر الذي سوف تشير إليه كل هذه السجلات:

دليلNginx Proxy Manager: نطاقات وشهادات TLS لكل خدماتكبدلاً من فتح منفذ مستقل لكل تطبيق، يتيح لك Nginx Proxy Manager أن تربط كل خدمة بنطاقها وتمنحها شهادة HTTPS مجانية من واجهة بسيطة، دون أن تكتب إعدادات Nginx بنفسك.دليلكيف تستضيف بريد مؤسستك بنفسك: دليل عملي من القرار إلى التشغيلمتى تستضيف بريد شركتك أو جامعتك بنفسك ومتى يكون البريد المستضاف أنسب، وما الذي تجهزه قبل البدء، وكيف تنقل المستخدمين على مراحل دون أن تضيع رسالة، مع مسار قراءة يجمع كل أدلة البريد على الموقع.دليلشرح SPF وDKIM وDMARC للمبتدئين: كيف تثبت أن رسائلك منك فعلاًلماذا يستطيع أي شخص أن يرسل باسم نطاقك، وكيف جاء كل من SPF وDKIM وDMARC ليسد ثغرة تركها الذي قبله، مع قراءة السجلات جزءاً جزءاً وطرق اختبار بريدك بالخدمات المجانية.دليلتثبيت خادم البريد mailcow باستخدام Dockerأن تدير خادم بريدك بنفسك يعني أن تضمن وصول رسائلك إلى صندوق الوارد لا إلى الرسائل المزعجة. يشرح هذا الدليل تثبيت mailcow، وضبط سجلات DNS المطلوبة، وحل مشكلات التسليم الشائعة.دليلكيف تختار خادماً افتراضياً VPSكم تحتاج من المعالج والذاكرة والقرص؟ وما الذي يميز مزوداً عن آخر غير السعر؟ يساعدك هذا الدليل على اختيار خادم 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 على نطاقات عامة وعلى ملف منطقة تجريبي.