الشبكات بدون تهيئة

تُعدّ الشبكات ذات التكوين الصفري ( zeroconf ) مجموعة من التقنيات التي تُنشئ تلقائيًا شبكة حاسوب قابلة للاستخدام استنادًا إلى بروتوكول الإنترنت (TCP/IP) عند ربط أجهزة الحاسوب أو ملحقات الشبكة. ولا تتطلب هذه التقنية تدخلًا يدويًا من المشغل أو خوادم تكوين خاصة. فبدون Zeroconf، يتعين على مسؤول الشبكة إعداد خدمات الشبكة ، مثل بروتوكول التكوين الديناميكي للمضيف (DHCP) ونظام أسماء النطاقات (DNS)، أو تكوين إعدادات الشبكة لكل جهاز حاسوب يدويًا.

يعتمد Zeroconf على ثلاث تقنيات أساسية: التعيين التلقائي لعناوين الشبكة الرقمية للأجهزة المتصلة بالشبكة، والتوزيع التلقائي وحل أسماء مضيفي الكمبيوتر ، وتحديد الموقع التلقائي لخدمات الشبكة ، مثل أجهزة الطباعة.

خلفية

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

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

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

يُعدّ بروتوكول AppleTalk مثالًا مبكرًا على أنظمة الشبكات المحلية التي لا تتطلب أي إعدادات مسبقة ، وهو بروتوكول قدمته شركة Apple لأجهزة Macintosh الأولى في ثمانينيات القرن الماضي. كان بالإمكان إضافة أجهزة Mac، بالإضافة إلى الأجهزة الأخرى التي تدعم البروتوكول، إلى الشبكة بمجرد توصيلها؛ حيث كانت جميع عمليات الإعداد اللاحقة مؤتمتة. يتم اختيار عناوين الشبكة تلقائيًا بواسطة كل جهاز باستخدام بروتوكول يُعرف باسم بروتوكول تحليل عناوين AppleTalk (AARP)، بينما يقوم كل جهاز بإنشاء خدمة دليل محلية خاصة به باستخدام بروتوكول يُعرف باسم بروتوكول ربط الأسماء (NBP). لا يقتصر بروتوكول NBP على الاسم فحسب، بل يشمل أيضًا نوع الجهاز وأي معلومات إضافية يُدخلها المستخدم، مثل موقعه الفعلي أو مدى توفره. يستطيع المستخدمون البحث عن أي جهاز على الشبكة باستخدام تطبيق Chooser ، الذي يقوم بتصفية الأسماء بناءً على نوع الجهاز.

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

اختيار العنوان

يجب تخصيص عناوين IP للأجهزة المضيفة على الشبكة، بحيث تُعرّفها هذه العناوين بشكل فريد للأجهزة الأخرى على نفس الشبكة. في بعض الشبكات، توجد جهة مركزية تُخصّص هذه العناوين عند إضافة أجهزة جديدة. وقد طُوّرت آليات للتعامل مع هذه المهمة تلقائيًا، ويشمل كل من IPv4 وIPv6 الآن أنظمة للتكوين التلقائي للعناوين ، مما يسمح للجهاز بتحديد عنوان آمن للاستخدام من خلال آليات بسيطة. بالنسبة لعنونة الارتباط المحلي ، يستخدم IPv4 النطاق الخاص 169.254.0.0/16 ، [ 1 ] بينما تستخدم أجهزة IPv6 البادئة fe80:: / 10 . في أغلب الأحيان، تُخصّص العناوين بواسطة خادم DHCP ، والذي غالبًا ما يكون مُدمجًا في أجهزة الشبكات الشائعة مثل أجهزة الكمبيوتر أو أجهزة التوجيه.

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

يُشترط على أجهزة IPv6 دعم عناوين متعددة لكل واجهة؛ علاوة على ذلك، يُشترط على كل جهاز IPv6 تكوين عنوان محلي للرابط حتى في حال توفر عناوين عامة. كما يمكن لأجهزة IPv6 تكوين عناوين إضافية تلقائيًا عند استلام رسائل إعلان الموجه، مما يُلغي الحاجة إلى خادم DHCP. [ 2 ]

