الدليل الشامل لأنواع سجلات DNS: التكوين العملي من سجل A إلى CAA

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

جدول مقارنة سريع لأنواع سجلات DNS العشرة

1. سجل A (Address Record)

التعريف

يربط سجل A اسم النطاق بعنوان IPv4 بحجم 32 بت. وهو أكثر أنواع سجلات DNS أساسيةً.

الصيغة

name.example.com.  IN  A  192.0.2.1

أمثلة عملية

; الموقع الرئيسي
example.com.       300  IN  A  203.0.113.10

; نطاق فرعي لواجهة API
api.example.com.   300  IN  A  203.0.113.20

; سجلات متعددة لتوزيع الحمل
example.com.       300  IN  A  203.0.113.10
example.com.       300  IN  A  203.0.113.11

الأخطاء الشائعة

• استخدام TTL مرتفع جدًا أثناء الترحيل (يمنع التراجع السريع)
• نسيان تحديث جميع سجلات A عند تغيير الخادم
• وضع سجل A وCNAME على نفس الاسم (تعارض مع RFC)

2. سجل AAAA (IPv6 Address Record)

التعريف

المكافئ لسجل A ولكن لعناوين IPv6 بحجم 128 بت. ضروري لدعم الإنترنت الحديث.

الصيغة

example.com.  IN  AAAA  2001:0db8:85a3::8a2e:0370:7334

أمثلة عملية

example.com.       300  IN  AAAA  2606:4700:3030::6815:1234
api.example.com.   300  IN  AAAA  2606:4700:3030::6815:5678

الأخطاء الشائعة

• نشر سجل AAAA دون أن يدعم الخادم فعليًا اتصالات IPv6
• عدم اختبار استبيان IPv6 بشكل منفصل عن IPv4

3. سجل CNAME (Canonical Name)

التعريف

ينشئ اسمًا مستعارًا يشير إلى الاسم القانوني لنطاق آخر. يقوم DNS بحل CNAME أولاً ثم يُعيد عنوان IP النهائي.

الصيغة

alias.example.com.  IN  CNAME  target.example.com.

أمثلة عملية

; www يشير إلى النطاق الجذري
www.example.com.      3600  IN  CNAME  example.com.

; نطاق فرعي يشير إلى CDN
cdn.example.com.      3600  IN  CNAME  d1234.cloudfront.net.

; نطاق فرعي لمنصة SaaS
blog.example.com.     3600  IN  CNAME  custom.ghost.io.

الأخطاء الشائعة

• استخدام CNAME على النطاق الجذري (apex) — محظور بموجب RFC 1034 — استخدم A/AAAA أو ALIAS
• إنشاء سلسلة CNAME (CNAME يشير إلى CNAME آخر) — يسبب تأخيرًا
• وضع CNAME مع MX أو TXT على نفس الاسم

4. سجل MX (Mail Exchange)

التعريف

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

الصيغة

example.com.  IN  MX  priority  mail-server.

أمثلة عملية

; Google Workspace
example.com.  3600  IN  MX  1   aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt4.aspmx.l.google.com.

; Microsoft 365
example.com.  3600  IN  MX  0   example-com.mail.protection.outlook.com.

الأخطاء الشائعة

• توجيه MX إلى CNAME (يجب أن يكون اسم مضيف له سجل A/AAAA)
• نسيان النقطة النهائية في اسم الخادم
• عدم تكوين سجلات MX احتياطية

5. سجل TXT (Text Record)

التعريف

يخزن نصًا عشوائيًا مرتبطًا بالنطاق. يُستخدم على نطاق واسع للتحقق من الملكية ومصادقة البريد الإلكتروني (SPF وDKIM وDMARC) وسياسات الأمان.

الصيغة

example.com.  IN  TXT  "record-text"

أمثلة عملية

; SPF
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; التحقق من النطاق (Google)
example.com.  3600  IN  TXT  "google-site-verification=abc123def456"

; DMARC
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

الأخطاء الشائعة

• وجود سجلات SPF متعددة على نفس النطاق (يجب أن يكون واحدًا فقط)
• تجاوز حد 255 حرفًا لكل سلسلة دون استخدام التسلسل
• تجاوز 10 عمليات بحث DNS في SPF (يسبب permerror)

