Scroll to navigation

RESOLVED.CONF(5) resolved.conf RESOLVED.CONF(5)

الاسم

resolved.conf, resolved.conf.d - ملفات تهيئة تحليل أسماء الشبكة

موجز

/etc/systemd/resolved.conf
/run/systemd/resolved.conf
/usr/local/lib/systemd/resolved.conf
/usr/lib/systemd/resolved.conf
/etc/systemd/resolved.conf.d/*.conf
/run/systemd/resolved.conf.d/*.conf
/usr/local/lib/systemd/resolved.conf.d/*.conf
/usr/lib/systemd/resolved.conf.d/*.conf

الوصف

تتحكم ملفات التهيئة هذه في تحليل أسماء DNS المحلية و LLMNR.

أدلة الضبط والأسبقية

يُضبط التشكيل المبدئي أثناء التجميع، لذا لا يلزم التشكيل إلا عند الحاجة للانحراف عن تلك القيم المبدئية. يُحمل ملف التشكيل الرئيس من أحد الأدلة المدرجة حسب ترتيب الأولوية، ويُستخدم أول ملف يُعثر عليه فقط: /etc/systemd/، و /run/systemd/، و /usr/local/lib/systemd/ [1]، و /usr/lib/systemd/. تحتوي نسخة المورد من الملف على مدخلات مُعلقة تظهر القيم المبدئية كدليل للمدير. يمكن أيضًا إنشاء تجاوزات محلية عن طريق إنشاء ملفات تكميلية (drop-ins)، كما هو موضح أدناه. يمكن أيضًا تحرير ملف التشكيل الرئيس لهذا الغرض (أو نسخة في /etc/ إذا كانت مشحونة تحت /usr/)، ومع ذلك يوصى باستخدام الملفات التكميلية للتشكيل المحلي بدلاً من إجراء تعديلات على ملف التشكيل الرئيس.

بالإضافة إلى ملف الإعداد الرئيس، تُقرأ قصاصات الإعداد الإضافية من /usr/lib/systemd/*.conf.d/ و /usr/local/lib/systemd/*.conf.d/ و /etc/systemd/*.conf.d/. لهذه الإضافات أولوية أعلى وتتجاوز ملف الإعداد الرئيس. تُفرز الملفات في الأدلة الفرعية للإعداد *.conf.d/ حسب أسماء ملفاتها بترتيب معجمي، بغض النظر عن الدليل الفرعي الذي توجد فيه. عندما تحدد ملفات متعددة نفس الخيار، بالنسبة للخيارات التي تقبل قيمة واحدة فقط، فإن المدخلة في الملف الأخير في الترتيب هي التي تسود، وبالنسبة للخيارات التي تقبل قائمة من القيم، تُجمع المدخلات كما تظهر في الملفات المرتبة.

عندما تحتاج الحزم إلى تخصيص الضبط، يمكنها تثبيت ملفات تكميلية (drop-ins) تحت /usr/. تُحجز الملفات في /etc/ لمدير النظام المحلي، الذي قد يستخدم هذا المنطق لتخطي ملفات الضبط المثبتة من قبل حزم المورّد. يجب استخدام الملفات التكميلية لتخطي ملفات الحزم التكميلية، بما أن ملف الضبط الرئيس له أسبقية أدنى. ويُوصى ببدء جميع أسماء الملفات في تلك المجلدات الفرعية برقم من خانتين وواصلة، لتبسيط الترتيب. كما يحدد هذا مفهوم أولويات الملفات التكميلية للسماح لموردي أنظمة التشغيل بشحن ملفات تكميلية ضمن نطاق محدد أدنى من النطاق الذي يستخدمه المستخدمون. وهذا من شأنه أن يقلل من خطر تخطي ملفات الحزم التكميلية للملفات التكميلية التي حددها المستخدمون عرضًا. ويُوصى باستخدام النطاق 10-40 للملفات التكميلية في /usr/ والنطاق 60-90 للملفات التكميلية في /etc/ و /run/، للتأكد من أن الملفات التكميلية المحلية والعابرة تأخذ الأولوية على الملفات التكميلية التي يشحنها مورد نظام التشغيل.

لتعطيل ملف تشكيل مقدم من المورد، فإن الطريقة الموصى بها هي وضع وصلة رمزية إلى /dev/null في دليل التشكيل في /etc/، بنفس اسم ملف تشكيل المورد.

الخيارات

الخيارات التالية متاحة في القسم [Resolve]:

DNS=

قائمة مفصولة بمسافات من عناوين IPv4 و IPv6 لاستخدامها كخوادم DNS للنظام. يمكن لكل عنوان أن يأخذ اختيارياً رقم منفذ مفصولاً بـ ":"، واسم واجهة شبكة أو فهرس مفصولاً بـ "%"، ومؤشر اسم الخادم (SNI) مفصولاً بـ "#". عند تحديد عنوان IPv6 مع رقم منفذ، يجب أن يكون العنوان بين قوسين مربعين. أي أن التنسيقات الكاملة المقبولة هي "111.222.333.444:9953%ifname#example.com" لـ IPv4 و "[1111:2222::3333]:9953%ifname#example.com" لـ IPv6. تُرسل طلبات DNS إلى أحد خوادم DNS المدرجة بالتوازي مع خوادم DNS المناسبة لكل وصلة التي تُحصل من systemd-networkd.service(8) أو تُضبط في وقت التشغيل بواسطة تطبيقات خارجية. لأسباب توافقية، إذا لم يُحدد هذا الإعداد، تُستخدم خوادم DNS المدرجة في /etc/resolv.conf بدلاً من ذلك، إذا كان هذا الملف موجوداً وتم تكوين أي خوادم فيه. هذا الإعداد يكون مبدئياً القائمة الفارغة.

أُضيف في الإصدارة 213.

FallbackDNS=

قائمة مفصولة بمسافات من عناوين IPv4 و IPv6 لاستخدامها كخوادم DNS احتياطية. يُرجى الاطلاع على DNS= للتنسيق المقبول للعناوين. أي خوادم DNS لكل وصلة تُحصل من systemd-networkd.service(8) لها الأولوية على هذا الإعداد، وكذلك أي خوادم مضبوطة عبر DNS= أعلاه أو /etc/resolv.conf. لذلك يُستخدم هذا الإعداد فقط إذا لم تكن هناك معلومات أخرى عن خادم DNS معروفة. إذا لم يُعط هذا الخيار، تُستخدم قائمة مضمنة من خوادم DNS بدلاً من ذلك.

أُضيف في الإصدارة 216.

Domains=

قائمة مفصولة بمسافات من النطاقات، مسبوقة اختيارياً بـ "~"، تُستخدم لغرضين متميزين موصوفين أدناه. تكون مبدئياً القائمة الفارغة.

أي نطاقات غير مسبوقة بـ "~" تُستخدم كلواحق بحث عند تحليل أسماء المضيفين أحادية التسمية (أسماء النطاقات التي لا تحتوي على نقطة)، لتأهيلها إلى أسماء نطاقات مؤهلة بالكامل (FQDNs). تُعالج "نطاقات البحث" هذه بدقة بالترتيب الذي تُحدد به، حتى يُعثر على الاسم مع اللاحقة المضافة. لأسباب توافقية، إذا لم يُحدد هذا الإعداد، تُستخدم نطاقات البحث المدرجة في /etc/resolv.conf مع الكلمة الأساسية search بدلاً من ذلك، إذا كان هذا الملف موجوداً وتم تكوين أي نطاقات فيه.

النطاقات المسبوقة بـ "~" تُسمى "نطاقات توجيه فقط". جميع النطاقات المدرجة هنا (كل من نطاقات البحث ونطاقات التوجيه فقط بعد إزالة البادئة "~") تُحدد مسار بحث يُوجه استعلامات DNS بشكل تفضيلي إلى هذه الواجهة. يكون لمسار البحث هذا تأثير فقط عندما تكون خوادم DNS مناسبة لكل وصلة معروفة. يمكن تعريف هذه الخوادم عبر إعداد DNS= (انظر أعلاه) وديناميكياً في وقت التشغيل، مثلاً من عقود DHCP. إذا لم تكن خوادم DNS لكل وصلة معروفة، فلا تأثير لنطاقات التوجيه فقط.

استخدم البناء "~." (المكون من "~" للإشارة إلى نطاق توجيه فقط و "." للإشارة إلى نطاق جذر DNS الذي هو اللاحقة الضمنية لجميع نطاقات DNS) لاستخدام خوادم DNS المعرفة لهذه الوصلة بشكل تفضيلي لجميع النطاقات.

انظر "البروتوكولات والتوجيه" في systemd-resolved.service(8) للتفاصيل حول كيفية استخدام نطاقات البحث ونطاقات التوجيه فقط.

لاحظ أن تكوين نطاق MulticastDNS "local" كنطاق بحث أو توجيه له تأثير توجيه عمليات البحث لهذا النطاق إلى DNS أحادي الإرسال الكلاسيكي. يمكن استخدام هذا لتوفير توافق مع التثبيتات القديمة التي تستخدم هذا النطاق في سياق DNS أحادي الإرسال، ضد تعيين IANA لهذا النطاق لأغراض MulticastDNS البحتة. نطاقات البحث والتوجيه هي مفهوم DNS أحادي الإرسال، لا يمكن استخدامها لحل عمليات البحث أحادية التسمية عبر MulticastDNS.

أُضيف في الإصدارة 229.

LLMNR=

يأخذ وسيطة منطقية أو "resolve". يتحكم في دعم تحليل أسماء الإرسال المتعدد المحلي للوصلة (RFC 4795[2]) على المضيف المحلي. إذا كان صحيحاً، يُفعّل دعم المستجيب والحلال الكامل لـ LLMNR. إذا كان خطأ، يُعطّل كليهما. إذا ضُبط على "resolve"، يُفعّل دعم الحل فقط، لكن يُعطّل الاستجابة. لاحظ أن systemd-networkd.service(8) يحافظ أيضًا على إعدادات LLMNR لكل وصلة. سيُفعّل LLMNR على وصلة فقط إذا كان الإعداد لكل وصلة والعالمي قيد التشغيل.

أُضيف في الإصدارة 216.

MulticastDNS=

يأخذ وسيطة منطقية أو "resolve". يتحكم في دعم DNS متعدد الإرسال (RFC 6762[3]) على المضيف المحلي. إذا كان صحيحاً، يُفعّل دعم المستجيب والحلال الكامل لـ Multicast DNS. إذا كان خطأ، يُعطّل كليهما. إذا ضُبط على "resolve"، يُفعّل دعم الحل فقط، لكن يُعطّل الاستجابة. لاحظ أن systemd-networkd.service(8) يحافظ أيضًا على إعدادات Multicast DNS لكل وصلة. سيُفعّل Multicast DNS على وصلة فقط إذا كان الإعداد لكل وصلة والعالمي قيد التشغيل.

أُضيف في الإصدارة 234.

DNSSEC=

يأخذ وسيطة منطقية أو "allow-downgrade".

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

إذا ضُبط على "allow-downgrade"، تُحاول عملية التحقق من DNSSEC، لكن إذا لم يدعم الخادم DNSSEC بشكل صحيح، يُعطّل وضع DNSSEC آلياً. لاحظ أن هذا الوضع يجعل التحقق من DNSSEC عرضة لهجمات "الخفض"، حيث قد يتمكن المهاجم من تحفيز خفض إلى وضع غير DNSSEC عن طريق تركيب رد DNS يوحي بأن DNSSEC غير مدعوم.

إذا ضُبط على خطأ، لا تُتحقق عمليات بحث DNS بواسطة DNSSEC.

لاحظ أن التحقق من DNSSEC يتطلب استرجاع بيانات DNS إضافية، وبالتالي يؤدي إلى عقوبة زمنية صغيرة في وقت بحث DNS.

يتطلب DNSSEC معرفة "مراسي الثقة" لإثبات سلامة البيانات. مرساة الثقة لنطاق الجذر للإنترنت مدمجة في المحلل، ويمكن تعريف مراسي ثقة إضافية باستخدام dnssec-trust-anchors.d(5). قد تتغير مراسي الثقة على فترات منتظمة، وقد تُلغى مراسي الثقة القديمة. في هذه الحالة، لا يكون التحقق من DNSSEC ممكنًا حتى يتم تكوين مراسي ثقة جديدة محليًا أو تحديث حزمة برامج المحلل بمرساة الثقة الجذرية الجديدة. في الواقع، عندما تُلغى مرساة الثقة المدمجة وتكون DNSSEC= صحيحة، ستفشل جميع عمليات البحث اللاحقة، لأنه لم يعد من الممكن إثبات ما إذا كانت عمليات البحث موقعة بشكل صحيح أو غير موقعة بشكل صحيح. إذا تم تعيين DNSSEC= على "allow-downgrade"، فسيقوم المحلل آليًا بإيقاف التحقق من DNSSEC في هذه الحالة.

سيتم إعلام برامج العميل التي تبحث عن بيانات DNS ما إذا كان يمكن التحقق من عمليات البحث باستخدام DNSSEC، أو ما إذا كان لا يمكن التحقق من البيانات المعادة (إما لأن البيانات وجدت غير موقعة في DNS، أو أن خادم DNS لم يدعم DNSSEC أو لم تكن مراسي الثقة المناسبة معروفة). في الحالة الأخيرة، يُفترض أن برامج العميل تستخدم مخططًا ثانويًا للتحقق من بيانات DNS المعادة، إذا كان ذلك مطلوبًا.

يُوصى بتعيين DNSSEC= على صحيح في الأنظمة التي يُعرف فيها أن خادم DNS يدعم DNSSEC بشكل صحيح، وحيث تحدث تحديثات البرامج أو مراسي الثقة بانتظام. في الأنظمة الأخرى، يُوصى بتعيين DNSSEC= على "allow-downgrade".

بالإضافة إلى إعداد DNSSEC العام هذا، يحتفظ systemd-networkd.service(8) أيضًا بإعدادات DNSSEC لكل وصلة. بالنسبة لخوادم DNS النظامية (انظر أعلاه)، يكون إعداد DNSSEC العام فقط ساري المفعول. بالنسبة لخوادم DNS لكل وصلة، يكون الإعداد لكل وصلة ساري المفعول، ما لم يكن غير معين، وفي هذه الحالة يُستخدم الإعداد العام بدلاً من ذلك.

تتعارض نطاقات DNS الخاصة بالموقع عمومًا مع تشغيل DNSSEC، ما لم يتم تكوين مرساة ثقة سلبية (إذا كانت النطاق الخاص غير موقع) أو إيجابية (إذا كانت النطاق الخاص موقعًا) لها. إذا تم تحديد وضع "allow-downgrade"، فسيتم محاولة اكتشاف نطاقات DNS الخاصة بالموقع باستخدام نطاقات المستوى الأعلى (TLDs) غير المعروفة لخادم DNS الجذر. لا يعمل هذا المنطق في جميع إعدادات النطاقات الخاصة.

المبدئي هو "no".

أُضيف في الإصدارة 229.

DNSOverTLS=

يأخذ وسيطة منطقية أو "opportunistic". إذا كانت صحيحة، فسيتم تعمية جميع الاتصالات بالخادم. لاحظ أن هذا الوضع يتطلب خادم DNS يدعم DNS-over-TLS ولديه شهادة صالحة. إذا تم تحديد اسم المضيف في DNS= باستخدام التنسيق "address#server_name"، فسيتم استخدامه للتحقق من شهادته وأيضًا لتمكين مؤشر اسم الخادم (SNI) عند فتح اتصال TLS. وإلا، يتم التحقق من الشهادة مقابل عنوان IP الخاص بالخادم. إذا كان خادم DNS لا يدعم DNS-over-TLS، فستفشل جميع طلبات DNS.

عند تعيينه على "opportunistic"، تُحاول طلبات DNS إرسالها معمّاة باستخدام DNS-over-TLS. إذا كان خادم DNS لا يدعم TLS، يتم تعطيل DNS-over-TLS. لاحظ أن هذا الوضع يجعل DNS-over-TLS عرضة لهجمات "الخفض"، حيث قد يتمكن المهاجم من تحفيز خفض إلى وضع غير معمّى عن طريق تركيب استجابة توحي بأن DNS-over-TLS غير مدعوم. إذا تم تعيينه على خطأ، تُرسل عمليات بحث DNS عبر UDP.

لاحظ أن DNS-over-TLS يتطلب إرسال بيانات إضافية لإعداد اتصال معمّى، وبالتالي يؤدي إلى عقوبة زمنية صغيرة في وقت بحث DNS.

لاحظ أنه في وضع "opportunistic"، لا يكون المحلل قادرًا على استيثاق الخادم، لذا فهو عرضة لهجمات "الرجل في المنتصف".

بالإضافة إلى إعداد DNSOverTLS= العام هذا، يحتفظ systemd-networkd.service(8) أيضًا بإعدادات DNSOverTLS= لكل وصلة. بالنسبة لخوادم DNS النظامية (انظر أعلاه)، يكون إعداد DNSOverTLS= العام فقط ساري المفعول. بالنسبة لخوادم DNS لكل وصلة، يكون الإعداد لكل وصلة ساري المفعول، ما لم يكن غير معين، وفي هذه الحالة يُستخدم الإعداد العام بدلاً من ذلك.

المبدئي هو "no".

أُضيف في الإصدار 239.

Cache=

يأخذ وسيطة منطقية أو "no-negative". إذا كانت "yes" (المبدئي)، فإن حل اسم نطاق تم الاستعلام عنه سابقًا سيعيد النتيجة السابقة طالما أنها لا تزال صالحة، وبالتالي لا يؤدي إلى طلب شبكة جديد. كن على علم أن إيقاف التخزين المؤقت يأتي بعقوبة أداء، وهي مرتفعة بشكل خاص عند استخدام DNSSEC. إذا كانت "no-negative"، يتم تخزين الإجابات الإيجابية فقط مؤقتًا.

لاحظ أن التخزين المؤقت معطل مبدئيًا لخوادم DNS المحلية للمضيف. انظر CacheFromLocalhost= للحصول على التفاصيل.

أُضيف في الإصدارة 231.

CacheFromLocalhost=

يأخذ وسيطة منطقية. إذا كانت "no" (المبدئي)، وجاءت الاستجابة من عنوان IP محلي للمضيف (مثل 127.0.0.1 أو ::1)، فلن يتم تخزين النتيجة مؤقتًا لتجنب التخزين المؤقت المحلي المكرر المحتمل.

أُضيف في الإصدار 248.

DNSStubListener=

يأخذ وسيطة منطقية أو واحدة من "udp" و "tcp". إذا كانت "udp"، فسيستمع محلل DNS الفرعي لطلبات UDP على العناوين 127.0.0.53 و 127.0.0.54، المنفذ 53. إذا كانت "tcp"، فسيستمع المحلل الفرعي لطلبات TCP على نفس العناوين والمنفذ. إذا كانت "yes" (المبدئي)، يستمع المحلل الفرعي لكل من طلبات UDP و TCP. إذا كانت "no"، يتم تعطيل المستمع الفرعي.

يوفر محلل DNS الناقص (stub resolver) على 127.0.0.53 مجموعة الميزات الكاملة للمحلل المحلي، والتي تتضمن تقديم حل LLMNR/MulticastDNS. يوفر محلل DNS الناقص على 127.0.0.54 محللًا أكثر محدودية، يعمل في وضع "الوكيل" فقط، أي أنه سيمرر معظم رسائل DNS غير معدلة نسبيًا إلى خوادم DNS الحالية في المنبع ويعيدها، لكنه لا يحاول معالجة الرسائل محليًا، وبالتالي لا يتحقق من DNSSEC، أو يقدم LLMNR/MulticastDNS. (ومع ذلك، سيترجم إلى اتصال DNS-over-TLS إذا لزم الأمر.)

لاحظ أن مستمع DNS الفرعي يُوقف ضمنيًا عندما يكون عنوان الاستماع والمنفذ قيد الاستخدام بالفعل.

أُضيف في الإصدار 232.

DNSStubListenerExtra=

يقبل عنوان IPv4 أو IPv6 للاستماع عليه. يمكن اختياريًا أن يسبق العنوان باسم بروتوكول ("udp" أو "tcp") مفصول بـ ":". إذا لم يُحدد البروتوكول، ستستمع الخدمة على كل من UDP وTCP. يمكن أيضًا اختياريًا أن يلحق برقم منفذ عددي مع فاصل ":". عند تحديد عنوان IPv6 مع رقم منفذ، يجب أن يكون العنوان بين قوسين مربعين. إذا لم يُحدد المنفذ، تستخدم الخدمة المنفذ 53. لاحظ أن هذا مستقل عن الـ DNS stub الرئيسي المُهيأ بـ DNSStubListener=، ويُهيئ فقط مآخذ إضافية للاستماع عليها. يمكن تحديد هذا الخيار عدة مرات. إذا أُسندت سلسلة فارغة، فسيتم مسح جميع الإسنادات السابقة. المبدئي غير مُحدد.

أمثلة:

DNSStubListenerExtra=192.168.10.10
DNSStubListenerExtra=2001:db8:0:f102::10
DNSStubListenerExtra=192.168.10.11:9953
DNSStubListenerExtra=[2001:db8:0:f102::11]:9953
DNSStubListenerExtra=tcp:192.168.10.12
DNSStubListenerExtra=udp:2001:db8:0:f102::12
DNSStubListenerExtra=tcp:192.168.10.13:9953
DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953

أُضيف في الإصدار 247.

ReadEtcHosts=

يقبل وسيطًا منطقيًا. إذا كان "yes" (المبدئي)، سيقرأ systemd-resolved ملف /etc/hosts، ويحاول حل المضيفين أو العناوين باستخدام الإدخالات في الملف قبل إرسال الاستعلام إلى خوادم DNS.

أُضيف في الإصدار 240.

ResolveUnicastSingleLabel=

يقبل وسيطًا منطقيًا. عندما يكون false (المبدئي)، لن يحل systemd-resolved استعلامات A وAAAA للأسماء ذات التسمية الواحدة عبر DNS التقليدي. لاحظ أن هذه الأسماء قد تُحل إذا حُددت نطاقات بحث (انظر Domains= أعلاه)، أو باستخدام آليات أخرى، خاصة عبر LLMNR أو من /etc/hosts. عندما يكون true، سيتم توجيه استعلامات الأسماء ذات التسمية الواحدة إلى خوادم DNS العالمية حتى لو لم تُعرف نطاقات بحث.

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

أُضيف في الإصدار 246.

StaleRetentionSec=ثوانٍ

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

هذا مفيد عند حدوث فشل في خادم DNS أو يصبح غير قابل للوصول. في هذه الحالات، يستمر systemd-resolved(8) في استخدام السجلات القديمة للإجابة على استعلامات DNS، خاصة عندما لا يمكن الحصول على استجابة صالحة من خوادم DNS العلوية. ومع ذلك، لا ينطبق هذا على استجابات NXDOMAIN، لأنها لا تزال استجابات صالحة تمامًا. تعزز هذه الميزة المرونة ضد فشل وانقطاعات البنية التحتية لـ DNS.

يحاول systemd-resolved دائمًا الوصول إلى خوادم DNS العلوية أولاً، قبل تزويد تطبيق العميل بأي بيانات قديمة. إذا فُعلت هذه الميزة، لن تُمسح الخبيئة عند تغيير الخوادم.

أُضيف في الإصدار 254.

انظر أيضًا

systemd(1), systemd-resolved.service(8), systemd-networkd.service(8), dnssec-trust-anchors.d(5), resolv.conf(5)

ملاحظات

1.
💣💥🧨💥💥💣 يرجى ملاحظة أن ملفات الضبط تلك يجب أن تكون متوفرة في جميع الأوقات. إذا كان /usr/local/ قسماً منفصلاً، فقد لا يكون متوفراً أثناء بدء التشغيل المبكر، ويجب عدم استخدامه للضبط.
2.
RFC 4795
https://tools.ietf.org/html/rfc4795
3.
RFC 6762
https://tools.ietf.org/html/rfc6762
4.
بيان IAB
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

systemd 257.13