يمكن لمضيفي IPv4 وIPv6 توليد الجزء الخاص بهم من عنوان مُكوّن تلقائيًا بشكل عشوائي. عادةً ما يجمع مضيفو IPv6 بادئة تصل إلى 64 بت مع مُعرّف EUI-64 ذي 64 بت، مُشتق من عنوان MAC المُخصص من المصنع (IEEE) ذي 48 بت . يتميز عنوان MAC بكونه فريدًا عالميًا، وهي خاصية أساسية لمُعرّف EUI-64. يتضمن بروتوكول IPv6 أيضًا آلية لاكتشاف العناوين المُكررة لتجنب التعارض مع المضيفين الآخرين. في IPv4، تُسمى هذه الطريقة " التكوين التلقائي للعنوان المحلي للرابط" . [ 1 ] مع ذلك، تُشير إليها مايكروسوفت باسم "التخصيص التلقائي لعناوين IP الخاصة" (APIPA) [ 3 ] أو " التكوين التلقائي لبروتوكول الإنترنت " ( IPAC ). هذه الميزة مدعومة في نظام ويندوز منذ إصدار ويندوز 98 على الأقل . [ 4 ]

اكتشاف خدمة الأسماء

تستخدم بروتوكولات الإنترنت عناوين IP للاتصالات، إلا أن استخدامها ليس سهلاً على البشر؛ فبروتوكول IPv6 تحديداً يستخدم سلاسل طويلة جداً من الأرقام يصعب إدخالها يدوياً. ولمعالجة هذه المشكلة، يستخدم الإنترنت منذ زمن طويل نظام أسماء النطاقات (DNS)، الذي يسمح بربط أسماء يسهل على البشر قراءتها بعناوين IP، ويتضمن شيفرة للبحث عن هذه الأسماء في نظام قاعدة بيانات هرمي. يُدخل المستخدمون أسماء النطاقات، مثل example.org ، والتي يبحث عنها برنامج DNS الخاص بالحاسوب في قواعد بيانات DNS لاسترداد عنوان IP، ثم يُمرر هذا العنوان إلى حزمة البروتوكولات لإجراء المزيد من الاتصالات. [ 5 ]

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

كان الهدف من نظام أسماء النطاقات (DNS) هو توفير أسماء موحدة لمجموعات الأجهزة ضمن نطاق إداري واحد، مثل example.org ، والتي توفرها خدمة أسماء النطاقات. يتطلب تعيين عنوان لجهاز محلي، مثل thirdfloorprinter.example.org ، عادةً صلاحيات المسؤول على خادم DNS، ويتم ذلك غالبًا يدويًا. إضافةً إلى ذلك، لا يُتوقع من خوادم DNS التقليدية تصحيح التغييرات في الإعدادات تلقائيًا. على سبيل المثال، إذا نُقلت طابعة من طابق إلى آخر، فقد يُخصص لها خادم DHCP المحلي عنوان IP جديدًا. [ 5 ]

لتلبية الحاجة إلى التكوين التلقائي، طبّقت مايكروسوفت خدمة أسماء NetBIOS ، التي تُعدّ خدمة مستعرض الكمبيوتر جزءًا منها، والموجودة بالفعل في نظام التشغيل Microsoft Windows for Workgroups 3.11 [ 6 ] منذ عام 1992. تتميز خدمة أسماء NetBIOS بعدم الحاجة إلى أي تكوين على الشبكات ذات الشبكة الفرعية الواحدة، ويمكن استخدامها بالتزامن مع خادم WINS أو خادم DNS من مايكروسوفت يدعم التسجيل التلقائي الآمن للعناوين. يتميز هذا النظام بانخفاض تكلفة الإدارة، وإن لم تكن معدومة، حتى في شبكات المؤسسات الكبيرة جدًا. تُعدّ البروتوكولات التي يمكن لـ NetBIOS استخدامها جزءًا من مجموعة بروتوكولات Server Message Block (SMB) المفتوحة [ 6 ] ، والمتوفرة أيضًا على أنظمة Linux وiOS، مع العلم أن نظام Windows يدعم عادةً نطاقًا أوسع من اللهجات التي يمكن التفاوض عليها بين عملاء Windows الذين يدعمونها. على سبيل المثال، يتم اختيار خدمات مستعرض الكمبيوتر التي تعمل على أنظمة تشغيل الخوادم أو الإصدارات الأحدث من Windows كمستعرض رئيسي ، على عكس تلك التي لا تعمل بنظام تشغيل خادم أو التي تعمل بإصدارات أقدم من Windows. [ 6 ]

