ما هو DNS؟ دليل مالك الخادم لإيصال نطاقك إلى VPS

ما هو DNS، ولماذا لا يصل نطاقك إلى VPS لديك بعد؟

يحوّل DNS (نظام أسماء النطاقات) اسماً مثل example.com إلى عنوان IP (بروتوكول الإنترنت) مثل 203.0.113.10. لا يستطيع المتصفح الاتصال باسم. بل يتصل بعنوان، ولذلك يبدأ تحميل كل صفحة بسؤال إلى DNS وإجابة عنه. إذا اشتريت نطاقاً للتو وVPS خاصاً بك، ولم يُحمّل شيء، فهناك احتمالان: لا يوجد سجل يربط الاسم بعنوان خادمك بعد، أو يوجد هذا السجل، لكن شيئاً ما في المسار لا يزال يوزّع إجابة قديمة.

كلتا الحالتين طبيعيتان، ولا تعني أي منهما أن هناك عطلاً. تتناول الأقسام أدناه المكوّنات بالترتيب الذي ستواجهها به، بدءاً من الأمر الأكثر تسبباً في إضاعة الوقت: أي لوحة تحكم تحتوي سجلاتك فعلياً.

تستخدم كل عملية تحقق هنا dig، وهو غير مثبت افتراضياً على جهاز Ubuntu أو Debian جديد.

sudo apt update && sudo apt install -y bind9-dnsutils

المسجّل وخوادم الأسماء ومضيف DNS: أيّها تعدّل؟

تصف هذه الأسماء الثلاثة مهام مختلفة. والخلط بينها هو السبب الأكثر شيوعاً لعدم تغيّر أي شيء بعد التعديل.

• المسجّل هو الشركة التي اشتريت النطاق منها. وتتمثل مهمته الأساسية في التفويض: فهو يخبر السجل الذي يدير نطاق المستوى الأعلى TLD، أي الجزء .com، بخوادم الأسماء المعتمدة لنطاقك.
• خوادم الأسماء المعتمدة تحتفظ بالسجلات الفعلية لمنطقتك. والمنطقة هي نطاقك والأسماء الموجودة تحته.
• مضيف DNS هو الجهة التي تشغّل خوادم الأسماء هذه. وقد يكون المسجّل نفسه، أو مزوّداً منفصلاً، أو bind9 يعمل على خادم تملكه.

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

اعرف الجهة التي يستعلم منها العالم:

dig example.com NS +short
dig +trace example.com

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

كيف ينتقل استعلام واحد

تشارك أربعة أطراف في العملية، ويحتفظ كل طرف بنسخة مما يتعلّمه.

1. المحلّل البدائي على جهازك. لا يجري أي بحث. يطلب الإجابة من خادم واحد مكوّن مسبقاً ويعتمد عليها. في Ubuntu، يكون /etc/resolv.conf عادةً رابطاً رمزياً إلى /run/systemd/resolve/stub-resolv.conf، ويشير إلى 127.0.0.53، وهو systemd-resolved يعمل محلياً مع ذاكرة تخزين مؤقت خاصة به.
2. المحلّل التكراري. هو المحلّل الذي يشغّله مزود خدمة الإنترنت لديك، أو محلّل عام مثل 1.1.1.1، أو محلّل تشغّله بنفسك. ينفّذ العمل الفعلي للعثور على الإجابة.
3. خوادم الجذر وTLD. يطلب المحلّل التكراري الإجابة من خادم جذر. لا يعرف خادم الجذر عنوانك، لكنه يرد بإحالة إلى خوادم .com. وترد هذه الخوادم بإحالة إلى خوادم الأسماء الخاصة بنطاقك.
4. خادم الأسماء المعتمد. لا يطلب الإجابة من أي جهة. يجيب من منطقة نطاقك ويضع علامة تفيد بأن الإجابة معتمدة.

يعرض لك dig +trace example.com هذه العملية، لأنه يبدأ من الجذر نفسه ويطبع كل إحالة بدلاً من طلب الإجابة من ذاكرة تخزين مؤقت. وهذه أسرع طريقة للتحقق من توافق التفويض مع المنطقة.

سجلات DNS المهمة عند تشغيل خادم

