تفاصيل الوكيل Azure Firewall DNS Proxy
يمكنك تكوين Azure Firewall ليعمل كوكيل DNS. وكيل DNS هو وسيط لطلبات DNS من الأجهزة الظاهرية للعميل إلى خادم DNS.
تصف المعلومات التالية بعض تفاصيل التنفيذ لوكيل DNS الخاص بجدار حماية Azure.
FQDNs مع سجلات A
يعمل Azure Firewall كعميل DNS قياسي. إذا كانت هناك سجلات A متعددة في الاستجابة، يخزن جدار الحماية جميع السجلات في ذاكرة التخزين المؤقت ويقدمها للعميل في الاستجابة. إذا كان هناك سجل واحد لكل استجابة، يخزن جدار الحماية سجلا واحدا فقط. لا توجد طريقة يمكن للعميل من خلالها معرفة ما إذا كان يجب أن يتوقع واحداً أو أكثر من سجلات A في الردود.
مدة البقاء (TTL) لـ FQDN
عندما توشك (مدة بقاء) FQDN TTL على الانتهاء، يتم تخزين السجلات مؤقتًا وتنتهي صلاحيتها وفقًا لـ TTLs الخاصة بهم. لا يتم استخدام الإحضار المسبق، لذلك لا يقوم جدار الحماية بالبحث قبل انتهاء صلاحية TTL لتحديث السجل.
لم يتم تكوين العملاء لاستخدام وكيل DNS لجدار الحماية
إذا تم تكوين كمبيوتر عميل لاستخدام خادم DNS ليس وكيل DNS لجدار الحماية، فقد تكون النتائج غير متوقعة.
على سبيل المثال، افترض أن عبء عمل العميل موجود في شرق الولايات المتحدة، ويستخدم خادم DNS أساسياً مستضافاً في شرق الولايات المتحدة. تم تكوين إعدادات خادم DNS في Azure Firewall لخادم DNS ثانوي مستضاف في غرب الولايات المتحدة. ينتج عن خادم DNS للجدار الناري المستضاف في غرب الولايات المتحدة استجابة مختلفة عن استجابة العميل في شرق الولايات المتحدة.
هذا سيناريو شائع، ولماذا يجب على العملاء استخدام وظيفة وكيل DNS للجدار الناري. على العملاء استخدام جدار الحماية كمحلل خاص بهم إذا كنت تستخدم FQDNs في قواعد الشبكة. يمكنك التأكد من تناسق دقة عنوان IP من قِبل العملاء وجدار الحماية نفسه.
في هذا المثال، إذا تم تكوين FQDN في قواعد الشبكة، يحل جدار الحماية FQDN إلى IP1 (عنوان IP 1) ويحدّث قواعد الشبكة للسماح بالوصول إلى IP1. إذا قام العميل بحل نفس FQDN إلى IP2 وعندما يحله بسبب اختلاف في استجابة DNS، فلن تتطابق محاولة الاتصال الخاصة به مع القواعد الموجودة على جدار الحماية ويتم رفضها.
بالنسبة لـ HTTP/S FQDNs في قواعد التطبيق، يوزع جدار الحماية FQDN من المضيف أو رأس SNI، ويحلها، ثم يتصل بعنوان IP هذا. تم تجاهل عنوان IP الوجهة الذي كان العميل يحاول الاتصال به.