في عام 2000، وصف بيل مانينغ وبيل وودكوك خدمة أسماء النطاقات متعددة البث [ 7 ] ، والتي انبثقت عنها تطبيقات شركتي آبل ومايكروسوفت. يتشابه التطبيقان إلى حد كبير. نُشرت خدمة أسماء النطاقات متعددة البث (mDNS) من آبل كمقترح معياري RFC 6762 ، بينما نُشرت خدمة حل أسماء النطاقات متعددة البث المحلية للرابط (LLMNR) من مايكروسوفت كمعيار معلوماتي RFC 4795. تُضمّن خدمة LLMNR في جميع إصدارات ويندوز بدءًا من ويندوز فيستا [ 8 ] ، وتعمل كبديل مباشر لخدمة أسماء NetBIOS من مايكروسوفت عبر IPv4، وكبديل لها عبر IPv6، نظرًا لعدم توفر NetBIOS عبر IPv6. يتوفر تطبيق آبل كخدمة Bonjour منذ عام 2002 في نظام التشغيل Mac OS X v10.2. يتوفر تطبيق Bonjour (mDNSResponder) بموجب ترخيص Apache 2 مفتوح المصدر [ 9 ] ، وهو مُضمّن في نظام Android Jelly Bean والإصدارات الأحدث [ 10 ] بموجب الترخيص نفسه.  

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

مع إصدار نظام التشغيل ويندوز 10، أعلنت مايكروسوفت عن إيقاف دعم بروتوكولي NetBIOS وLLMNR واعتماد بروتوكول mDNS. [ 11 ] [ 12 ] على الرغم من أن تطبيق ويندوز 10 في الإصدارات السابقة (الإصدار 1703) كان يقتصر على اكتشاف الطابعات المتصلة بالشبكة، وأجهزة عكس الشاشة، ومكبرات الصوت اللاسلكية، وما إلى ذلك، إلا أن الإصدارات اللاحقة (ويندوز 10 الإصدار 1903 وما بعده) قامت بحل أسماء المضيفين أيضًا. [ 13 ] يُعطى بروتوكول mDNS الأولوية في ويندوز 10 والإصدارات الأحدث، لكن بروتوكولات LLMNR وNetBIOS Name Service و SSDP لا تزال تعمل كخيار احتياطي إلى جانب mDNS في ويندوز في الوقت الحالي. [ 11 ]

تختلف بروتوكولات mDNS وLLMNR اختلافًا طفيفًا في طريقة حلّ أسماء النطاقات. يسمح بروتوكول mDNS لجهاز الشبكة باختيار اسم نطاق في مساحة أسماء DNS المحلية والإعلان عنه باستخدام عنوان IP خاص بالبث المتعدد. يُدخل هذا دلالات خاصة على نطاق المستوى الأعلى local ، [ 14 ] وهو ما يعتبره بعض أعضاء IETF مشكلة. [ 15 ] يسمح مشروع LLMNR الحالي لجهاز الشبكة باختيار أي اسم نطاق، وهو ما يعتبره بعض أعضاء IETF خطرًا أمنيًا. [ 16 ] يتوافق بروتوكول mDNS مع DNS-SD كما هو موضح في القسم التالي، بينما لا يتوافق بروتوكول LLMNR معه. [ 17 ]

اكتشاف الخدمات

لا توفر خدمات أسماء الأجهزة، مثل mDNS وLLMNR وغيرها، معلوماتٍ عن نوع الجهاز أو حالته. فعلى سبيل المثال، قد يواجه المستخدم صعوبةً في العثور على طابعة قريبة إذا كان اسم الطابعة "بوب" . يوفر اكتشاف الخدمات معلوماتٍ إضافيةً عن الأجهزة. ويُدمج اكتشاف الخدمات أحيانًا مع خدمة أسماء الأجهزة ، كما هو الحال في بروتوكول ربط الأسماء من Apple و NetBIOS من Microsoft .

اكتشاف خدمة NetBIOS

يدعم بروتوكول NetBIOS على نظام التشغيل Windows الأجهزة المضيفة الفردية على الشبكة للإعلان عن الخدمات، مثل مشاركة الملفات والطابعات. كما يدعم، على سبيل المثال، طابعة الشبكة للإعلان عن نفسها كمضيف يشارك طابعة وأي خدمات أخرى ذات صلة. يعتمد ذلك على كيفية اتصال الجهاز (بالشبكة مباشرةً، أو بالمضيف الذي يشاركه) والبروتوكولات المدعومة. مع ذلك، قد تُفضل عملاء Windows المتصلون به استخدام بروتوكول SSDP أو WSD عبر NetBIOS. يُعد NetBIOS أحد مزودي خدمات Windows الذين يُنفذون عملية الاكتشاف العامة المعروفة باسم اكتشاف الوظائف ، والتي تتضمن مزودي خدمات مدمجين لبروتوكولات PnP، والسجل، وNetBIOS، وSSDP، وWSD [ 18 ] ، حيث أن البروتوكولين الأولين محليان فقط، بينما تدعم البروتوكولات الثلاثة الأخيرة اكتشاف الأجهزة المتصلة بالشبكة. لا يتطلب أي من هذه البروتوكولات أي تهيئة للاستخدام على الشبكة الفرعية المحلية. تقليديًا، كان دعم NetBIOS مقتصرًا على الطابعات باهظة الثمن للاستخدام المؤسسي، على الرغم من أن بعض الطابعات منخفضة التكلفة المزودة بتقنية Wi-Fi أو Ethernet تدعمه بشكل أصلي، مما يسمح باستخدام الطابعة دون تهيئة حتى على أنظمة التشغيل القديمة جدًا.

