أنواع DNS Records 2026: شرح A, AAAA, MX, CNAME, TXT الكامل

إذا كنت تدير موقعًا أو سيرفرًا، فلا بد أن تكون قد سمعت بمصطلحات مثل سجل A و MX و CNAME. هذه السجلات هي اللبنات الأساسية التي يقوم عليها نظام أسماء النطاقات (DNS) في الإنترنت. فهم أنواع DNS Records بشكل عميق يحرّرك من الاعتماد الكلي على دعم الاستضافة، ويمنحك القدرة على تشخيص أي مشكلة في موقعك أو بريدك خلال دقائق. في هذا الدليل الموسّع لعام 2026، سنشرح كل نوع من السجلات بالتفصيل، مع أمثلة عملية، وأوامر للاختبار، ونصائح من واقع التجربة.

ما هي DNS Records ولماذا تحتاج فهمها؟

سجلات DNS هي ببساطة “إدخالات” مخزّنة في خوادم DNS الموثوقة، تخبر العالم بمعلومات معينة عن نطاقك. كل سجل يحوي اسمًا، نوعًا، قيمة، ومدة TTL. عندما يكتب أحدهم اسم موقعك في المتصفح، يبدأ المتصفح بسلسلة من الاستعلامات تنتهي بالعثور على سجل A أو AAAA لاسم النطاق، ومنه يحصل على عنوان IP السيرفر الذي يستضيف الموقع.

لكن DNS لا يقتصر على ربط الأسماء بـ IPs، بل يفعل أكثر من ذلك بكثير. مثلًا، يخبر سيرفرات البريد إلى أين ترسل الرسائل (سجل MX). يثبت ملكية النطاق لخدمات مثل Google Search Console (سجل TXT). يحدّد الخوادم المخوّلة بإصدار شهادات SSL لنطاقك (سجل CAA). يوجّه الزائرين إلى نطاقات بديلة (سجل CNAME). فهم أنواع DNS Records المختلفة يفتح لك بابًا واسعًا في إدارة بنيتك التحتية على الإنترنت.

في عام 2026، أصبح فهم DNS أكثر أهمية من أي وقت مضى. مع انتشار IPv6، وتوسع استخدام DNSSEC، وتعقّد إعدادات البريد بـ SPF و DKIM و DMARC، أصبح كل مدير موقع بحاجة إلى معرفة عميقة بهذه السجلات. كذلك مع التحول إلى البنية الموزعة (multi-cloud)، أصبح استخدام DNS كأداة لتوزيع الحمل أمرًا شائعًا.

• تشخيص مشاكل الموقع بسرعة دون الانتظار للدعم.
• إدارة عمليات النقل والتحويل بين السيرفرات بسلاسة.
• إعداد البريد الاحترافي والإيميلات الفرعية.
• تأمين النطاق بـ DNSSEC و CAA.
• تنفيذ استراتيجيات SEO متقدمة عبر التحويلات.

كيف يعمل نظام DNS بشكل عام

قبل الغوص في تفاصيل كل نوع من أنواع DNS Records، من المهم فهم الإطار العام لعملية الاستعلام. النظام يبدأ من العميل (متصفح أو تطبيق)، الذي يطلب من DNS Resolver المحلي (عادة في الموجّه أو الـ ISP) ترجمة اسم النطاق إلى IP. الـ Resolver يبحث في الكاش أولًا، فإن لم يجد، يبدأ سلسلة استعلامات من الجذر (root servers) إلى الـ TLD ثم إلى الـ Authoritative Nameservers الخاصة بنطاقك.

الـ Authoritative Nameserver هو الخادم الذي يحوي السجلات الفعلية لنطاقك. عندما تشتري نطاقًا وتختار nameservers من Cloudflare أو من استضافتك أو من مرام، فأنت في الواقع تخبر مسجّل النطاق بأن هذه الخوادم هي المصدر الموثوق لكل معلومات DNS عن نطاقك. أي تعديل تجريه في لوحة DNS، يُحدَّث على هذه الخوادم.