• A: يربط اسماً بعنوان IPv4. example.com. A 203.0.113.10. هذا هو السجل الذي يوجّه نطاقك إلى VPS الخاص بك.
• AAAA: يربط اسماً بعنوان IPv6، مثل 2001:db8::10. انشره فقط عندما تستمع خدمتك فعلاً على ذلك العنوان. يجرّب العملاء على شبكات IPv6 إجابة AAAA أولاً، لذلك يؤدي عنوان لا تستجيب عليه أي خدمة إلى تأخير كل زيارة.
• CNAME: اسم مستعار من اسم إلى اسم آخر. يوجّه www.example.com. CNAME example.com. زوار www إلى الوجهة التي يحل إليها النطاق الأساسي. لا يمكن وضع CNAME عند apex (أي example.com الأساسي)، لأن apex يجب أن يحتوي على سجلات SOA (بدء الصلاحية) وNS الخاصة به، ولا يُسمح لـCNAME بمشاركة الاسم مع أي سجل آخر. يوفّر مقدمو الخدمة حلولاً بديلة بأسماء مثل ALIAS وANAME وCNAME flattening.
• MX: يحدد مكان تسليم البريد الوارد للنطاق. يحتوي على اسم مضيف ورقم أولوية، ويُجرَّب الرقم الأقل أولاً. يجب أن يشير MX إلى اسم يملك سجل عنوان. ويُعد توجيهه إلى CNAME غير صالح، وقد ترفضه بعض خوادم الإرسال.
• TXT: نص حر يُستخدم للإثبات والسياسات. توجد هنا سجلات مصادقة البريد (SPF وDKIM وDMARC)، وكذلك رمز ACME (بيئة إدارة الشهادات تلقائياً) الذي يُصدر شهادة wildcard.
• NS: يحدد خوادم الأسماء التي تخدم المنطقة. توجد النسخة التي تحدد المكان الذي يستعلم منه العالم في المنطقة الأب، وتأتي من تفويض المسجّل للنطاق، لا من النسخة الموجودة داخل منطقتك نفسها.

يسبب تفصيلان التباساً أكبر من أنواع السجلات نفسها. الاسم الذي ينتهي بنقطة يكون مطلقاً، لذلك يعني www.example.com. ذلك الاسم تحديداً ولا شيء أكثر. تتوقع معظم لوحات التحكم اسماً نسبياً وتضيف النطاق نيابةً عنك، لذلك يؤدي إدخال www.example.com في حقل الاسم إلى إنشاء www.example.com.example.com، وهو اسم لا يحل إليه أحد. أما التفصيل الآخر فهو @، الذي يعني apex في معظم لوحات التحكم تقريباً: النطاق بحد ذاته، من دون نطاق فرعي.

وجّه سجل A إلى VPS الخاص بك

احصل أولاً على العنوان الذي يراه الإنترنت لخادمك:

curl -4 https://ifconfig.me
ip -brief -4 address show

أنشئ بعد ذلك سجلاً واحداً لدى مستضيف DNS الخاص بك: النوع A، والاسم @، والقيمة هي ذلك العنوان، وTTL (مدة البقاء) يساوي 300. أضف سجلاً ثانياً لـ www، إما كسجل A آخر بالقيمة نفسها، أو كسجل CNAME يشير إلى النطاق الأساسي.

تحقق الآن من أن الاسم يُحلّ، ويفضل أن تنفذ ذلك من حاسوبك المحمول لا من الخادم نفسه:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

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

لا يتم تحميل حل الاسم

يثبت حل الاسم أن DNS يعمل. لكنه لا يثبت شيئاً عن خادم الويب لديك. بعد أن يعيد dig العنوان الصحيح، اختبر الاتصال:

curl -I http://example.com

يمثل curl: (6) Could not resolve host: example.com مشكلة في DNS. أما curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused فليس مشكلة في DNS: فقد حُلَّ الاسم ووصلت الحزمة، ولذلك تكمن المشكلة في عدم وجود أي خدمة تستمع على ذلك المنفذ. يعني تعليق الطلب ثم انتهاء مهلة الانتظار عادةً أن جداراً نارياً أسقط الحزمة بصمت بدلاً من رفضها. عند هذه النقطة ينتهي دور DNS، وتتولى المنافذ ومقابس الاستماع وقواعد جدار ufw الناري على VPS لديك المتابعة. بعد اكتمال الاتصال، يتولى HTTP تنفيذ عملية تحميل الصفحة.