WS-Discovery

يُعدّ اكتشاف خدمات الويب الديناميكي ( WS-Discovery ) مواصفةً تقنيةً تُعرّف بروتوكول اكتشاف متعدد البث لتحديد مواقع الخدمات على الشبكة المحلية. يعمل هذا البروتوكول عبر منفذي TCP وUDP رقم 3702، ويستخدم عنوان IP متعدد البث 239.255.255.250 . وكما يوحي الاسم، يتم التواصل الفعلي بين العُقد باستخدام معايير خدمات الويب، وتحديدًا SOAP عبر UDP . يدعم نظام التشغيل Windows هذا البروتوكول من خلال خدمات الويب للأجهزة وملف تعريف الأجهزة لخدمات الويب . كما تدعمه العديد من الأجهزة، مثل طابعات HP وBrother.

اكتشاف الخدمة القائم على نظام أسماء النطاقات (DNS)

تتيح تقنية DNS-SD (اكتشاف خدمة نظام أسماء النطاقات [ 19 ] ) للعملاء اكتشاف قائمة مُسماة من مثيلات الخدمة، وربط هذه الخدمات بأسماء المضيفين باستخدام استعلامات نظام أسماء النطاقات القياسية. تتوافق هذه التقنية مع برامج خادم وعميل نظام أسماء النطاقات أحادي البث الحالية، كما تعمل بكفاءة عالية مع mDNS في بيئة لا تتطلب أي إعدادات. يتم وصف كل مثيل خدمة باستخدام سجل DNS SRV [ 20 ] وسجل DNS TXT [ 21 ] . يكتشف العميل قائمة المثيلات المتاحة لنوع خدمة مُحدد من خلال الاستعلام عن سجل DNS PTR [ 21 ] الخاص باسم ذلك النوع من الخدمة؛ يُعيد الخادم صفرًا أو أكثر من الأسماء بالصيغة<الخدمة>.<النطاق>، حيث يُقابل كل اسم زوجًا من سجلات SRV/TXT.سجل SRVإلى اسم النطاق الذي يُوفر المثيل، بينما يُمكن أن يحتوي سجل TXT على معلمات تكوين خاصة بالخدمة. بعد ذلك، يُمكن للعميل ربط سجل A/AAAA الخاص باسم النطاق والاتصال بالخدمة.

تُمنح أنواع الخدمات وفقًا لأسبقية الحجز. كان سجل أنواع الخدمات يُدار في الأصل بواسطة DNS-SD.org، [ 19 ] ولكن تم دمجه لاحقًا في سجل IANA لسجلات DNS SRV. [ 22 ]

تاريخ

في عام ١٩٩٧، اقترح ستيوارت تشيشاير تكييف بروتوكول ربط الأسماء (Name Binding Protocol) الخاص بشركة آبل مع شبكات بروتوكول الإنترنت (IP) لمعالجة نقص إمكانية اكتشاف الخدمات. [ ٢٣ ] انضم تشيشاير لاحقًا إلى آبل، وكتب مسودات مقترحات فريق هندسة الإنترنت (IETF) لبروتوكول mDNS واكتشاف الخدمات القائم على نظام أسماء النطاقات (DNS)، دعمًا للانتقال من AppleTalk إلى شبكات بروتوكول الإنترنت. في عام ٢٠٠٢، أعلنت آبل عن تطبيق كلا البروتوكولين تحت اسم Rendezvous [ ٢٤ ] (أُعيدت تسميته لاحقًا إلى Bonjour). أُدرج لأول مرة في نظام التشغيل Mac OS X 10.2 ، ليحل محل بروتوكول تحديد موقع الخدمة (SLP) المستخدم في الإصدار 10.1 . في عام ٢٠١٣، صُدّقت المقترحات في RFC 6762 [ ٢٥ ] و RFC 6763. [ ٢٦ ]  

DNS-SD مع البث المتعدد

يستخدم بروتوكول mDNS حزم بيانات مشابهة لبروتوكول DNS أحادي البث لحل أسماء المضيفين، إلا أنها تُرسل عبر رابط متعدد البث. يستمع كل مضيف على منفذ mDNS رقم 5353، المُرسل إلى عنوان متعدد البث معروف، ويحل طلبات سجل DNS الخاص باسم مضيفه المحلي (مثل A أو AAAA أو CNAME ) إلى عنوان IP الخاص به. عندما يحتاج عميل mDNS إلى حل اسم مضيف محلي إلى عنوان IP، فإنه يرسل طلب DNS لهذا الاسم إلى عنوان متعدد البث المعروف؛ فيرد الجهاز الذي يحمل سجل A/AAAA المقابل بعنوان IP الخاص به. عنوان mDNS متعدد البث هو 224.0.0.251 لعنونة IPv4 و ff02::fb لعنونة IPv6 المحلية للرابط.