6. سجل NS (Name Server)

التعريف

يحدد خوادم الأسماء المعتمدة لمنطقة DNS. تُعيَّن هذه السجلات لدى المسجّل وفي المنطقة نفسها.

الصيغة

example.com.  IN  NS  ns1.provider.com.

أمثلة عملية

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

; تفويض نطاق فرعي
dev.example.com.  86400  IN  NS  ns1.dev-provider.com.
dev.example.com.  86400  IN  NS  ns2.dev-provider.com.

الأخطاء الشائعة

• عدم تطابق NS لدى المسجّل مع المُعلن في المنطقة
• استخدام خادم أسماء واحد فقط (بدون تكرار)
• NS يشير إلى CNAME (محظور)

7. سجل SOA (Start of Authority)

التعريف

أول سجل إلزامي في أي منطقة DNS. يحتوي على المعلومات الإدارية مثل الرقم التسلسلي وفترات التحديث وانتهاء الصلاحية.

الصيغة

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
    2026052201  ; Serial (YYYYMMDDNN)
    7200        ; Refresh (ساعتان)
    3600        ; Retry (ساعة واحدة)
    1209600     ; Expire (14 يومًا)
    300         ; Negative TTL (5 دقائق)
)

الأخطاء الشائعة

• عدم زيادة الرقم التسلسلي بعد التعديلات (الخوادم الثانوية لا تُحدّث)
• فترة Expire قصيرة جدًا (تختفي المنطقة إذا أصبح الخادم الأساسي غير متاح)

8. سجل PTR (Pointer Record)

التعريف

يقوم بالتعيين العكسي: بالنظر إلى عنوان IP، يُعيد اسم المضيف المرتبط. يُكوَّن في المنطقة العكسية (in-addr.arpa أو ip6.arpa).

الصيغة

1.2.0.192.in-addr.arpa.  IN  PTR  server.example.com.

أمثلة عملية

; عكسي IPv4
10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.

; عكسي IPv6
4.3.2.1.0.7.3.0.e.2.a.8.0.0.0.0.3.a.5.8.8.b.d.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  host.example.com.

الأخطاء الشائعة

• عدم طلب تكوين PTR من مزود الاستضافة (نادرًا ما تتحكم في المنطقة العكسية)
• عدم تطابق PTR مع سجل A (يؤدي إلى رفض البريد الإلكتروني)

9. سجل SRV (Service Record)

التعريف

يحدد المضيف والمنفذ لخدمة معينة، مما يتيح الاكتشاف التلقائي للخدمات.

الصيغة

_service._protocol.example.com.  IN  SRV  priority  weight  port  host.

أمثلة عملية

; Microsoft Teams / SIP
_sip._tls.example.com.       3600  IN  SRV  100  1  443  sipdir.online.lync.com.
_sipfederationtls._tcp.example.com.  3600  IN  SRV  100  1  5061  sipfed.online.lync.com.

; XMPP
_xmpp-server._tcp.example.com.  3600  IN  SRV  5  0  5269  xmpp.example.com.

الأخطاء الشائعة

• نسيان الشرطة السفلية (underscore) في أسماء الخدمة والبروتوكول
• الخلط بين الأولوية والوزن (الأولوية الأقل = يُجرَّب أولاً)

10. سجل CAA (Certification Authority Authorization)

التعريف

يحدد سلطات الشهادات (CAs) المصرح لها بإصدار شهادات SSL/TLS للنطاق. طبقة أمان إضافية ضد الإصدار غير المصرح به.

الصيغة

example.com.  IN  CAA  flags  tag  "value"

أمثلة عملية

; السماح فقط لـ Let's Encrypt
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"

; السماح لـ Let's Encrypt وDigiCert
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"
example.com.  3600  IN  CAA  0  issue  "digicert.com"

; تقييد wildcard لسلطة شهادات محددة
example.com.  3600  IN  CAA  0  issuewild  "letsencrypt.org"

; إشعار في حالة الانتهاك
example.com.  3600  IN  CAA  0  iodef  "mailto:security@example.com"

