شهادة MCSA الفصل 4 : ال DNS and DHCP الجزء 2

sparrow
0

 



الفصل : 4

الجزء : 2

العنوان : ال DNS and DHCP



ال Split-brain DNS


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


المواقع الإلكترونية أو الخدمات التي تعيش على الإنترنت قد تنتهي بـ .com، .org، .edu، .biz، .info، .tech، .construction- والقائمة تطول وتطول. هذه تُعرف بالنطاقات العليا، والاستخدام الإبداعي لهذه اللاحقات يجب أن يبقى على الإنترنت وبعيدًا عن مناطق DNS الداخلية لدينا.


الآن، قد يعمل العديد منكم بالفعل في بيئات الشركات حيث يتم تكوين DNS الداخلي كشيء آخر غير .local، لذلك تدركون بالفعل أن النطاقات الداخلية يمكن بالتأكيد تكوينها كواحدة من هذه اللاحقات الأخرى. على سبيل المثال، Microsoft.com هو بالطبع واحد من النطاقات العامة التي تملكها Microsoft، ويمكنهم أيضًا استخدام Microsoft.com كمنطقة DNS داخلية أيضًا. في الواقع، يمكن أن يكون حتى اسم النطاق الأساسي داخل Active Directory الآن، وهذا لن يسبب بالضرورة أي مشاكل، ولكن بالتأكيد يزيد من احتمال المشاكل، أو على الأقل يخلق بيئة DNS أكثر تعقيدًا بشكل عام.


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


مثال على ذلك هو Microsoft DirectAccess، الذي سنتناوله في الفصل 8، الوصول عن بعد. عند نشر DirectAccess، هناك جزء حيوي من تكنولوجيا جانب العميل يسمى Name Resolution Policy Table يجب تعبئته بناءً على بنية DNS الداخلية الخاصة بك. بالنسبة للشركات التي تستخدم نطاق .local داخليًا، يكون هذا التكوين قطعة من الكعكة ولا حاجة لاعتبارات خاصة. بالنسبة لأي شخص لديه split-brain DNS، يتحول هذا أحيانًا إلى فوضى معقدة ولأي شخص غير متمرس في تعقيدات DirectAccess، قد يعني وجود split-brain DNS في بيئتك أنك لن تتمكن أبدًا من جعل DirectAccess يعمل في بيئتك.


للأول وهلة، قد تظن أن الإدارة ستكون أسهل إذا كانت مناطق DNS الداخلية تتطابق مع مناطق DNS العامة، ولكن هذا ببساطة ليس صحيحًا. العكس هو


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


على مدى السنوات القليلة الماضية، رأيت بعض مستندات Microsoft المتعلقة بـ Office 365 التي توصي المسؤولين الذين يقومون بإعداد نطاقات داخلية جديدة بفعل ذلك عن طريق تعمد استخدام split-brain DNS، وتكوين مناطق DNS الداخلية لتطابق DNS العامة الخاصة بهم. على سبيل المثال، قد يوصون بأنه إذا كان نطاقك العام هو contoso.com، فيجب أيضًا إعداد نطاقك الداخلي ليكون contoso.com بدلاً من contoso.local. بعد قراءة هذه المقالات، وبناءً على تجاربي الخاصة، لا أوافق. إعداد split-brain DNS يجعل بعض جوانب إدارة Office 365 والدمج أسهل، ولكن إذا نظرت إلى الصورة الكاملة لتقنية المعلومات، فإنه لا يزال أكثر تعقيدًا بشكل عام. هناك أيضًا خدمة جديدة نوعًا ما تسمى Azure Active Directory Domain Services (AADDS)، وتكوين DNS الداخلي لديك ليكون split-brain يخلق تعقيدات إضافية مع استخدام AADDS في المستقبل.


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


أنواع مناطق DNS


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


مع DNS Server المزود بواسطة Windows Server 2022، يمكنك بالتأكيد بناء العديد من مناطق DNS المختلفة، لزيادة قدرات حل الأسماء في شبكتك. هناك العديد من الأسباب المختلفة التي قد ترغب في إنشاء مناطق DNS إضافية، ويجب أن تفهم ما هي أنواع المناطق المتاحة للتنفيذ. دعونا نأخذ دقيقة ونناقش أنواع المناطق المختلفة المتاحة لنا.


مناطق مدمجة في Active Directory


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