يمكن أيضًا إرسال طلبات اكتشاف خدمة نظام أسماء النطاقات ( DNS-SD) باستخدام mDNS لتوفير خدمة DNS-SD بدون أي إعدادات مسبقة. [ 27 ] تستخدم هذه الخدمة سجلات DNS PTR وSRV و TXT للإعلان عن أنواع الخدمات، وأسماء النطاقات الخاصة بها، ومعلمات التكوين الاختيارية للاتصال بها. ويمكن الآن لسجلات SRV أن تُحلّل إلى أسماء نطاقات .local ، والتي بدورها تُحلّل إلى عناوين IP محلية باستخدام mDNS.

يدعم

يُستخدم بروتوكول DNS-SD في منتجات Apple، ومعظم طابعات الشبكة، والعديد من توزيعات Linux، بما في ذلك Debian و Ubuntu ، [ 28 ] بالإضافة إلى عدد من منتجات الجهات الخارجية لأنظمة تشغيل مختلفة. على سبيل المثال، يمكن للعديد من تطبيقات الشبكة في نظام التشغيل OS X ، التي طورتها Apple، مثل Safari و iChat و Messages ، استخدام DNS-SD لتحديد مواقع الخوادم القريبة وعملاء الند للند. يدعم نظام Windows 10 بروتوكول DNS-SD للتطبيقات المكتوبة بلغة JavaScript. [ 29 ] قد تتضمن بعض التطبيقات دعمًا خاصًا بها في الإصدارات القديمة من نظام التشغيل، بحيث تدعم معظم برامج المراسلة الفورية وعملاء VoIP على Windows بروتوكول DNS-SD. كما تتضمن بعض توزيعات Unix و BSD وLinux بروتوكول DNS-SD. على سبيل المثال، يأتي توزيع Ubuntu الأساسي مزودًا ببرنامج Avahi ، وهو تطبيق mDNS/DNS-SD.

UPnP

يحتوي بروتوكول UPnP على بعض مكونات البروتوكول التي تهدف إلى اكتشاف الخدمات.

SSDP

بروتوكول اكتشاف الخدمة البسيط (SSDP) هو بروتوكول UPnP، يُستخدم في نظام التشغيل Windows XP والإصدارات الأحدث. يستخدم SSDP إشعارات HTTP التي تُحدد نوع الخدمة واسمها الفريد (USN). تُنظم أنواع الخدمات من قِبل اللجنة التوجيهية للتوصيل والتشغيل العالمي (UPnP). يدعم SSDP العديد من مُصنّعي الطابعات وأجهزة التخزين الشبكي (NAS) والأجهزة المنزلية، مثل Brother. كما تدعمه بعض العلامات التجارية لمعدات الشبكات، والعديد من أجهزة جدار الحماية الخاصة بالمكاتب الصغيرة والمكاتب المنزلية (SOHO) ، حيث يمكن لأجهزة الكمبيوتر المضيفة المتصلة به إنشاء منافذ للتطبيقات. يُستخدم أيضًا في أنظمة الكمبيوتر الخاصة بالمسرح المنزلي لتسهيل تبادل الوسائط بين أجهزة الكمبيوتر المضيفة ومركز الوسائط.

DLNA

يُعدّ تحالف الشبكات الرقمية المنزلية (DLNA) مجموعة أخرى من المعايير التي تستخدم بروتوكول UPnP لاكتشاف الأجهزة المتصلة بالشبكة. ويضم DLNA قائمة طويلة من الشركات المصنّعة البارزة التي تُنتج أجهزة مثل أجهزة التلفاز وأجهزة التخزين الشبكي (NAS) وغيرها، والتي تدعم هذا المعيار. كما يدعم DLNA جميع أنظمة التشغيل الرئيسية. ويعتمد اكتشاف خدمة DLNA على بروتوكول SSDP.

الجهود المبذولة نحو بروتوكول معياري من IETF

يدعم نظام SLP طابعات الشبكة من هيوليت-باكارد ، ونوفيل ، وسن مايكروسيستمز . وصف نظام SLP موجود في RFC 2608 و RFC 3224 ، وتتوفر تطبيقاته لأنظمة سولاريس ولينكس .  

كل جوين