# تتبع مسار استعلام DNS كاملًا
dig +trace example.com

# استعلام مباشر من خادم Cloudflare العام
dig @1.1.1.1 example.com

# استعلام مباشر من خادم Google العام
dig @8.8.8.8 example.com

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

أنواع DNS Records: سجل A Record: ربط النطاق بـ IPv4

سجل A هو أكثر أنواع DNS Records شهرة وأهمية. اسمه اختصار لكلمة “Address”. وظيفته الأساسية: ربط اسم النطاق بعنوان IPv4 محدد. كل موقع تزوره ينتهي به الأمر إلى استعلام لسجل A أو AAAA. ببساطة، عندما يطلب متصفحك example.com، فإنه في النهاية يبحث عن سجل A للنطاق ليعرف الـ IP الذي يجب أن يتصل به.

; مثال على سجلات A
example.com.        IN    A    203.0.113.10
www.example.com.    IN    A    203.0.113.10
blog.example.com.   IN    A    203.0.113.20
mail.example.com.   IN    A    203.0.113.30

; استعلام عن سجل A
dig +short A example.com

يمكن لاسم نطاق واحد أن يحوي أكثر من سجل A، وفي هذه الحالة يقوم الـ resolver بتوزيع الطلبات على هذه الـ IPs بطريقة round-robin. هذه تقنية بدائية لتوزيع الحمل بين سيرفرات متعددة، رغم أنها لا توفّر health checks (إن سقط أحد السيرفرات، يستمر DNS في إرسال زوار له). لتوزيع حمل أكثر ذكاءً، يُستخدم Anycast أو خدمات GSLB (Global Server Load Balancing).

في إعداد سجل A، يجب الحرص على عدم استخدام IP خاص (private IP) إن كنت تنشر السجل علنيًا. الـ IPs الخاصة مثل 192.168.x.x و 10.x.x.x لا تعمل من خارج شبكتك المحلية. للتعرف أكثر على إدارة السيرفرات، اطّلع على دليل أوامر Linux الشامل.

أنواع DNS Records: سجل AAAA Record: ربط النطاق بـ IPv6

سجل AAAA (يُنطق “Quad-A”) هو نظير سجل A، لكن لـ IPv6 بدلًا من IPv4. مع نفاد عناوين IPv4 العالمية، أصبح IPv6 ضرورة لا اختيار. في عام 2026، تجاوزت نسبة استخدام IPv6 على مستوى العالم 50%، مع شركات كبرى مثل Google و Facebook و Cloudflare تدعمه افتراضيًا. عنوان IPv6 يُكتب بصيغة سداسية عشرية مفصولة بـ colon، مثل 2001:db8::1.

; مثال على سجل AAAA
example.com.    IN    AAAA    2001:db8:85a3:0:0:8a2e:370:7334
www.example.com. IN   AAAA    2001:db8:85a3::8a2e:370:7334

; الاستعلام عن سجل AAAA
dig +short AAAA example.com

إن كان سيرفرك يدعم IPv6، يُنصح بشدة بإضافة سجل AAAA إلى جانب A. هذا يضمن وصول زوارك بأسرع طريقة ممكنة بغض النظر عن إصدار IP الذي يستخدمونه. لو لم يكن لديك سجل AAAA وكان زائرك يستخدم IPv6 فقط، سيضطر إلى استخدام آليات ترجمة بطيئة قد تؤخر التحميل بثوانٍ.

التأكد من عمل IPv6 يتطلب اختبارًا فعليًا. استخدم أدوات مثل curl -6 https://example.com أو ping6 example.com. أيضًا تأكد من أن الـ Firewall على سيرفرك يسمح بحركة IPv6، فكثير من المشرفين ينسون فتح المنافذ لـ IPv6 ويظنون أن ufw يطبّق نفس القواعد على الإصدارين تلقائيًا.

