الفصل : 4
الجزء : 1
العنوان : ال DNS and DHCP
إذا اعتبرنا أن خدمات Active Directory Domain Services (AD DS) هي الأكثر شيوعًا ومحورية في جعل شبكاتنا المعتمدة على Microsoft تعمل بشكل فعال، فإن أدوار DNS وDHCP تحتل المرتبتين الثانية والثالثة. لم ألتق بعد بمسؤول نظم اختار نشر دومين جديد دون نشر DNS في نفس الوقت، وكل شبكة تحتاج إلى DHCP سواء كان يتم تقديم تلك الخدمة بواسطة سيرفر Windows أم لا. يمكن تقديم أي من هذه الأدوار بواسطة شيء آخر غير السيرفر التقليدي. هناك شركات وأجهزة مخصصة لتوفير DNS داخل الشبكات التجارية، ولها بعض المزايا وبعض العيوب. فيما يتعلق بـ DHCP، هناك الكثير من الخيارات لتقديم تلك الخدمة خارج عالم Windows، حيث أن معظم الجدران النارية وحتى السويتشات يمكنها أن تكون أيضًا "سيرفرات" DHCP في الشبكة.
على الرغم من صحة الجمل السابقة، في الواقع، يتم توفير غالبية خدمات DNS وDHCP الداخلية للشركات في جميع أنحاء العالم بواسطة سيرفرات Windows، وهذه الأدوار تكون موجودة بشكل شائع بجانب AD DS على الأقل في بعض سيرفرات Domain Controller (DC) في أي شبكة معينة.
في هذا الفصل، سنغطي كل من DNS وDHCP المقدمين بواسطة Windows Server 2022، سنتعرف على أغراضهما وسنستعرض بعض المصطلحات والمهام الشائعة المتعلقة بهذه الأدوار. في هذا الفصل، سنغطي ما يلي:
- غرض DNS
- أنواع سجلات DNS
-ال Split-brain DNS
- أنواع مناطق DNS
- تخصيص IP مع DHCP
- إنشاء نطاق DHCP
- ال DHCP reservations
- التبديل الاحتياطي DHCP
- إدارة IP (IPAM)
غرض DNS
نظام أسماء النطاقات Domain Name System (DNS) يشبه إلى حد ما Active Directory في كونه قاعدة بيانات منظمة غالبًا ما يتم تخزينها على سيرفرات Domain Controller ويتم توزيعها تلقائيًا حول شبكتك إلى سيرفرات Domain Controller/DNS الأخرى. حيث تحتوي قاعدة بيانات AD على معلومات حول كائنات الدومين نفسها، يكون DNS مسؤولًا عن تخزين وحل جميع الأسماء في شبكتك. ماذا أعني بالأسماء؟ في أي وقت يحاول فيه المستخدم أو الكمبيوتر الاتصال بأي مورد عن طريق طلب اسم، يكون DNS هو النظام المسؤول عن تحويل ذلك الاسم إلى شيء آخر للوصول بالترافيك إلى الوجهة الصحيحة. كما ترى، الطريقة التي ينتقل بها الترافيك من العميل إلى السيرفر هي عبر الشبكة، وعادةً عبر مكدس TCP/IP، باستخدام عنوان IP للوصول إلى وجهته.
عندما أفتح تطبيقًا على جهاز الكمبيوتر الخاص بي للوصول إلى بعض البيانات الموجودة على سيرفر، يمكنني تكوين التطبيق بحيث يتواصل مباشرة مع السيرفر باستخدام عنوان IP الخاص بالسيرفر على الشبكة. إذا كان تطبيق على جهاز الكمبيوتر الخاص بي يحتاج إلى التواصل مع سيرفر يسمى APP01، وكان ذلك السيرفر يستخدم عنوان IP 10.10.10.15 على الشبكة، يمكنني إدخال 10.10.10.15 في تكوين التطبيق، وسيفتح بنجاح. إذا قمت بإعداد مئات من أجهزة الكمبيوتر المختلفة بهذه الطريقة، جميعها تشير إلى عناوين IP، سيعمل ذلك بشكل جيد لفترة. لكن سيأتي اليوم الذي، لأي سبب كان، قد يحتاج فيه عنوان IP هذا إلى التغيير. أو ربما أضيف سيرفرًا ثانيًا لتقاسم العبء والتعامل مع زيادة حركة المستخدمين. ماذا نفعل الآن؟ هل نزور كل جهاز كمبيوتر عميل ونحدث عنوان IP المستخدم؟ بالطبع لا.
هذا هو أحد الأسباب التي تجعل DNS حيويًا للطريقة التي نصمم بها وندير بها بنانا التحتية. باستخدام DNS، يمكننا استخدام الأسماء بدلاً من عناوين IP. مع DNS، يمكن تكوين تطبيقي للتحدث إلى APP01 أو أيًا كان اسم السيرفر الخاص بي، وإذا احتجت إلى تغيير عنوان IP لاحقًا، ببساطة أغيره داخل وحدة التحكم DNS إلى عنوان IP المحدث وسيبدأ جميع أجهزة الكمبيوتر العميلة على الفور في حل اسم APP01 إلى عنوان IP الجديد. أو يمكنني حتى استخدام اسم أكثر عمومية، مثل intranet، وجعله يحل عبر عدة سيرفرات مختلفة. سنتحدث عن ذلك قليلاً لاحقًا.
في أي وقت يقوم فيه جهاز الكمبيوتر بإجراء مكالمة إلى سيرفر أو خدمة أو موقع ويب، فإنه يستخدم DNS لحل ذلك الاسم إلى جزء أكثر فائدة من المعلومات لجعل اتصال الشبكة يحدث بنجاح. نفس الشيء صحيح داخل وخارج الشبكات التجارية. على جهاز اللابتوب الشخصي الخاص بي الآن، إذا فتحت متصفح Edge وتصفحت https://www.bing.com/، فإن سيرفر DNS لمزود الإنترنت الخاص بي يحل bing.com إلى عنوان IP على الإنترنت، وهو العنوان الذي يتواصل معه اللابتوب الخاص بي وبالتالي تفتح تلك الصفحة بنجاح. عندما نعمل داخل شبكاتنا التجارية، لا نريد الاعتماد على أو الثقة في مزود عام مع معلومات اسم السيرفر الداخلية لدينا، لذلك نبني سيرفرات DNS الخاصة بنا داخل الشبكة. نظرًا لأن سجلات DNS داخل شبكة الدومين تحل الأسماء إلى الكائنات التي توجد داخل Active Directory تقريبًا دائمًا، فمن المنطقي أن يكون DNS وAD DS متكاملين بشكل وثيق. وهذا صحيح في غالبية شبكات Microsoft، حيث إنه من الشائع جدًا تثبيت كل من دور AD DS بالإضافة إلى دور DNS على سيرفرات Domain Controller الخاصة بك.
أنواع سجلات (records) لل DNS
بعد تثبيت دور DNS على سيرفر في الشبكة، يمكننا البدء في استخدامه لإنشاء سجلات DNS، التي تحل الأسماء إلى عناوين IP المقابلة لها، أو غيرها من المعلومات اللازمة لتوجيه الترافيك في الشبكة.
إذا كنت تعمل في شبكة دومين، قد تكون مندهشاً عندما ترى عدداً من السجلات موجودة بالفعل داخل DNS، على الرغم من أنك لم تقم بإنشائها. عندما تقوم بتشغيل Active Directory وDNS معاً، فإن عملية الانضمام إلى الدومين التي تقوم بها مع أجهزتك وخوادمك تقوم بتسجيل سجل DNS تلقائياً خلال تلك العملية، مما يعني أن إنشاء سجل DNS لكل خادم أو جهاز جديد ليس شيئاً تحتاج إلى تذكره. لم أنشئ بعد أي سجلات DNS في بيئة المختبر الجديدة الخاصة بي، ليس عمداً على أي حال، ومع ذلك عندما أفتح وحدة تحكم DNS Manager من داخل قائمة Tools في Server Manager، أستطيع رؤية بعض السجلات الموجودة بالفعل. هذا لأنني عندما انضممت بهذه الأجهزة إلى الدومين، تم تسجيل هذه السجلات تلقائياً لكي تكون الخوادم والعملاء الجدد قابلة للحل فوراً داخل دوميننا.
ال Host record (A or AAAA)
أول نوع من سجلات DNS الذي ننظر إليه هو النوع الأكثر شيوعاً الذي ستعمل معه. سجل المضيف (Host record) هو الذي يحل اسم معين إلى عنوان IP معين. إنه بسيط جداً، ولأغلب الأجهزة على شبكتك سيكون هذا النوع الوحيد من السجلات الذي يوجد لها داخل DNS. هناك نوعان مختلفان من سجلات المضيف التي يجب أن تكون على دراية بها، على الرغم من أنك ستستخدم على الأرجح واحداً فقط منها لعدة سنوات قادمة. النوعان المختلفان من سجلات المضيف يطلق عليهما A record وAAAA record، والذي يُنطق Quad A.
ما الفرق بين الاثنين؟ سجلات A هي لعناوين IPv4 وستستخدم في معظم الشركات لسنوات قادمة. سجلات AAAA تخدم نفس الغرض تماماً وهو حل اسم إلى عنوان IP، ولكنها فقط لعناوين IPv6، ولن تكون مفيدة إلا إذا كنت تستخدم IPv6 في شبكتك. في الشكل 4.1، يمكنك رؤية بعض سجلات Host (A) التي تم إنشاؤها تلقائياً عندما انضمت تلك الأجهزة إلى دوميننا. لدي أيضاً خادم آخر يعمل على شبكتي لم ينضم بعد إلى الدومين، وبالتالي لم يسجل نفسه تلقائياً في DNS. هذا الخادم يُدعى RA1، ولكن إذا قمت بتسجيل الدخول إلى أي نظام آخر على شبكتي، أفشل في الاتصال بخادم RA1 الخاص بي، لأن هذا الاسم لم يتم إدخاله بعد في DNS.
في الوقت الحالي، سأختار عدم انضمام هذا الخادم إلى الدومين، حتى نتمكن من إنشاء سجل DNS يدوياً له والتأكد من أنني أستطيع حل الاسم بشكل صحيح بعد القيام بذلك. داخل DNS Manager على خادم DNS الخاص بك، انقر بزر الماوس الأيمن على اسم الدومين الخاص بك المدرج تحت مجلد Forward Lookup Zones، ثم اختر New Host (A or AAAA). داخل الشاشة لإنشاء سجل مضيف جديد، أدخل ببساطة اسم الخادم الخاص بك وعنوان IP الذي تم تكوينه على واجهته الشبكية.
الآن بعد أن أنشأنا هذا السجل الجديد للمضيف، ينبغي أن نتمكن فوراً من بدء حل هذا الاسم داخل شبكة الدومين الخاصة بنا. العودة إلى جهاز العميل الذي كنت أحاول فيه الاتصال بـRA1 سابقاً، سأحاول نفس الأمر مرة أخرى، وهذه المرة يتم الحل والرد بنجاح.
ال Alias record – CNAME
نوع آخر مفيد من سجلات DNS هو CNAME، الذي يسمى بشكل أكثر شيوعًا في هذه الأيام سجل الاسم المستعار alias record. هذا سجل يمكنك إنشاؤه يأخذ اسمًا ويشير به إلى اسم آخر. قد يبدو ذلك سخيفًا للوهلة الأولى، لأنه في النهاية ستظل بحاجة إلى حل اسمك النهائي إلى عنوان IP باستخدام سجل المضيف للحصول على الترافيك إلى حيث يحتاج للذهاب، ولكن أغراض سجل الاسم المستعار يمكن أن تكون واسعة. مثال جيد على إبراز فائدة سجل الاسم المستعار هو عندما تقوم بتشغيل سيرفر ويب يقدم مواقع ويب داخل شبكتك. بدلاً من إجبار جميع المستخدمين على تذكر عنوان URL مثل http://web1.contoso.local للوصول إلى موقع ويب، يمكننا إنشاء سجل اسم مستعار يسمى intranet، ونشير به إلى WEB1. بهذه الطريقة، يمكن دائمًا استخدام سجل intranet الأكثر عمومية بواسطة أجهزة الكمبيوتر العميلة، وهو اسم أكثر ودية للمستخدمين لتذكره.
بالإضافة إلى إنشاء تجربة مستخدم أسعد بهذا السجل الجديد لـ DNS، فقد قمت في نفس الوقت بإنشاء بعض المرونة الإدارية الإضافية لأنك يمكن بسهولة تغيير مكونات السيرفر التي تعمل تحت ذلك السجل، دون الحاجة إلى ضبط أي إعدادات على أجهزة الكمبيوتر العميلة أو إعادة تدريب الموظفين على كيفية الوصول إلى الصفحة. تحتاج إلى استبدال سيرفر ويب؟ لا مشكلة، فقط جهز السيرفر الجديد بجانب القديم ثم أشر سجل الاسم المستعار إلى السيرفر الجديد. تحتاج إلى إضافة سيرفر ويب آخر؟ هذا سهل أيضًا، حيث يمكننا إنشاء سجلات اسم مستعار متعددة، جميعها بنفس اسم intranet، ونشير بها إلى السيرفرات المختلفة التي تلعب دورًا داخل البيئة. هذا يخلق شكلًا بسيطًا جدًا من توازن الحمل، حيث سيبدأ DNS في توزيع الترافيك بين سيرفرات الويب المختلفة، بناءً على سجل CNAME الخاص بـ intranet.
في الواقع، بدلاً من الاستمرار في الحديث عن هذا، دعنا نجربه. لدي موقع ويب يعمل على عنوان URL بالضبط في بيئتي، ولكن حاليًا يمكنني الوصول إليه فقط عن طريق كتابة http://web1.contoso.local. داخل DNS، سأقوم بإنشاء سجل اسم مستعار يعيد توجيه intranet إلى WEB1.
الآن عندما أقوم بالاتصال بـ intranet، يمكنك رؤية أنه يحل إلى خادم WEB1 الخاص بي. وعند الوصول إلى صفحة الويب، يمكنني ببساطة كتابة كلمة intranet في شريط العنوان داخل متصفح الويب الخاص بي للوصول إلى الصفحة. الموقع نفسه ليس على علم بتغيير الاسم الذي تم، لذا لم أكن بحاجة إلى إجراء أي تعديلات على الموقع، فقط داخل DNS.
سجل تبادل البريد (Mail Exchanger (MX) record)
النوع الثالث من سجلات DNS يسمى سجل تبادل البريد (MX record). في مهامك اليومية، لن تحتاج إلى التعامل أو تكوين سجلات MX بنفس التكرار مثل سجلات A أو CNAME، ولكنها مهمة لفهمها على أي حال. سجل MX يتعلق بخدمات البريد الإلكتروني والتسليم. أي اسم مجال يتبع @ في عنوان بريدك الإلكتروني، يجب أن يحتوي خادم DNS الذي يدير ذلك النطاق على سجل MX يوضح إلى أين يتم توجيه البريد الإلكتروني لهذا النطاق. سجلات MX تستخدم غالباً ضمن DNS العام، لعمليات حل الأسماء التي تحدث عبر الإنترنت. بالنسبة للشركات التي تستضيف بريدها الإلكتروني على خوادم Exchange المحلية، سيحتوي DNS العام على سجل MX يشير إلى بيئة Exchange الخاصة بهم. بالنسبة للشركات التي تستضيف بريدها الإلكتروني في خدمة سحابية مثل Office 365، يجب أن تحتوي سجلات DNS العامة على سجل MX يوجه حركة البريد الإلكتروني نحو مزود السحابة الذي يستضيف صناديق البريد.
عند إرسال بريد إلكتروني للخارج، يحتاج الإنترنت لتحديد كيفية تسليم ذلك البريد الإلكتروني. يتم التحقق من DNS العام للنطاق الذي يُرسل إليه البريد الإلكتروني، ويحدد سجل MX الموجود ضمن إعدادات DNS أين يتم إرسال البريد. إذا لم يكن لديك سجل MX، أو إذا اختفى لسبب ما، فلن تتلقى أي رسائل بريد إلكتروني إلى نطاقك. هذا مهم لفهمه لأغراض استكشاف مشكلات تسليم البريد الإلكتروني. كيف يمكن أن يختفي سجل MX؟ عادةً أثناء تغييرات موقع الويب. عندما تقرر شركة الانتقال إلى موقع ويب جديد، يكون مطور الموقع عادةً هو الذي يقوم بإجراء تلك التغييرات. كجزء من هذه التغييرات، يحتاجون إلى الوصول إلى DNS ليتمكنوا من توجيه اسم موقع شركتك إلى عنوان IP الجديد الذي يتم استخدامه لاستضافة الموقع، وإذا تم اختيار الخيارات الخاطئة أثناء الانتقال، فقد يصبح سجل MX غير موجود في العملية. إذا واجهت أي مشكلات في تسليم البريد الإلكتروني بعد تغييرات في DNS، فمن المرجح أن هناك مشكلة في سجل MX.
سجلات MX في Microsoft 365
الآن بعد أن أصبحت العديد من الشركات تستضيف بريدها الإلكتروني على منصة Office 365 من Microsoft، دعونا نلقي نظرة مباشرة على سجل MX الذي يشير إلى هذا النظام. حتى مع أن ملايين صناديق البريد عبر آلاف الشركات تستضيف بريدها الإلكتروني في نفس Office 365، فإن كل شركة سيكون لديها سجل MX فريد يرتبط ببيئة Office 365 الخاصة بها. العثور على معايير سجل MX الخاصة بك بسيط جداً، فقط تحتاج إلى معرفة المكان الذي تبحث فيه.
قم بتسجيل الدخول إلى بوابة الإدارة في Microsoft 365، وانتقل إلى الإعدادات > النطاقات. هنا، سترى جميع أسماء النطاقات التي قمت بتكوينها داخل البوابة. انقر على اسم النطاق المعني، ثم انقر على سجلات DNS. هنا، سترى جميع سجلات DNS التي يجب أن تكون موجودة لدى مزود DNS العام الخاص بشركتك لضمان عمل خدمات Microsoft 365 بنجاح. الأهم لتسليم البريد الإلكتروني هو سجل MX، المدرج في الأعلى، ولكن جميع السجلات الثلاثة تحت عنوان Microsoft Exchange هي مهمة جداً.
سجل MX الخاص بك سيشبه على الأرجح ما يلي:
بمجرد التأكد من إنشاء هذا السجل بنجاح في سجلات DNS العامة لنطاقك، يعرف الإنترنت الآن أن أي بريد إلكتروني موجه إلى عنوان ينتهي بـ @contoso.com يجب أن يتم تسليمه إلى خدمات استضافة Microsoft 365، وMicrosoft تتولى توصيله إلى الشركة وصندوق البريد المناسبين.
سجل TXT
سجل TXT هو اختصار لسجل النص (Text). تستخدم سجلات TXT داخل DNS لأغراض متنوعة، ويمكن أن تحتوي على أي نوع من المعلومات تقريباً. أحياناً توضع سجلات TXT لقراءة نوع معين من المعلومات من قبل البشر، ولكن من المرجح أن يُطلب منك إنشاء سجل TXT في مرحلة ما كنوع من التحقق.
على سبيل المثال، معظم المواقع محمية بشهادات SSL، وعملية شراء شهادة SSL هي عملية مباشرة. ومع ذلك، بالطبع لن ترغب في أن يتمكن أي شخص يمتلك جهاز كمبيوتر محمول واتصال بالإنترنت من شراء شهادة يمكنها حماية اسم موقع ينتهي بنطاق تملكه شركتك، أليس كذلك؟ لذلك، تتطلب جهات التصديق (CAs) (الأماكن التي تشتري منها شهادات SSL) نوعاً من عملية التحقق قبل السماح لك بشراء شهادة لاسم نطاقك.
أحياناً تكون عملية التحقق ببساطة إرسال بريد إلكتروني إلى عنوان مرتبط بذلك النطاق، أو أحياناً سيُطلب منك إنشاء سجل TXT بمجموعة معينة من الأحرف في سجلات DNS العامة الخاصة بك. المفهوم والتحقق هنا هو أنه إذا كنت تملك حقاً ذلك النطاق، فستتمكن من إنشاء سجلات DNS داخل ذلك النطاق. عندما ترى جهة التصديق السجل TXT الذي أنشأته حديثاً ويحتوي على البيانات التي طلبوا منك إدخالها، يعرفون أنك تملك ذلك النطاق حقاً، ومن ثم سيصدرون شهادتك الجديدة. مهاجم يحاول انتحال موقعك الإلكتروني والحصول على شهادة SSL بشكل خبيث لن يكون لديه مثل هذا الوصول إلى إعدادات DNS لنطاقك.
سجل SPF
هناك بعض الأنواع الخاصة من سجلات TXT، أحدها الشائع هو سجل إطار سياسة المرسل Sender Policy Framework (SPF) . يتعلق هذا السجل بتسليم البريد الإلكتروني، ولكن بينما يحدد سجل MX الخوادم التي يجب أن يتدفق البريد الإلكتروني إليها، يحدد سجل SPF الأماكن التي يأتي منها البريد الإلكتروني. تستخدم سجلات SPF كجزء من حسابات البريد المزعج والانتحال، لتحديد الأماكن على الإنترنت التي من المتوقع أن يتدفق البريد الإلكتروني من نطاقك منها. دعونا نلقي نظرة على بعض سجلات SPF كمثال، والتي ستساعدك على فهم كيفية تنسيقها، وأيضاً المساعدة في وصف سبب ضرورتها:
التنسيق السابق هو تنسيق قياسي لسجل SPF TXT. بالنسبة لأنظمة البريد الإلكتروني البسيطة حيث يتدفق كل البريد الإلكتروني من عنوان IP عام واحد على الإنترنت، أو من نظام بريد إلكتروني مستضاف واحد، سيكون سجلك قصيراً وجميلاً. مثال رائع هو البريد الإلكتروني القادم من Office 365. يجب أن يحتوي كل من يستضيف البريد الإلكتروني في Office 365 على سجل SPF بالمعلومات التالية:
تستخدم معلومات سجل SPF من قبل خوادم البريد المستقبلة للتحقق من البريد القادم. ستستقبل خادم البريد الإلكتروني البريد، وتكتشف النطاق الذي أتى منه، وتتحقق من وجود سجل SPF لدى خوادم DNS لذلك النطاق. إذا لم تجد مثل هذا السجل، فإن بريدك الإلكتروني لديه فرصة أكبر لأن يتم وضع علامة عليه كبريد مزعج. إذا وجدت سجلاً لـ SPF، فإن خادم البريد يتحقق من الإدخالات في ذلك السجل، والتي تحدد الأماكن الآمنة التي نتوقع أن يتدفق منها البريد، وتأكد من أن البريد جاء بالفعل من أحد تلك الأماكن.
في سجل SPF الخاص بـ Office 365 السابق، قمنا بتضمين النطاق spf.protection.outlook.com. كل البريد الإلكتروني الذي يتدفق من خوادم Office 365 سيتطابق مع هذا المصدر، لذا فإن هذا السجل البسيط هو الشيء الوحيد الذي يجب أن يكون موجوداً لضمان تسليم البريد الإلكتروني بأمان من مستأجر Office 365 الخاص بك.
الآن تخيل أن سجل SPF الخاص بك موجود بالفعل ويعمل مع بريدك الإلكتروني المستضاف، ولكنك قمت بإعداد خادم SMTP محلي حتى تتمكن الطابعات متعددة الوظائف من إرسال البريد الإلكتروني. هذا طلب شائع من قبل الشركات، وشيء أجده في الحياة العملية بشكل منتظم. لا يهم كثيراً نوع خادم SMTP الذي لديك؛ هناك طرق مختلفة لتحقيق ذلك. ما ستجده عادةً، على الرغم من ذلك، هو أنه عند إرسال بريد إلكتروني من طابعتك، قد يبدأ هذا البريد في الحصول على علامة كبريد مزعج. أحياناً يصل إلى مجلد البريد غير الهام لدى المستلم، وأحياناً يتم التقاطه وعدم تسليمه على الإطلاق. لماذا يحدث هذا؟ إذا كان لديك خادم SMTP محلي حيث يأتي البريد الإلكتروني، تذكر أن الطابعة تقوم فقط بتسليم البريد إلى خادم SMTP، وذلك الخادم هو الذي ينقل البريد عبر الإنترنت.
هذا البريد المحول لا يأتي من spf.protection.outlook.com، ولكن البريد الإلكتروني المرسل من خادم SMTP المحلي الخاص بك يأتي من عنوان IP العام الخاص بمزود خدمة الإنترنت (ISP) الخاص بك. يحتاج سجل SPF الخاص بك إلى تعديل لتضمين هذا المرسل الآمن الإضافي، حتى يعرف مستلمو بريدك الإلكتروني أن البريد الإلكتروني القادم من مبناك الفعلي هو مشروع. دعونا نبني سجلاً لـ SPF يتضمن عنوان IP واحد:
`
هذا كل شيء! عن طريق تحديث سجل SPF الخاص بك لتضمين عنوان IP العام الذي تأتي منه عمليات المسح للطابعة، ستثق خوادم البريد الإلكتروني المستقبلة بشكل أفضل في البريد الوارد.
أنا أستخدم 8.8.8.8 كمثال في النص السابق؛ لا تقم بإدخال هذا في سجلات SPF الخاصة بك! سترغب في تحديد عنوان IP الخارجي الفعلي الخاص بك واستخدام تلك المعلومات بدلاً من ذلك. من السهل أيضاً إضافة عدة عناوين IP إذا لزم الأمر:
الشيء الآخر الذي يستحق الذكر هنا هو الـ "قواعد التنفيذ". في النهاية، لكل سجل SPF، ترى "-all". هذه هي القاعدة التي تُستخدم إذا لم يتطابق البريد الإلكتروني المرسل مع أي من القيم الآمنة في السجل. قواعد التنفيذ المتاحة لديك هي كما يلي:
ال -all يعني أنه إذا لم يتطابق البريد الإلكتروني مع أي من المضيفين الآمنين المدرجين في سجل SPF، يجب أن تفترض أن هذا البريد الإلكتروني هو بريد مزعج.
ال~all يعني أن البريد الإلكتروني لا يطابق، ولكن لا تحظر البريد بناءً على تلك النتيجة.
ال+all يعني السماح بكل البريد الإلكتروني.
أستخدم دائمًا قاعدة -all (رفض) للرسائل التي لا تتطابق مع الأماكن الآمنة المدرجة. إذا كان هناك شيء لم تقم بإدخاله بشكل صحيح، فمن الأفضل أن تعرفه على الفور وتقوم بإصلاحه. بدلاً من ذلك، إذا اخترت +all (السماح) لكل البريد الإلكتروني، فستتجاوز فقط ما تحاول تحقيقه بسجلات SPF في المقام الأول.
ال Name Server (NS) record
هنا نوع آخر من سجلات DNS التي لا تحتاج للتعامل معها يوميًا، ولكن يجب أن تعرف لماذا هو موجود. سجل NS هو معرف داخل منطقة DNS يحدد الخوادم (DNS servers) التي يجب استخدامها كسلطات لتلك المنطقة. إذا نظرت إلى سجلات NS المدرجة في DNS الداخلي لديك الآن، ستلاحظ أنها تذكر أسماء خوادم DNS الموجودة في الشبكة. عند إضافة خادم DC/DNS جديد إلى النطاق الخاص بك، سيتم تلقائيًا إضافة سجل NS جديد لهذا الخادم في منطقة DNS الخاصة بك.
ال Public name server records
سجلات NS حيوية لفهم كيفية العمل مع سجلات DNS العامة/الإنترنت. لا أستطيع أن أخبرك كم مرة ساعدت فيها المسؤولين الذين كانوا يحاولون إنشاء سجلات DNS جديدة لمنطقتهم ويواجهون صعوبة لأن سجلاتهم الجديدة لا تظهر وتعمل على الإنترنت. بعد نظرة سريعة، نكتشف أن سجل خادم الأسماء للنطاق كان يشير إلى خادم أو خدمة مختلفة تمامًا، والتي لم يدركوا حتى أنها جزء من معادلة DNS. إليك مثالًا يوضح ذلك.
تتولى إدارة بنية تحتية قائمة بالفعل حيث تتولى إدارة الخوادم لشركة ما. لدى المدير السابق جميع كلمات المرور موثقة؛ الأمور تبدو جيدة حتى الآن. يأتي مدير التسويق في الشركة إليك في اليوم الثاني لإعلامك أنه بدلاً من التنقل في قنوات الشراء المناسبة لتقنية المعلومات، قاموا فقط بالتسجيل لخدمة تسويقية معينة باستخدام بطاقة ائتمان الشركة، وهذه الشركة التسويقية تتطلب إنشاء سجلات CNAME في DNS العام الخاص بك لكي يتمكن بريدك الإلكتروني وأنظمتهم من العمل معًا. الآن الأمر متروك لك لوضع هذه السجلات CNAME في مكانها.
لا توجد مشكلة، أليس كذلك؟ تراجع وثيقة كلمات المرور وتجد سجلًا يحمل اسم DNS يحتوي على بيانات الدخول لـ GoDaddy. يبدو أنه الصفقة الكبرى، ويبدو منطقياً لأن GoDaddy هو منصة شائعة على الإنترنت لإدارة مناطق DNS. تسجل الدخول إلى GoDaddy، تعدل منطقة DNS لنطاقك، وتضيف سجلات CNAME الجديدة. السجلات CNAME لا تعمل حتى الآن، لكنك تعرف أن نشر DNS يستغرق وقتًا ليصل إلى جميع أنحاء الإنترنت، لذا تخبر السيد تسويق أن الخدمة الجديدة يجب أن تكون قيد التشغيل خلال 24 ساعة. أنت بطل!
لكن... بعد 24 ساعة، وما زالت لا تعمل. السيد تسويق يبدأ بالضغط، وأنت تدرك أن المكافأة الفصلية قد لا تكون مضمونة. لسوء الحظ، نسيت قطعة حيوية من اللغز. على الرغم من أنك تملك حسابًا في GoDaddy، وتم تسميته DNS، وكنت قادرًا على إنشاء سجلات DNS جديدة داخل هذا الحساب، فمن الممكن تمامًا أن المسجل لنطاقك يشير في الواقع إلى خدمة DNS مختلفة تمامًا!
أداة مفيدة في هذا السيناريو هي أداة DNS Lookup من MXToolbox.com. بحث سريع على الإنترنت سيجد لك الرابط الحالي، ببساطة اكتب اسم نطاقك في أداة DNS Lookup، وستعيد إليك الخوادم المسؤولة الحالية، وأي خدمة هي التي تستضيف سجلات DNS الخاصة بك على الإنترنت.
باتباع الإجراء السابق، تكتشف أن سجلات خادم الأسماء لنطاقك تشير في الواقع إلى Network Solutions، وليس إلى GoDaddy على الإطلاق! كما اتضح، فإن سلفك في تقنية المعلومات لم يكن متأكدًا تمامًا من كيفية إجراء نقل النطاق، وأكمل جزءًا منه ولكن لم ينته من العملية، لذا بينما لديك GoDaddy متاح ونطاقك مدرج داخل وحدة تحكم GoDaddy، عندما يحاول أي جهاز على الإنترنت البحث عن معلومات DNS لنطاقك، فإن سجلات خادم الأسماء تخبر هذا الجهاز بالتوجه إلى Network Solutions لخوادم DNS الخاصة بالنطاق، وليس إلى GoDaddy على الإطلاق. لديك الآن خياران. يمكنك إما تسجيل الدخول إلى Network Solutions وإضافة سجلات CNAME الخاصة بك هناك، وستعمل لأن Network Solutions هي الخدمة التي تقوم بحل DNS لنطاقك حاليًا، أو يمكنك إنهاء تلك الهجرة وتحديث سجلات خادم الأسماء بحيث تشير إلى خوادم DNS الخاصة بـ GoDaddy، بدلاً من Network Solutions.
باختصار، هذه هي التدفق الذي يحدث مع استعلام DNS:
1. يقوم العميل/الخادم بإجراء طلب لـ DNS
2. تحدد سجلات خادم الأسماء أي خوادم DNS هي السلطة للنطاق الذي تطلبه
3. يتم توجيه استعلامات DNS إلى خوادم الأسماء تلك
4. يتم حل DNS
ال ipconfig /flushdns
ملاحظة أخيرة لإنهاء هذا القسم. كنت أقول أشياء مثل "الآن عندما أفعل هذا..." أو "فورًا بعد هذا التغيير..." وإذا كنت تقوم بإنشاء بعض سجلاتك الخاصة، فقد لاحظت أنه في بعض الأحيان يستغرق الأمر بعض الوقت لكي تتعرف أجهزة الكمبيوتر العميلة على هذه السجلات الجديدة في DNS. هذا سلوك طبيعي، والوقت الذي يستغرقه قبل أن ينتشر التغيير في الشبكة بأكملها يعتمد تمامًا على حجم شبكتك وكيفية تكوين تكرار Active Directory. عندما تقوم بإنشاء سجل DNS جديد على أحد وحدات تحكم النطاق، يجب على السجل الجديد تكرار نفسه في جميع وحدات تحكم النطاق الأخرى في شبكتك. يمكن أن تستغرق هذه العملية بضع ساعات إذا لم يتم تكوين AD لتكرار أسرع. عادةً، يستغرق الأمر بضع دقائق فقط. وبعد ذلك، بمجرد أن يصبح السجل الجديد موجودًا في جميع خوادم وحدات تحكم النطاق، قد تستغرق الأجهزة العميلة بعض الوقت للاستفادة من السجل الجديد، لأن أجهزة الكمبيوتر العميلة في شبكة النطاق تحتفظ بذاكرة تخزين مؤقت لبيانات DNS. بهذه الطريقة، لا يتعين عليها الاتصال بخادم DNS لكل طلب تحويل أسماء. يمكنها بسرعة الرجوع إلى الذاكرة المؤقتة المحلية لمعرفة المعلومات من آخر مرة تحققت فيها من خادم DNS. إذا كنت تحاول اختبار سجل DNS جديد قمت بإنشائه فورًا ولا يعمل، قد ترغب في محاولة تشغيل الأمر ipconfig /flushdns على جهاز الكمبيوتر العميل الخاص بك. هذا يجبر العميل على تفريغ نسخ الذاكرة المؤقتة المحلية لسجلات DNS والذهاب للحصول على معلومات جديدة محدثة من خادم DNS. بعد تفريغ الذاكرة المؤقتة، من المرجح أن يبدأ السجل الجديد في التحول بشكل صحيح.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 4 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