AllJoyn عبارة عن حزمة برمجية مفتوحة المصدر تُستخدم مع مجموعة واسعة من الأجهزة، بدءًا من أجهزة إنترنت الأشياء وصولًا إلى أجهزة الكمبيوتر، لاكتشاف الأجهزة والتحكم بها على الشبكات (واي فاي، إيثرنت) وغيرها من الروابط (بلوتوث، زيجبي، إلخ). تستخدم هذه الحزمة بروتوكول mDNS وبروتوكول HTTP عبر UDP وبروتوكولات أخرى. مع ذلك، لم يعد المشروع نشطًا منذ عام 2016، ولا يُنصح باستخدامه في المشاريع الجديدة. [ 30 ]

التقييس

تم نشر معيار RFC 2608 ، وهو معيار SLP لتحديد مكان الحصول على الخدمات، في يونيو 1999 من قبل مجموعة عمل SVRLOC IETF. [ 31 ] 

تم نشر معيار RFC 3927 ، الخاص باختيار عناوين العناصر المتصلة بالشبكة، في مارس 2005 من قبل فريق عمل Zeroconf التابع لـ IETF. ضم الفريق أفرادًا من شركات Apple وSun وMicrosoft. [ 32 ] 

تم تقديم LLMNR للاعتماد الرسمي في مجموعة عمل IETF DNSEXT؛ ومع ذلك، فقد فشل في الحصول على توافق في الآراء، وبالتالي تم نشره كـ RFC 4795 إعلامي في يناير 2007. [ 33 ] 

بعد فشل LLMNR في أن يصبح معيارًا للإنترنت، ونظرًا لأن mDNS/DNS-SD يستخدم على نطاق أوسع بكثير من LLMNR، فقد طُلب من Apple من قبل IETF تقديم مواصفات mDNS/DNS-SD للنشر كـ RFC معلوماتي أيضًا.

في فبراير 2013، تم نشر mDNS و DNS-SD كمقترحات مسار المعايير RFC 6762 و RFC 6763 .  

قضايا أمنية

نظرًا لأن بروتوكول mDNS يعمل وفق نموذج ثقة مختلف عن بروتوكول DNS أحادي البث - إذ يعتمد على الثقة في الشبكة بأكملها بدلًا من خادم DNS مُحدد - فهو عرضة لهجمات انتحال الهوية من أي نظام ضمن نطاق البث نفسه . ومثل بروتوكول SNMP والعديد من بروتوكولات إدارة الشبكات الأخرى، يمكن للمهاجمين استخدامه أيضًا للحصول بسرعة على معلومات تفصيلية عن الشبكة وأجهزتها. [ 34 ] لهذا السبب، ينبغي على التطبيقات التحقق من هوية المستخدمين وتشفير حركة البيانات إلى المضيفين البعيدين (مثلًا عبر RSA أو SSH ، إلخ) بعد اكتشافهم وحل أسماء النطاقات من خلال DNS-SD/mDNS. ويعاني بروتوكول LLMNR من ثغرات أمنية مماثلة. [ 35 ]

عمليات التنفيذ الرئيسية

أبل بونجور

يستخدم تطبيق Bonjour من Apple بروتوكول mDNS واكتشاف خدمة DNS. وقد غيّرت Apple تقنية zeroconf المفضلة لديها من SLP إلى mDNS وDNS-SD بين نظامي التشغيل Mac OS X 10.1 و 10.2 ، مع استمرار دعم SLP في نظام Mac OS X.

يحتوي برنامج mDNSResponder من Apple على واجهات برمجة تطبيقات للغتين C و Java [ 36 ] ، وهو متوفر لأنظمة BSD و Apple Mac OS X و Linux وأنظمة التشغيل الأخرى المبنية على معيار POSIX و MS Windows. ويمكن تنزيل البرنامج لنظام Windows من موقع Apple الإلكتروني. [ 37 ]

أفاهي

أفاهي هو تطبيق Zeroconf لأنظمة لينكس وبي إس دي . يدعم بروتوكولات IPv4LL وmDNS وDNS-SD. وهو جزء من معظم توزيعات لينكس، ومثبت افتراضيًا في بعضها. عند تشغيله مع nss-mdns، فإنه يوفر أيضًا خدمة تحليل أسماء المضيفين. [ 38 ]

كما يقوم Avahi بتنفيذ مكتبات التوافق الثنائي التي تحاكي Bonjour وتطبيق mDNS التاريخي Howl، لذلك يمكن للبرامج المصممة لاستخدام هذه التطبيقات أيضًا استخدام Avahi من خلال واجهات المحاكاة.

نظام التشغيل ويندوز سي إي 5.0

يتضمن نظام التشغيل Microsoft Windows CE 5.0 تطبيق Microsoft الخاص لـ LLMNR.