أنواع DNS Records: سجل MX Record: توجيه البريد الإلكتروني

سجل MX (Mail Exchanger) يُحدِّد سيرفر البريد المسؤول عن استقبال الرسائل لنطاقك. عندما يرسل أحد ما بريدًا إلى [email protected]، يبحث سيرفر البريد المرسل عن سجلات MX لـ example.com، ثم يتصل بالخادم المذكور فيها. سجل MX يحتوي على قيمتين: الأولوية (preference)، واسم الخادم (mail server).

; مثال على سجلات MX
example.com.    IN    MX    10    mail1.example.com.
example.com.    IN    MX    20    mail2.example.com.
example.com.    IN    MX    30    backup-mail.example.com.

; الاستعلام عن سجلات MX
dig +short MX example.com

الأولوية رقم منخفض يعني أولوية أعلى. في المثال أعلاه، يجرّب سيرفر الإرسال أولًا mail1، فإن فشل ينتقل إلى mail2، ثم إلى backup-mail. هذا يوفّر redundancy، فحتى لو سقط سيرفر بريدك الأساسي، تظل الرسائل تصل إلى السيرفرات البديلة.

قاعدة مهمة في سجلات MX: قيمة السجل يجب أن تكون اسم نطاق وليست IP. لو حاولت وضع IP مباشرة، سترفض كثير من خوادم البريد الرسائل (وفقًا لـ RFC 5321). هذا يعني أنك تحتاج أيضًا إلى سجل A للخادم المذكور في MX. مثلًا mail1.example.com يجب أن يكون له سجل A يشير إلى IP الخادم.

أنواع DNS Records: سجل CNAME Record: الأسماء المستعارة

سجل CNAME (Canonical Name) يُستخدم لإنشاء اسم مستعار (alias) لنطاق آخر. مثلًا، يمكنك جعل www.example.com مستعارًا لـ example.com، فعندما يطلب أحدهم سجل A لـ www، يقوم الـ resolver أولًا بقراءة سجل CNAME، ثم يتبع التحويل ويستعلم عن A لـ example.com مباشرة. هذا يوفّر مرونة كبيرة، إذ لو غيّرت IP السيرفر، تكفي تحديث سجل A واحد، وتتبعه كل الـ CNAMEs تلقائيًا.

; مثال على سجلات CNAME
www.example.com.    IN    CNAME    example.com.
shop.example.com.   IN    CNAME    myshop.shopify.com.
docs.example.com.   IN    CNAME    example.netlify.app.

; الاستعلام عن CNAME
dig +short CNAME www.example.com

CNAME شائع جدًا في خدمات SaaS مثل Shopify و Netlify و Cloudflare Pages. هذه الخدمات لا تتيح لك معرفة IPs خوادمها (لأنها قد تتغير ديناميكيًا)، فتطلب منك إنشاء CNAME يشير إلى نطاقها الفرعي على خدمتها. وهذا يعمل بشكل ممتاز.

لكن CNAME يأتي مع قيود مهمة. القاعدة الذهبية: لا يمكن أن يحوي اسم نطاق سجل CNAME وسجلًا آخر من نوع مختلف (باستثناء DNSSEC). هذا يعني أنك لا تستطيع جعل النطاق الجذر example.com CNAME، لأنه يحتاج عادة إلى MX و SOA و NS. لذلك CNAME على النطاق الجذر ممنوع تقنيًا في DNS التقليدي. الحل: استخدام ALIAS أو ANAME (وهي ميزات غير قياسية يقدمها بعض موفري DNS).

أنواع DNS Records: سجل TXT Record: استخدامات متعددة

سجل TXT هو أكثر أنواع DNS Records مرونة. كان في الأصل مصممًا لإضافة معلومات نصية حرة عن النطاق، لكنه تطوّر ليصبح حاوية لعدد كبير من البروتوكولات. اليوم، سجلات TXT تستخدم لـ SPF، DKIM، DMARC، التحقق من ملكية النطاق لخدمات Google و Microsoft، والـ BIMI لشعارات البريد، والكثير غيرها.