بعد فتح أداة DNS Manager على وحدة تحكم النطاق الخاصة بك، ستلاحظ أن أي مناطق DNS حالية مدرجة تحت المجلدات المسماة Forward Lookup Zones وReverse Lookup Zones. ما الفرق؟


مناطق Forward Lookup Zones


المناطق التي تم تكوينها داخل Forward Lookup Zones هي مناطق DNS التقليدية. وظيفتها هي أخذ طلب DNS وارد، مثلًا من جهاز عميل، وتحويل ذلك الطلب من اسم DNS إلى عنوان IP يتم تسليمه إلى جهاز العميل. Forward Lookup Zones هي تقريبًا دائمًا حيث يعمل مسؤولو DNS.


مناطق Reverse Lookup Zones


إذا كان "العكس" هو عكس "الأمام"، فإن نفس الشيء يجب أن يكون صحيحًا داخل سياق DNS. مناطق Reverse Lookup Zones مسؤولة عن تعيين عناوين IP إلى أسماء. قد لا تدرك حتى أن هذه تحدث في بيئتك، ولكن يمكنك اختبارها بسهولة في أي وقت. ربما تعرف جميعًا كيفية استخدام أمر ping، الذي يعتمد على DNS لتحويل الاسم إلى عنوان IP. هذا، بالطبع، يتم التعامل معه بواسطة Forward Lookup Zone، كما نرى هنا:


هل تعلم أنه يمكنك أيضًا استخدام أمر ping للقيام بالعكس؟ ماذا إذا كنت تريد استعلام DNS لمعرفة ما هو اسم المضيف الذي يعينه عنوان IP 10.10.10.11؟


هذا البحث العكسي، تحويل عناوين IP إلى أسماء، أظهر لنا أن عنوان IP 10.10.10.11 لديه سجل مؤشر عكسي يعيد التعيين إلى خادم DC2 لدينا. هذا النوع من البحث يتم التعامل معه بواسطة Reverse Lookup Zone داخل DNS.


الآن بعد أن فهمنا الفرق بين Forward وReverse Lookup Zones، النقر بزر الماوس الأيمن على Forward Lookup Zones واختيار "منطقة جديدة..." يهبط بنا بثلاثة خيارات حول نوع المنطقة التي نود إنشائها:


المنطقة الأساسية (Primary Zone)


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


المنطقة الثانوية (Secondary Zone)


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


داخل معظم الشبكات التي عملت معها والتي تعتمد على بنية Microsoft التحتية، يتم إعداد جميع المناطق الأساسية لتكون مدمجة في Active Directory، مما يعني أنها تقوم بالمزامنة مع جميع خوادم DNS المستندة إلى وحدات التحكم في النطاقات (domain controllers) على أي حال. في هذه الحالة، يكون من غير المرجح الحاجة إلى المناطق الثانوية. إذا ابتعدت عن هذه العقلية وأنشأت خوادم DNS ليست وحدات تحكم في النطاقات (وهو أمر يمكنك القيام به تمامًا) - فقد ترغب في فهم حالات استخدام المناطق الثانوية لأن الاحتمال الأكبر هو أنك ستستخدمها في هذا السيناريو.


منطقة Stub


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


تتيح مناطق Stub لخوادم DNS معرفة كيفية توجيه حركة المرور لحل السجلات داخل نطاق آخر. يبدو ذلك تمامًا مثل conditional forwarder الذي تعلمنا عنه في الفصل السابق، أليس كذلك؟ نعم، لكن كما تعلم، قمنا بتوجيه conditional forwarder إلى عنوان IP محدد، مما يخبر DNS بأن الطلبات الخاصة بالنطاق البعيد يجب أن توجه دائمًا إلى خادم معين أو خوادم معينة. تحتوي مناطق Stub على سجلات NS للنطاق البعيد، لذا حتى إذا قام ذلك النطاق البعيد ببعض التعديلات الداخلية وتغيرت خوادم DNS الخاصة به أو تم تحديثها، يمكن لمناطق Stub التعامل بشكل أكثر دقة مع تلك السيناريوهات.


تقوم مناطق DNS المدمجة في Active Directory بالمزامنة بين وحدات التحكم في النطاقات باستخدام المزامنة الخاصة بالنطاق، لكن مناطق DNS غير المدمجة في Active Directory يجب أن تقوم بالمزامنة باستخدام عملية خاصة بها تُعرف بعمليات نقل المنطقة (zone transfers). يمكن استخدام مناطق Stub للمساعدة في جعل عملية نقل المنطقة أكثر كفاءة وخلق حل أسرع للأسماء لأجهزة الكمبيوتر العميلة.