لماذا لا يزال المتصفح يعرض المضيف القديم

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

توجد النسخ في أماكن أكثر مما يتوقع الناس: ذاكرة التخزين المؤقت القصيرة الخاصة بالمتصفح، وstub resolver على الجهاز، وrecursive resolver الذي تستخدمه تلك الشبكة، وأي resolver ثبّته VPN على جهاز العميل. يحتفظ كل منها بنسخته لمدة تصل إلى TTL الذي تلقّاه. قد يرى شخصان على شبكتين مختلفتين إجابتين مختلفتين لساعات، ويكون كلا الجهازين يعمل بصورة صحيحة.

راقب العدّ التنازلي مقابل caching resolver:

dig @1.1.1.1 example.com +noall +answer

شغّل الأمر مرتين بفاصل بضع ثوانٍ. ينخفض TTL في الإجابة. عندما يصل إلى الصفر، يتخلص resolver من السجل ويسأل خادم الأسماء لديك مرة أخرى.

توجد ذاكرة تخزين مؤقت ثانية لا ينتبه إليها معظم الناس: الإجابات السلبية. عندما يُبلَّغ resolver بأن اسماً غير موجود، فإنه يخزّن أيضاً إجابة NXDOMAIN هذه للمدة التي يحددها الحقل الأخير من سجل SOA الخاص بالمنطقة.

dig example.com SOA +short

الرقم الأخير في ذلك السطر هو TTL السلبي، وغالباً ما يكون 3600. لذلك، فإن البحث عن staging.example.com قبل إنشائه قد يحجب السجل عنك لمدة ساعة كاملة بعد إنشائه. أنشئ السجل أولاً، ثم استعلم عنه.

تغيير خوادم الأسماء أبطأ من تغيير سجل، والسبب مرتبط بآلية العمل. تُخدَم سجلات التفويض في منطقة .com باستخدام TTL قدره 172800 ثانية، أي يومان، لذلك يمكن لـresolver الذي خزّن خوادم الأسماء القديمة أن يواصل سؤالها طوال هذه المدة. من هنا جاءت النصيحة «اسمح بمدة تصل إلى 48 ساعة». تنطبق هذه المدة على تغييرات خوادم الأسماء، لا على تعديلات السجلات العادية.

خطط للترحيل وفق TTL بدلاً من محاولة تجاوزه:

1. اخفض TTL للسجل إلى 300 واحفظه.
2. انتظر مدة أطول من TTL القديم، حتى تنتهي صلاحية كل نسخة مخزّنة تحمل القيمة القديمة.
3. غيّر العنوان.
4. بعد انتقال حركة المرور، ارفع TTL مجدداً إلى 3600 أو أكثر، لأن انخفاض TTL يعني أن كل resolver سيسأل خوادم الأسماء لديك بمعدل أعلى بكثير.

لمسح ما يحتفظ به جهازك نفسه:

resolvectl flush-caches
resolvectl statistics

يطبع resolvectl statistics قسماً لذاكرة التخزين المؤقت يتضمن عدّادات hit وmiss، لذلك يظهر البحث التالي مباشرة بعد المسح على أنه miss. يحتفظ المتصفح بذاكرة تخزين مؤقت منفصلة، ما يعني أن Chrome قد يواصل استخدام إجابة قديمة بعد إفراغ ذاكرة التخزين المؤقت للنظام. امسح تلك الذاكرة في chrome://net-internals/#dns. افحص /etc/hosts أيضاً، لأن سطراً متبقياً هناك يتغلب على DNS في ذلك الجهاز، وفي ذلك الجهاز وحده. يعرض getent hosts example.com الإجابة التي سيستخدمها النظام فعلياً، بما في ذلك /etc/hosts.

تُثبَت شهادات wildcard باستخدام سجل TXT