; مثال على سجلات TXT متنوعة
example.com.            IN    TXT    "v=spf1 ip4:203.0.113.10 ~all"
_dmarc.example.com.     IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
example.com.            IN    TXT    "google-site-verification=abc123def456"
example.com.            IN    TXT    "MS=ms12345678"

; الاستعلام عن كل سجلات TXT
dig +short TXT example.com

قاعدة مهمة في TXT: السجل الواحد يمكن أن يحوي حتى 255 حرفًا فقط ضمن string واحدة. لو احتجت إلى قيمة أطول (شائع في DKIM)، يجب تقسيمها إلى عدة strings داخل السجل نفسه، يُلصق كل منها بـ quotes. معظم لوحات DNS الحديثة تتعامل مع هذا تلقائيًا، لكن لو كنت تكتب الـ zone file يدويًا فيجب أن تنتبه.

في 2026 ظهر استخدام جديد لـ TXT: تخزين سياسات BIMI (Brand Indicators for Message Identification). هذا البروتوكول يسمح بعرض شعار شركتك بجانب رسائل البريد في عملاء البريد الذين يدعمونه (مثل Gmail و Yahoo). يتم ذلك بإنشاء سجل TXT تحت default._bimi.example.com يشير إلى ملف SVG لشعارك.

أنواع DNS Records: سجل NS Record: تحديد nameservers

سجلات NS (Name Server) تخبر العالم بأي خوادم DNS تتولى الإجابة عن الاستعلامات الخاصة بنطاقك. هي السجلات الأساسية التي يضعها مسجّل النطاق على مستوى TLD، وتُكرَّر داخل الـ zone file نفسه أيضًا. عندما تنقل نطاقك من Cloudflare إلى مرام مثلًا، فإنك في الواقع تغيّر سجلات NS الخاصة به.

; مثال على سجلات NS
example.com.    IN    NS    ns1.maram.iq.
example.com.    IN    NS    ns2.maram.iq.

; الاستعلام عن NS
dig +short NS example.com

عادة، يُوصى بأن يكون لديك على الأقل اثنان من Nameservers، لتوفير redundancy. السبب أن سقوط nameserver واحد يعني أن نطاقك سيكون متاحًا فقط من خلال الكاش، وعند انتهاء TTL، يصبح غير قابل للوصول. وجود اثنين أو أكثر يضمن الاستمرارية.

يمكنك أيضًا استخدام سجلات NS داخليًا لتفويض إدارة subdomain إلى خادم آخر. مثلًا، تستطيع تفويض إدارة blog.example.com إلى nameservers مختلفة بإضافة سجل NS داخلي. هذا مفيد جدًا في البنى الكبيرة، حيث تدير قسم منفصل من النطاق فريق آخر.

سجلات SOA و SRV و PTR

سجل SOA (Start of Authority) هو سجل واحد لكل نطاق، يحوي معلومات إدارية مهمة. منها: اسم الـ primary nameserver، عنوان البريد الإلكتروني للمشرف (مع استبدال @ بنقطة)، رقم الـ serial، ومدد التحديث المختلفة (refresh, retry, expire, minimum TTL).

; مثال على سجل SOA
example.com.    IN    SOA    ns1.maram.iq. admin.example.com. (
                            2026042701 ; serial
                            3600       ; refresh (1 hour)
                            1800       ; retry (30 minutes)
                            1209600    ; expire (2 weeks)
                            86400 )    ; minimum TTL (1 day)

سجل SRV (Service) يُستخدم لتوجيه الخدمات المختلفة إلى خوادم محددة بمنافذ معينة. مثال: VoIP، Jabber/XMPP، Microsoft Exchange، Minecraft Servers. يأخذ شكلًا خاصًا: _service._protocol.example.com، وقيمته تحوي priority, weight, port, target.