CA/B Forum Ballot SC-081v3 — سياسة صلاحية الشهادات الجديدة

في أبريل 2025، وافق CA/Browser Forum على Ballot SC-081v3 الذي يُقلّص تدريجيًا الحد الأقصى لصلاحية شهادات SSL/TLS:

الأثر العملي: مع شهادات بصلاحية 47 يومًا، تصبح الأتمتة عبر ACME (مثل Let’s Encrypt وZeroSSL) إلزامية. تكتسب سجلات CAA أهمية بالغة لأنها تحدد أي سلطات الشهادات يمكنها إصدار التجديدات التلقائية لنطاقك.

الأخطاء الشائعة

• عدم تكوين CAA والسماح لأي CA بإصدار شهادات لنطاقك
• نسيان إضافة CA المستخدمة لـ wildcard في وسم issuewild
• عدم تضمين iodef لتلقي تنبيهات عن المحاولات غير المصرح بها

مصادقة البريد الإلكتروني: SPF وDKIM وDMARC

متطلبات Google/Yahoo لعام 2024

اعتبارًا من فبراير 2024، تُلزم Google وYahoo المرسلين بكميات كبيرة (أكثر من 5000 رسالة يوميًا) بتطبيق:

1. SPF — سجل صالح ومكوَّن بشكل صحيح
2. DKIM — توقيع متوافق مع نطاق المرسل
3. DMARC — سياسة لا تقل عن p=none

المرسلون الذين لا يستوفون هذه المتطلبات سيواجهون رفض رسائلهم أو تصنيفها كبريد عشوائي.

تكوين SPF الكامل

; SPF — Google Workspace + Mailchimp
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

القواعد الأساسية:

• حد أقصى 10 عمليات بحث DNS (include وa وmx وredirect تُحتسب جميعها)
• استخدم ~all (softfail) أثناء الاختبار، و-all (hardfail) في الإنتاج
• سجل SPF واحد فقط لكل نطاق

تكوين DKIM

; محدد Google Workspace
google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

; محدد مخصص
selector1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

تكوين DMARC التدريجي

; المرحلة 1: المراقبة
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com"

; المرحلة 2: حجر جزئي
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

; المرحلة 3: الرفض الكامل
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

شجرة القرار لاختيار نوع السجل

أحتاج إلى توجيه نطاقي إلى...
│
├─ عنوان IP؟
│  ├─ IPv4 ← سجل A
│  └─ IPv6 ← سجل AAAA
│
├─ اسم نطاق آخر؟
│  ├─ هل هو النطاق الجذري (apex)؟ ← استخدم A/AAAA (أو ALIAS إن توفر)
│  └─ هل هو نطاق فرعي؟ ← سجل CNAME
│
├─ خادم بريد إلكتروني؟
│  └─ سجل MX (+ SPF/DKIM/DMARC عبر TXT)
│
├─ تحقق أو سياسة نصية؟
│  └─ سجل TXT
│
├─ خدمة بمنفذ محدد؟
│  └─ سجل SRV
│
├─ التحكم في جهات إصدار الشهادات؟
│  └─ سجل CAA
│
└─ تعيين عكسي من IP إلى اسم؟
   └─ سجل PTR

مثال كامل لتكوين DNS

السيناريو: النطاق mysite.sa مع موقع خلف CDN، وبريد إلكتروني على Google Workspace، وLet’s Encrypt لشهادات SSL.

; --- سجلات البنية التحتية ---
mysite.sa.          86400  IN  NS   ns1.cloudflare.com.
mysite.sa.          86400  IN  NS   ns2.cloudflare.com.

; --- الموقع ---
mysite.sa.          300    IN  A     104.21.45.67
mysite.sa.          300    IN  AAAA  2606:4700:3030::6815:2d43
www.mysite.sa.      3600   IN  CNAME mysite.sa.

; --- البريد الإلكتروني (Google Workspace) ---
mysite.sa.          3600   IN  MX   1  aspmx.l.google.com.
mysite.sa.          3600   IN  MX   5  alt1.aspmx.l.google.com.
mysite.sa.          3600   IN  MX   5  alt2.aspmx.l.google.com.