تتحقق CA (جهة إصدار الشهادات) من التحكم في الاسم قبل إصدار الشهادة. يعرض تحدي HTTP-01 ملفاً عبر المنفذ 80 على اسم المضيف المحدد، وهذا مناسب لاسم واحد. تغطي شهادة wildcard النمط *.example.com، وهو مجموعة غير محدودة من أسماء المضيفين التي لا تستطيع CA جلب ملف منها، لذلك تصدر Let's Encrypt شهادات wildcard فقط عبر تحدي DNS-01. تنشر سجل TXT في _acme-challenge.example.com يحتوي على رمز تمنحك إياه CA، ويكون التحكم في المنطقة هو الدليل.

وهذا يجعل مضيف DNS جزءاً من تجديد الشهادة. يجب أن ينشئ Certbot سجل TXT هذا ويحذفه تلقائياً عند كل تجديد، لذلك يحتاج إلى API وplugin متوافق مع مزود الخدمة لديك. عند فشل التحقق، تكون الرسالة المعتادة هي DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com، وهذا يعني أن CA أجرت التحقق قبل أن يصبح السجل مرئياً: إما أنه لم يُحفَظ مطلقاً، أو أن استجابة سلبية كانت لا تزال مخزنة مؤقتاً. يرد الإجراء الكامل في الدليل الخاص بشهادات wildcard باستخدام تحدي DNS-01.

عندما يستولي VPN على محلّل الأسماء

يستبدل عميل VPN (الشبكة الخاصة الافتراضية) عادةً محلّل الأسماء في النظام أثناء اتصاله، لأن إرسال استعلامات الأسماء إلى الشبكة المحلية سيكشف لتلك الشبكة اسم كل موقع تزوره. هذا سلوك صحيح، لكنه قد يفشل بطريقتين.

إذا أصبح النفق متاحاً وتوقفت الأسماء عن الحل بينما بقيت العناوين تعمل، فهذا يعني أن محلّل الأسماء الذي ثبّته العميل لا يمكن الوصول إليه من داخل النفق. ينجح ping 1.1.1.1، ويُرجع curl https://example.com القيمة curl: (6) Could not resolve host: example.com. أما إذا أصبح النفق متاحاً واستمرت الاستعلامات في الذهاب إلى الشبكة التي تتصل بها، فستمر حركة الشبكة عبر النفق، بينما يواصل محلّل الأسماء المحلي رؤية كل اسم تطلبه.

resolvectl status

يعرض ذلك محلّل الأسماء المستخدم لكل وصلة، حتى تتمكن من معرفة المحلّل الذي ثبّته النفق وما إذا كان هو المحلّل المقصود. يضبط نفق WireGuard هذا المحلّل من سطر DNS = في إعداد العميل، ويشرح إصلاح DNS عندما يستولي WireGuard على محلّل الأسماء حالتي systemd-resolved وresolvconf بالتفصيل.

رموز الاستجابة، وما يخبرك به كل رمز

• NXDOMAIN: يفيد الخادم الموثوق بأن الاسم غير موجود. تحقق من التهجئة، وتحقق من عدم تكرار لاحقة النطاق، وتحقق من أنك عدّلت المنطقة التي تشير إليها عملية التفويض.
• NOERROR مع ANSWER SECTION فارغ: الاسم موجود، لكنه لا يحتوي على سجّل من النوع الذي طلبته. يؤدي طلب AAAA عندما لا يكون موجوداً سوى A إلى هذه النتيجة تحديداً.
• SERVFAIL: حاول محلّل الأسماء إنشاء إجابة، لكنه لم يتمكن من ذلك. السببان المعتادان هما خوادم موثوقة لا تستجيب مطلقاً، وفشل التحقق من DNSSEC (امتدادات أمان نظام أسماء النطاقات). اختبر باستخدام dig @1.1.1.1 example.com A +cd، الذي يعطّل التحقق. إذا ظهرت إجابة تتضمن +cd وSERVFAIL عند تعطيله، فهذا يعني أن التواقيع هي المشكلة. يحدث ذلك بعد نقل خادم أسماء مع استمرار النطاق الأب في نشر سجل DS (موقّع التفويض) القديم.
• REFUSED: لن يجيب الخادم الذي سألته عن هذا السؤال، ويحدث ذلك عادةً لأنك وجّهت dig إلى خادم موثوق لنطاق لا يخدمه.
• ;; connection timed out; no servers could be reached: لم يصل dig إلى أي محلّل أسماء. هذه مشكلة في الشبكة أو في محلّل الأسماء لديك، ولذلك لا يكون النطاق هو موضع المشكلة.

