سجلات DNS للمطورين — A، CNAME، MX، TXT، والـ TTL الذي جعلك تنتظر 48 ساعة

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

هذا ليس دورة تعليمية لمن لم يسمع أبدًا عن DNS. إنه مرجع للمطورين الذين يعرفون ما هو النطاق ولكنهم يبحثون دائمًا عن Stack Overflow كلما أرادوا إضافة نوع سجل لم يتعاملوا معه منذ ستة أشهر.

كيف يعمل DNS فعليًا (النسخة لمدة 30 ثانية)

عندما يحل المتصفح example.com، يسأل مُحللًا متسلسلًا (عادةً مزود الخدمة أو 8.8.8.8). يتحقق المُحلل من مخزونه. إذا كان هناك تطابق في المخزون، فإنه يُرجع الإجابة المخزونة. وإذا لم يكن هناك تطابق، فإنه يتحرك إلى أعلى شجرة DNS — مُنافذ الجذور → مُنافذ الـ TLD (.com) → مُنافذ النطاق المُحَدّد لمنطقتكم — ويُخزن النتيجة لفترة تُحدد من خلال TTL.

كل سجل DNS يحتوي على نوع، واسم، وقيمة، وTTL. هذا كل شيء. ينشأ التعقيد من معرفة أي نوع يُستخدم لفعل ما، ومكان تفاعل السجلات بطريقة غير واضحة.

الأنواع التي ستحتاجها في الواقع

سجل A — عنوان IP للعنوان المُعرف

يُربط اسم المُعرف إلى عنوان IP من النوع IPv4. هذا هو السجل الأكثر شيوعًا الذي ستحتاجه.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

الإشكالية: يمكنك أن تمتلك أكثر من سجل A لاسم مُعرف واحد. سيُرجع DNS جميعها، وستختار العميل واحدًا (عادةً بطريقة توزيع عشوائي). هذا هو تكوين بسيط للتنقيط — لكن إذا توقف أحد هذه العناوين، فإن DNS لا يمتلك تحققًا لصحة العناوين. سيستمر في تقديم العنوان المُعطل حتى ينتهي TTL ويُزال.

لـ IPv6، المُعادل هو سجل AAAA. نفس المفهوم، عنوان بطول 128 بت بدلًا من 32 بت.

سجل CNAME — مُعرف بديل لعنوان آخر

يُشير إلى عنوان مُعرف واحد إلى عنوان مُعرف آخر (بدلاً من عنوان IP). يُتبع السلسلة حتى يصل إلى سجل A.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

مقارنة بين CNAME و A — متى تستخدم كل منهما: إذا كنت تشير إلى خدمة تُعطيك عنوانًا مُعرفًا (مثل Netlify، Vercel، GitHub Pages، Heroku، معظم المزودين للـ CDN)، فاستخدم CNAME. إذا كان لديك عنوان IP ثابت، فاستخدم سجل A. بسيط.

القاعدة الصعبة: لا يمكنك وضع سجل CNAME على رأس النطاق (النطاق النقي — example.comالقيم المنطقية تبقى كنصوص. www.example.com). يحظر RFC 1034 ذلك لأن الرأس يجب أن يحتوي على سجلات SOA وNS، ووجود سجل CNAME بنفس الاسم سيؤدي إلى تعارض. عندما يخبرك Netlify أو Vercel أن تضيف سجل CNAME للنطاق الرئيسي، فإن ما يقصده هو استخدام مزود DNS يدعم سجلات ANAME أو ALIAS — وهو توسعة خاصة تُصرف مثل CNAME لكنها تُحل إلى سجلات A على مستوى النطاق.

كما أن: لا تُستخدم CNAME إلى CNAME إذا كان ممكنًا. من الناحية التقنية مسموح به، لكن كل خطوة في السلسلة هي مُستكشف إضافي. أهم شيء، إذا توقف السجل المُتوسط، فإن السجل ينهار أيضًا.

سجل MX — توجيه البريد

يُخبر الخوادم الأخرى أين يتم توصيل البريد للنطاق. يحتوي سجل MX على رقم أولوية — الرقم الأقل يعني الأولوية الأعلى.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

إذا لم يكن mail1 متاحًا، فإن الخوادم المُرسلة ستجرب mail2. هذا هو تبديل مناسب، وليس توازنًا للحمل — لا تُقسم التدفق، بل تُحدد ترتيبًا للإحاطة.

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

إذا كنت تُعدّ تثبيت Google Workspace أو Microsoft 365، فسيُعطى لك مجموعة من السجلات MX. لا تُغيّر الأرقام الأولية بحجة أنك مُبادر — لأن منطق توجيه البريد يعتمد على أن تكون هذه الأرقام دقيقة.

سجل TXT — نص عشوائي، غالبًا للاختبار والتحقق من البريد

يحتوي السجلات TXT على نصوص مُرنة. في الممارسة، يُستخدم لثلاثة أشياء:

• التحقق من النطاق — سيرفرات مثل Google Search Console، Stripe، GitHub، وعشرات الخدمات الأخرى ستحتاج إلى إضافة سجل TXT لتأكيد أنك مالك النطاق
• SPF (إطار سياسة المرسل) — يحدد أي خوادم البريد مسموح لها بإرسال بريد باسم النطاق
• DKIM و DMARC — سجلات تحقق البريد التي تمنع التزوير

يبدو سجل SPF على النحو التالي:

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

هذا يعني: يُسمح لـ Google وSendGrid بإرسال بريد باسم هذا النطاق؛ أي شيء آخر يجب أن يُعامل بحذر (~all = فشل مرن، -all = فشل صارم).

يوجد سجل DMARC على _dmarc.example.com:

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