; مثال على سجل SRV لخدمة SIP
_sip._tcp.example.com.    IN    SRV    10 60 5060 sipserver.example.com.
; الأرقام: priority=10, weight=60, port=5060

; مثال لـ XMPP
_xmpp-server._tcp.example.com.    IN    SRV    5 0 5269 xmpp.example.com.

سجل PTR (Pointer) هو العكس من سجل A. بدلًا من ربط اسم بـ IP، يربط IP باسم. يستخدم في reverse DNS lookup، وله أهمية خاصة في خوادم البريد. كثير من سيرفرات البريد ترفض الرسائل القادمة من IPs لا تحتوي على PTR صحيح. لإعداد PTR، يجب التواصل مع المُزوّد الذي يملك الـ IP (وهو غالبًا مزود الاستضافة).

أنواع DNS Records للأمان (CAA, DS, DNSKEY)

مع تزايد التهديدات، ظهرت أنواع DNS Records جديدة مخصصة للأمان. سجل CAA (Certification Authority Authorization) يحدد المؤسسات المخوّلة بإصدار شهادات SSL لنطاقك. هذا يمنع جهة غير مصرح لها من الحصول على شهادة باسم نطاقك حتى لو وقع اختراق في إحدى CAs.

; مثال على سجل CAA
example.com.    IN    CAA    0 issue "letsencrypt.org"
example.com.    IN    CAA    0 issue "sectigo.com"
example.com.    IN    CAA    0 issuewild ";"
example.com.    IN    CAA    0 iodef "mailto:[email protected]"

السجلان DNSKEY و DS مرتبطان بـ DNSSEC، وهي تقنية توقّع سجلات DNS رقميًا لمنع التزوير. DNSKEY يحوي المفتاح العام، و DS يُوضع على مستوى TLD ليثبت ارتباط المفتاح بنطاقك. تفعيل DNSSEC في 2026 أصبح ضرورة، خصوصًا للنطاقات التي تتعامل بالأموال أو البيانات الحساسة.

تفعيل DNSSEC يتم عادة بأمر بسيط في لوحة DNS، ثم نسخ سجل DS وإضافته في لوحة مسجّل النطاق. بعد ذلك يبدأ كل resolver يدعم DNSSEC في التحقق من سلامة كل سجل DNS لنطاقك. لمزيد من معلومات الأمان، اطّلع على دليل شهادة SSL الشامل.

مدة TTL وتأثيرها على أنواع DNS Records على DNS

TTL اختصار لـ Time To Live، وهي القيمة (بالثواني) التي تخبر الـ resolvers بمدة الاحتفاظ بالسجل في الكاش قبل إعادة الاستعلام. القيم الشائعة: 300 (5 دقائق)، 3600 (ساعة)، 86400 (يوم). اختيار القيمة المناسبة يعتمد على طبيعة استخدامك.

• TTL منخفض (60-300 ثانية): مناسب أثناء النقل، يُتيح انتشار التغييرات بسرعة. لكن يضع ضغطًا أكبر على خوادم DNS.
• TTL متوسط (3600 ثانية): مناسب للاستخدام العادي. توازن بين الأداء وسرعة الانتشار.
• TTL مرتفع (86400 ثانية): للسجلات النادرة التغير. يحسّن الأداء لكنه يجعل أي تغيير بطيء الانتشار.

قبل أي عملية نقل سيرفر، خفّض TTL إلى 300 ثانية قبل النقل بـ 24 ساعة على الأقل. بعد اكتمال النقل والتأكد من استقراره، أعِد القيم إلى 3600 أو أكثر. هذا يجعل عملية النقل سلسة جدًا. للمزيد عن النقل اطّلع على دليل نقل المواقع.

كيف تدير DNS Records في cPanel