إنشاء منطقة جديدة


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


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


داخل DNS Manager، انقر بزر الماوس الأيمن على Forward Lookup Zones واختر New Zone.... الآن حدد الخيارات لإنشاء منطقة أساسية جديدة، وسأختار تخزينها في Active Directory. راجع الشكل 4.10 إذا كنت بحاجة إلى نقطة مرجعية لهذه الخيارات.


الآن نصادف شاشة بعنوان Active Directory Zone Replication Scope. هذه الشاشة والخيارات تظهر فقط عند تحديد خيار Store inside AD، وإلا فإن المعالج كان سيتجاوز هذه الشاشة. هنا لديك خيارات لكيفية توزيع هذه المنطقة الجديدة بين وحدات التحكم في النطاقات الخاصة بك. يمكنك توزيعها على جميع وحدات التحكم في النطاقات داخل النطاق، أو حتى كامل الغابة.


بعد ذلك، قم بتسمية المنطقة. الاسم الذي تقدمه للمنطقة هنا هو النطاق الذي ستحتوي المنطقة على سجلاته. الإمكانيات هنا لا حصر لها، يمكنني حتى كتابة Jordan.local كنطاق DNS الخاص بي، أو Jordan.com. هذا في الواقع موقع حقيقي يعيد التوجيه إلى Nike.com، وهو أمر عادل لأن مايكل جوردان أكثر شهرة مني بقليل.


لقد كتبت Jordan.com لمجرد المزاح، ولكنه سيعرض بالضبط ما كنت أود أن أريكم إياه، لذا دعونا نلتزم به. هذا ربما يكون أحمق شيء قمت به داخل DNS Manager.


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



هذا سلوك طبيعي تمامًا، أليس كذلك؟ كتابة عنوان URL لموقع ويب، وهو اسم DNS؛ DNS يحله إلى عنوان IP الذي يستضيف الموقع، ومتصفحك يأخذك هناك. بعد ذلك، أكمل إنشاء منطقة DNS داخلية جديدة باسم Jordan.com على خادم DNS الداخلي الخاص بنا.


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


هذا كل شيء! الشاشة النهائية للمعالج هي مجرد مراجعة للإعدادات، وبعد النقر على Finish، تصبح منطقة DNS الجديدة الخاصة بك متاحة على الفور وتعمل على حل الأسماء في نطاق Jordan.com الجديد، لأي أجهزة كمبيوتر عميلة تستخدم هذا الخادم كخادم DNS. كما ترى في الشكل 4.13، تم الآن إدراج منطقة Jordan.com في DNS Manager، وقد أنشأت سجلات A لكي تعيد أي طلبات إلى Jordan.com أو www.Jordan.com إلى عنوان IP 10.10.10.23. (هل رأيت ماذا فعلت هنا؟ الرقم 23؟).


الآن بعد أن تم إنشاء منطقتنا الجديدة داخل الشبكة، ماذا تغير؟ دعنا نعود إلى جهاز الكمبيوتر العميل في شبكتي الاختبارية، ونحاول التصفح وإجراء ping مرة أخرى إلى Jordan.com:


قبل إنشاء هذه المنطقة الجديدة، كان يتم تحويل طلب العميل لـ Jordan.com ببساطة إلى خوادم DNS العامة على الإنترنت، لأن خوادم DNS الداخلية الخاصة بنا لم يكن لديها أي تعريفات خاصة بها لما يجب فعله مع طلبات Jordan.com. بعد إنشاء منطقة DNS داخلية لـ Jordan.com، قمنا الآن بمقاطعة الوصول إلى الموقع، لأن خادم DNS الخاص بنا لديه الآن قواعده الخاصة لما يجب فعله مع هذه الطلبات! إذا قمت ببناء موقع ويب خاص بي على خادم ويب وأعطيته عنوان IP 10.10.10.23، فإن جهاز الكمبيوتر العميل الخاص بي كان سيفتح موقعي المخصص عند كتابة Jordan.com في المتصفح الخاص بهم.


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



النهاية


نكون هنا انتهينا من الجزء 2 من الفصل 4 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق


و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها 


واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا  


او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله 


ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من     هنا 


يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من  

هنا


وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما


Tags

إرسال تعليق

0تعليقات

إرسال تعليق (0)

#buttons=(موافق!) #days=(20)

يستخدم موقعنا ملفات تعريف الارتباط لتحسين تجربتك. تاكد الان
Ok, Go it!