الشيء المهم: يمكنك أن تمتلك سجل TXT واحد لـ SPF لكل نطاق. إذا أضفت سجلًا ثانٍ (لأن خدمة جديدة طلبت ذلك)، فسيكون هناك سجلان معاً، وسيرى الخوادم البريدية سياسات متضاربة، وسينهار التحقق من البريد. ادمجها بدلًا من ذلك: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

سجل NS — توزيع مُنافذ الاسم

يحدد المُنافذ التي تُعتبر مُحَدّدة للنطاق. عادةً ما تُضبط هذه السجلات عند مزود النطاق، وليس مباشرة في منطقتك DNS. عندما تنتقل من مزود DNS إلى آخر (مثلاً من مزود GoDaddy إلى Cloudflare)، فإنك تُغيّر سجلات NS على مستوى المزود.

تنتشر سجلات NS هي السبب في بطء انتقال النطاق. غالبًا ما تكون أوقات تجديد السجلات (TTL) بين 24 إلى 48 ساعة، وتعمل تغييرات المزود على مستوى المُسجلات مع تأخير إضافي.

TTL — الرقم الذي جعلك تنتظر 48 ساعة

TTL (مدة البقاء) هو رقم بالثواني. يخبر المُحللين المُخزّنين كم يُمكنهم الاحتفاظ بالإجابة قبل أن يطلبوا مجددًا. رقم TTL 300 يعني خمسة دقائق. رقم TTL 172800 يعني 48 ساعة.

عندما تُغيّر سجل DNS، يُحتفظ بالجواب القديم مُخزّنًا في كل مكان حتى ينتهي TTL القديم. إذا كان سجل A لديك يحتوي على TTL لمدة 48 ساعة، وقمت بتغيير عنوان IP، فسيُصل بعض المستخدمين إلى الخادم القديم لمدة تصل إلى يومين — ولا يمكنك فعل شيء لحل ذلك بعد أن يتم التغيير.

الحل هو تقليل TTL قبل أن تُغيّر السجل. الممارسة القياسية عند التحويل المخطط:

1. تقليل TTL إلى 300 (5 دقائق) على الأقل 48 ساعة قبل التحويل — يجب أن تنتظر حتى ينتهي TTL القديم
2. أعد التغيير في السجلات
3. انتظر 5 إلى 10 دقائق حتى تنتشر التغييرات
4. أرفع TTL مرة أخرى إلى قيمة منطقية (3600 إلى 86400) بعد التأكد من أن التكوين الجديد يعمل

إذا نسيت الخطوة 1 وانتقلت مباشرة إلى الخطوة 2 مع TTL مرتفع، فستبقى مُثقلًا. يمكنك تقليل TTL الآن، لكن ذلك يقلل فقط من الانتظار لمن لم يخزّن السجل بعد. أي شيء أخزن السجل يجب أن ينتظر حتى ينتهي TTL الأصلي.

مراجع سريع

السجل	يُشير إلى	الاستخدام الشائع	الإشكالية
أ	عنوان IP من النوع IPv4	العنوان المُعرف إلى عنوان الخادم	لا توجد تحقق لصحة الخادم — تبقى العناوين المُعطلة في الدوران حتى ينتهي TTL
MX	عنوان IP من النوع IPv6	العنوان المُعرف إلى عنوان الخادم من النوع IPv6	سهل نسيان إضافة السجل مع سجل A لدعم التوازي بين IPv4 وIPv6
SOA	عنوان مُعرف آخر	مُعرفات، توجيهات للـ CDN أو الخدمات المُتاحة	لا يمكن استخدامه على رأس النطاق؛ لا يمكن أن يُوجه MX أو NS إلى سجل CNAME
NS	عنوان مُعرف (سجل A)	توجيه توصيل البريد	يجب أن يكون القيمة اسمًا مُعرفًا، وليس عنوان IP؛ الأرقام الأولية مهمة
CNAME	نص مُرنة	SPF، DKIM، DMARC، التحقق من النطاق	يمكنك أن تمتلك سجل SPF واحد فقط لكل نطاق — ادمج، لا أضف
TXT	اسم مُنافذ الخادم	توزيع الاسم	تُغيّر التغييرات على مستوى المُسجل، وتنتشر ببطء
CAA	نطاق المُصدر	الشركات المُسموح لها بإصدار شهادات SSL للنطاق	سهل أن تُغلق نفسك من تجديد الشهادة بسبب تكوين خاطئ

الأشياء التي ستساعدك في توفير الوقت

استخدم dig بشكل مباشر، وليس من أداة على الويب. dig @8.8.8.8 example.com A يُتجاوز مُحللك المحلي ويعرض ما يراه Google DNS. أضف +short لإظهار الجواب فقط. أضف +trace لإظهار السلسلة الكاملة للحل.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

تحقق من TTL قبل أي تغيير. قبل إضافة أي فهرس. تأكد من وجود المشكلة أولاً. dig example.com A وتحقق من الرقم في العمود الثالث من قسم الإجابة. هذا هو المدة (بالثواني) التي قد تنتظرها إذا قمت بتغيير السجل الآن دون تقليل TTL أولاً.

سجلات Cloudflare المُحاطة لا تُظهر عنوانك الحقيقي. عند تفعيل سحابة Cloudflare على سجل، فإن السجل A المُعرض للعالم هو عنوان Cloudflare، وليس عنوانك. هذا هو ما تريده عادةً للحماية من الهجمات، لكنه يعني أن dig لن يُظهر عنوان الخادم الحقيقي، وستكون الأدوات التي تُستكشف عنوانك مباشرة لا تعمل كما يجب.

قد يعجبك أيضاً