نظام إدارة النظام (Systemd)

يقوم Systemd بتنفيذ كل من mDNS و LLMNR في systemd-resolved.

في حال عدم توفر خادم DHCP لتخصيص عنوان IP لجهاز، يمكن للجهاز اختيار عنوان محلي خاص به . باستخدام هذا العنوان، يمكن للأجهزة التواصل عبر هذا الرابط، ولكن محليًا فقط؛ ولا يمكن الوصول إلى الشبكات الأخرى أو الإنترنت. تتوفر بعض تطبيقات عناوين IPv4 المحلية.

  • يدعم نظاما التشغيل ماك أو إس من آبل ومايكروسوفت ويندوز عناوين الارتباط المحلي منذ ويندوز 98 وماك أو إس 8.5 (كلاهما صدر عام 1998). [ 1 ] وقد أصدرت آبل تطبيقها مفتوح المصدر في حزمة داروين bootp.
  • يحتوي برنامج Avahi على تطبيق لبروتوكول IPv4LL في أداة avahi-autoipd.
  • بروتوكول الإنترنت بدون تكوين (zcip) [ 39 ]
  • يمكن لـ BusyBox تضمين تطبيق بسيط لبروتوكول IPv4LL.
  • Stablebox، [ 40 ] وهو نسخة معدلة قليلاً من Busybox، يقدم تطبيق IPv4LL معدل قليلاً يسمى llad.
  • Zeroconf [ 41 ] عبارة عن حزمة تعتمد على Simple IPv4LL، وهو تطبيق أقصر من إعداد آرثر فان هوف . [ 42 ]

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

لا تعالج أي من هاتين الطريقتين مشكلات النواة مثل بث ردود ARP [ 45 ] أو إغلاق اتصالات الشبكة الحالية.

انظر أيضاً

مراجع