ping: example.com: Temporary failure in name resolution هي الفئة نفسها من الفشل، لكن glibc يبلغ عنها بدلاً من dig.

هل ينبغي تشغيل خوادم أسماء على VPS الخاص بك؟

يمكنك ذلك. سيتولى bind9 أو knot أو nsd خدمة نطاقك من الخادم، كما سيمنحك ذلك فهماً أعمق لـDNS مما توفره أي لوحة تحكم. لكن الاعتراضات عملية. ينبغي أن يكون للنطاق خادما أسماء على الأقل، على شبكتين منفصلتين، لذلك يصبح VPS واحد نقطة فشل لكل خدمة على النطاق، بما في ذلك البريد. تحتاج خوادم الأسماء التي تحمل أسماءً ضمن النطاق الذي تخدمه إلى سجلات glue لدى المسجّل. سجل glue هو عنوان ns1.example.com المخزّن في النطاق الأب، لأن عملية البحث لا تملك طريقة أخرى للبدء. عندما يتعذر على محلّل DNS الوصول إلى خادم الأسماء، فلن ينتقل تلقائياً إلى موقعك الإلكتروني؛ بل يختفي النطاق بالكامل بالنسبة إلى ذلك المستخدم. بالنسبة إلى معظم الأشخاص، يكون DNS المستضاف مع API هو الخيار الأقل خطراً. أما تشغيل محلّل تخزين مؤقت على VPS لأجهزتك الخاصة فهو مهمة مختلفة، والتزام أصغر بكثير.

FAQ

لماذا لم ينتشر تغيير DNS حتى الآن؟

لا يحدث أي «انتشار» بالمعنى الحرفي. تحتفظ خوادم الأسماء الموثوقة بالقيمة الجديدة بمجرد حفظها، ويحتفظ كل محلل أسماء سبق أن طلبها بنسخته المخزنة مؤقتاً إلى أن تنتهي مدة TTL التي تلقاها. استعلم من الخادم الموثوق مباشرةً باستخدام dig @ns1.your-dns-host.net example.com A +short. إذا أعاد العنوان الجديد، فالتغيير نافذ، وما تبقى هو التخزين المؤقت. إذا غيّرت خوادم الأسماء بدلاً من السجلات، فتوقّع مدة أطول بكثير، لأن تفويضات TLD تُوزّع مع TTL مدته يومان.

كيف أعرف خوادم الأسماء التي يستخدمها نطاقي فعلياً؟

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

نطاقي يُحلّ إلى عنوان، لكن الموقع لا يُحمّل. ماذا أفعل الآن؟

ينتهي دور DNS فور إعادة dig example.com A +short عنوان خادمك. بعد ذلك، تكون المشكلة في الاتصال. إذا أعاد curl -I http://example.com القيمة Connection refused، فهذا يعني عدم وجود أي خدمة تستمع على ذلك المنفذ. إذا ظل الطلب معلّقاً إلى أن تنتهي مهلته، فهذا يعني أن جداراً نارياً أسقط الحزمة. تحقق من أن خادم الويب قيد التشغيل ويستمع على العنوان العام، ثم افحص الجدار الناري على الخادم والجدار الناري المنفصل للشبكة في لوحة تحكم المزوّد.

لماذا لا يمكنني وضع CNAME على نطاق الجذر؟

يشير CNAME إلى أن اسماً ما هو اسم مستعار لاسم آخر، ولا يُسمح للاسم الذي يملك CNAME بحمل أي سجل آخر. يجب أن يحمل نطاق الجذر سجلي SOA وNS لكي يوجد كمنطقة، لذلك لا يمكن أن يكون CNAME أيضاً. استخدم سجل A يحتوي على العنوان في الجذر، أو استخدم ميزة المزوّد التي تُباع باسم ALIAS أو ANAME أو CNAME flattening، إذ تخزّن اسماً وتجيب عن الاستعلامات بالعنوان الذي يُحلّ إليه ذلك الاسم حالياً.