; --- مصادقة البريد ---
mysite.sa.          3600   IN  TXT  "v=spf1 include:_spf.google.com -all"
google._domainkey.mysite.sa.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."
_dmarc.mysite.sa.   3600   IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mysite.sa"

; --- الشهادات ---
mysite.sa.          3600   IN  CAA  0  issue     "letsencrypt.org"
mysite.sa.          3600   IN  CAA  0  issuewild "letsencrypt.org"
mysite.sa.          3600   IN  CAA  0  iodef     "mailto:security@mysite.sa"

أدوات التشخيص واستكشاف الأخطاء

سطر الأوامر

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

# استعلام MX مع التفاصيل
dig example.com MX +noall +answer

# استعلام سجل TXT (SPF)
dig example.com TXT +short

# استعلام CAA
dig example.com CAA +short

# التحقق من الانتشار عبر خادم محدد
dig @8.8.8.8 example.com A

# تتبع كامل لعملية الاستبيان
dig example.com +trace

# DNS العكسي
dig -x 203.0.113.10

# التحقق من DNSSEC
dig example.com +dnssec +short

الأدوات المتاحة عبر الإنترنت

قبل تكوين أي سجلات DNS، من الضروري التأكد من توفر النطاق المطلوب. استخدم أداة التحقق من النطاقات في Nameslink للاستعلام الفوري عن التوفر، أو انتقل إلى Nameslink Quick Buy لتسجيل النطاقات بسرعة.

أفضل ممارسات TTL

نصيحة عملية: عند التخطيط لعملية ترحيل، قلّل TTL قبل 48 ساعة على الأقل من التغيير. بهذه الطريقة، عند تعديل السجلات، سيكون الانتشار أسرع والتراجع ممكنًا.

الأسئلة الشائعة

1. هل يمكنني استخدام CNAME على النطاق الجذري (apex)؟

لا. يحظر RFC 1034 تعايش CNAME مع سجلات أخرى على نفس الاسم، والنطاق الجذري يحتوي دائمًا على SOA وNS. يقدم بعض المزودين أنواعًا مملوكة (ALIAS، ANAME) كبديل، لكنها ليست معيارًا في DNS.

2. كم عدد سجلات MX التي أحتاج إلى تكوينها؟

اثنان على الأقل بأولويات مختلفة للتكرار. يوفر معظم مزودي البريد الإلكتروني (Google وMicrosoft) من 2 إلى 5 خوادم MX بأولويات متنوعة.

3. ماذا يحدث إذا تجاوز SPF الخاص بي 10 عمليات بحث؟

ستكون النتيجة permerror، وقد تعامل الخوادم المستقبلة رسائلك كما لو لم يكن هناك SPF مكوَّن. استخدم آليات ip4: وip6: (التي لا تُحتسب كعمليات بحث) أو خدمات تسطيح SPF (SPF flattening).

4. هل أحتاج إلى سجل CAA إذا كنت أستخدم HTTPS بالفعل؟

نعم. سجل CAA هو طبقة وقائية تمنع سلطات الشهادات غير المصرح بها من إصدار شهادات لنطاقك. مع سياسة 47 يومًا الجديدة من CA/B Forum، تجعل أتمتة الشهادات سجل CAA أكثر أهمية لضمان أن سلطات الشهادات الموثوقة فقط هي التي تُصدر التجديدات.

5. كيف أتحقق من توفر نطاقي قبل تكوين DNS؟

استخدم أداة تقييم النطاقات في Nameslink للتحقق ليس فقط من التوفر بل أيضًا من القيمة التقديرية للنطاق. للتسجيل الفوري، انتقل إلى Nameslink Quick Buy.

المراجع

1. RFC 1035 — Domain Names: Implementation and Specification
2. RFC 7208 — Sender Policy Framework (SPF)
3. RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
4. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
5. RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record
6. CA/Browser Forum Ballot SC-081v3 — Reducing TLS Certificate Lifetimes (أبريل 2025)
7. Google — Email Sender Guidelines (2024)
8. Yahoo — Sender Best Practices (2024)
9. IANA — DNS Parameters Registry
10. Cloudflare Learning Center — DNS Record Types