ملحوظات

  1. 1 2 3 إس. تشيشاير ؛ ب. أبوبا؛ إي. غوتمان (مايو 2005). التكوين الديناميكي لعناوين IPv4 المحلية للرابط . مجموعة عمل الشبكة. doi : 10.17487/RFC3927 . RFC 3927 .المعيار المقترح.
  2. إس. طومسون؛ تي. نارتن؛ تي. جينمي (سبتمبر 2007). التكوين التلقائي لعناوين IPv6 عديمة الحالة . مجموعة عمل الشبكة. doi : 10.17487/RFC4862 . RFC 4862 .مسودة معيار. تلغي RFC 2462. تم تحديثها بواسطة RFC 7527 .  
  3. "Apipa"، شبكة مطوري مايكروسوفت ، مايكروسوفت، مؤرشف من الأصل بتاريخ 18 مارس 2017 ، تم استرجاعه بتاريخ 5 يوليو 2008
  4. "كيفية استخدام عناوين TCP/IP التلقائية بدون خادم DHCP"، قاعدة المعرفة ، مايكروسوفت، 6 يناير 2021
  5. 1 2 3 مارشال براين وستيفاني كروفورد، "كيف تعمل خوادم أسماء النطاقات" ، howstuffworks
  6. 1 2 3 "وصف خدمة مستعرض الكمبيوتر من مايكروسوفت" . قاعدة معارف مايكروسوفت . مايكروسوفت . تم الاطلاع عليه في 1 نوفمبر 2015 .
  7. مانينغ، بيل؛ وودكوك، بيل (أغسطس 2000)، "خدمة أسماء النطاقات متعددة البث" ، متتبع بيانات IETF ، IETF
  8. مكتبة مايكروسوفت تك نت: حل أسماء البث المتعدد المحلي للرابط (صفحة ويب)، مايكروسوفت، 5 مايو 2010
  9. ترخيص وعلامات Bonjour التجارية (صفحة ويب)، Apple
  10. واجهات برمجة تطبيقات أندرويد 4.1 (صفحة ويب)
  11. 1 2 التوافق على mDNS: تقليل سرعة تحليل أسماء NetBIOS و LLMNR
  12. نظام أسماء النطاقات المتنقل (mDNS) في المؤسسات
  13. تشقّ mDNS وDNS-SD طريقهما ببطء إلى نظام التشغيل Windows 10 ، مدونة Ctrl، 21 أكتوبر 2015 ، تم الاطلاع عليه بتاريخ 30 أغسطس 2017
  14. ردًا على: آخر نداء: "حل أسماء البث المتعدد المحلي للرابط (LLMNR)" إلى معيار مقترح (رسالة بريد إلكتروني)، IETF، مؤرشف من الأصل بتاريخ 2008-12-07 ، تم استرجاعه بتاريخ 2006-02-10
  15. ردًا على: ملخص النداء الأخير لـ LLMNR (رسالة بريد إلكتروني)، IETF، مؤرشف من الأصل بتاريخ 2008-12-07 ، تم استرجاعه بتاريخ 2006-02-10
  16. ملخص النداء الأخير لـ LLMNR (رسالة بريد إلكتروني)، IETF، مؤرشف من الأصل بتاريخ 2008-12-07 ، تم استرجاعه بتاريخ 2005-11-11
  17. مزيد من التفاصيل حول الاختلافات (رسالة البريد الإلكتروني)، IETF
  18. "حول اكتشاف الوظائف" . مركز مطوري ويندوز . مايكروسوفت . تم الاطلاع عليه في 1 نوفمبر 2015 .
  19. 1 2 DNS-SD
  20. RFC 2782 
  21. 1 2 RFC 1035 
  22. أنواع الخدمات ، DNS-SD
  23. تشيشاير، ستيوارت ، بروتوكول ربط الأسماء عبر بروتوكول الإنترنت (انتقاد لاذع)
  24. صفر تكوين
  25. إس. تشيشاير؛ إم. كروخمال (فبراير 2013). نظام أسماء النطاقات متعدد البث . IETF . doi : 10.17487/RFC6762 . RFC 6762 .
  26. إس. تشيشاير؛ إم. كروخمال (فبراير 2013). اكتشاف الخدمات القائم على نظام أسماء النطاقات . IETF . doi : 10.17487/RFC6763 . RFC 6763 .
  27. إس. تشيشاير ؛ إم. كروخمال (فبراير 2013). اكتشاف الخدمات القائم على نظام أسماء النطاقات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6763 . ISSN 2070-1721 . RFC 6763 . المعيار المقترح. تم تحديثه بواسطة RFC 8553 . 
  28. "بيان سطح المكتب لنظام أوبونتو 15.10" . أوبونتو . تم الاطلاع عليه بتاريخ 23 أكتوبر 2015 .
  29. "مساحة اسم Windows.Networking.ServiceDiscovery.Dnssd" . مركز مطوري Windows . مايكروسوفت . تم الاطلاع عليه في 1 نوفمبر 2015 .
  30. خطأ في التجميع باستخدام gcc الحديث ، تم استرجاعه بتاريخ 31 يناير 2025
  31. ميثاق بروتوكول تحديد موقع الخدمة (svrloc) ، IETF
  32. ميثاق شبكات التكوين الصفري (zeroconf) ، IETF، مؤرشف من الأصل بتاريخ 1 نوفمبر 2004 ، تم استرجاعه بتاريخ 28 أكتوبر 2004
  33. ميثاق امتدادات نظام أسماء النطاقات (dnsext) ، IETF، مؤرشف من الأصل بتاريخ 7 مارس 2005 ، تم استرجاعه بتاريخ 2 مارس 2005
  34. هجمات تسميم أسماء النطاقات (MDNS) داخل الشبكة المحلية (مدونة الويب العالمية)، مواطن جنو، 23 يناير 2008
  35. لودج، ديفيد (22 سبتمبر 2015). "كيفية الحصول على بيانات اعتماد من نظام ويندوز عبر LLMNR" . شركاء اختبار الاختراق .
  36. لقاء مع جافا ، مركز مطوري ماك، 31 أغسطس 2004
  37. "Bonjour لنظام التشغيل Windows 1.0.4"، الدعم ، Apple
  38. ^ لينارت، nss-mdns 0.10 ، DE : 0 مؤشر
  39. zcip ، سورس فورج
  40. "صندوق مستقر"، رمز
  41. Zeroconf ، أستراليا : UTS، مؤرشف من الأصل بتاريخ 9 مايو 2005 ، تم استرجاعه بتاريخ 4 مايو 2005
  42. AVH IPv4LL (شفرة مصدر C)، بدون تكوين
  43. "Zeroconf in udhcpc"، رسالة بريد إلكتروني ( udhcpc )، Busy box، مايو 2005، مؤرشفة من الأصل في 2006-02-06 ، تم استرجاعها في 2006-03-15
  44. ماربلز، روي، dhcpcd (مشروع)، مؤرشف من الأصل (ويكي) بتاريخ 12-07-2010 ، تم استرجاعه بتاريخ 07-01-2011
  45. "قياسات ARP المحلية للرابط"، AIR (ويكي)، شمال شرق : جامعة فرجينيا

مصادر

  • غوتمان، إريك (2001)، "التكوين التلقائي لشبكات بروتوكول الإنترنت: تمكين الاتصال المحلي"، مجلة IEEE للحوسبة عبر الإنترنت ، 5 (3): 81-86 ، doi : 10.1109/4236.935181