إدارة أنواع DNS Records في cPanel سهلة جدًا. ادخل إلى لوحة cPanel، ثم ابحث عن أداة “Zone Editor” أو “DNS Zone Editor”. ستجد قائمة بكل نطاقاتك. اضغط على “Manage” أمام النطاق المطلوب، وستظهر لك كل السجلات الحالية.

لإضافة سجل جديد، اضغط على “Add Record”، اختر النوع من القائمة المنسدلة، أدخل الاسم والقيمة وقيمة TTL. مثلًا لإضافة سجل A لـ subdomain اسمه blog، يكون الاسم “blog” والنوع A والقيمة هي IP السيرفر. لتعديل سجل موجود، اضغط على “Edit” بجانبه. لحذف سجل، استخدم زر “Delete”.

# في WHM، إدارة DNS عبر السطر
# عرض sigorum DNS لنطاق
cat /var/named/example.com.db

# إعادة تحميل DNS بعد تعديل يدوي
rndc reload example.com

# اختبار سرعة استعلام DNS
dnsperf -d query_file.txt -s ns1.example.com

إن كنت تستخدم Cloudflare لإدارة DNS، فالواجهة مشابهة جدًا. ادخل إلى لوحة Cloudflare، اختر النطاق، اذهب إلى تبويب DNS. ستجد كل السجلات معروضة بوضوح، مع إمكانية تفعيل أو إلغاء الـ proxy (السحابة البرتقالية) لكل سجل. الـ proxy يفعّل CDN و WAF لـ Cloudflare، لكنه يخفي IP الأصلي للسيرفر، مما قد يسبب مشاكل في بعض السيناريوهات.

أخطاء شائعة في إعداد DNS Records

من أكثر الأخطاء شيوعًا في إعداد أنواع DNS Records: نسيان النقطة الأخيرة في FQDN. في ملفات zone التقليدية، اسم النطاق الكامل يجب أن ينتهي بنقطة، مثل example.com.. لو أغفلت النقطة، يضيف السيرفر اسم zone تلقائيًا، فيصبح الاسم example.com.example.com وهو خطأ.

الخطأ الثاني: محاولة وضع CNAME على النطاق الجذر. هذا ممنوع تقنيًا، استخدم بدلًا من ذلك ALIAS أو ANAME أو سجلًا A مباشرًا. الخطأ الثالث: استخدام MX يشير إلى CNAME بدلًا من سجل A مباشرة، وهذا قد يسبب مشاكل في تسليم البريد. الخطأ الرابع: عدم تطابق سجل PTR مع سجل A، وهو ضروري لاجتياز اختبارات سيرفرات البريد.

• نسيان تخفيض TTL قبل النقل.
• إنشاء سجلين متضادين لنفس الاسم.
• إدخال IP في سجل MX بدلًا من اسم نطاق.
• تفعيل DNSSEC ثم نقل DNS لمزود لا يدعمه.
• استخدام underscore (_) في أسماء النطاقات (ممنوع للـ A و CNAME).
• عدم تكرار سجلات NS داخل zone file.
• وضع TTL مرتفع جدًا على سجل قد يحتاج تغييرًا قريبًا.

الخلاصة

فهم أنواع DNS Records هو أساس كل عمل احترافي على الإنترنت. سجلات A و AAAA تربط نطاقك بالسيرفر. MX يوجّه البريد. CNAME ينشئ أسماء مستعارة مرنة. TXT يخدم عشرات البروتوكولات من SPF إلى التحقق. NS يحدد خوادم DNS الموثوقة. وسجلات الأمان مثل CAA و DNSSEC ترفع مستوى الحماية. مع TTL المضبوط بحكمة، تستطيع إدارة بنيتك التحتية بمرونة واحترافية. الاستثمار في فهم هذه السجلات يوفّر عليك ساعات طويلة من التشخيص في المستقبل، ويجعلك قادرًا على بناء حلول متقدمة لأي تحدٍ يواجه نطاقك.