تفويض منطقة شبكة فرعية عكسي أقل من / 24 في BIND. كيف يعمل؟

بمجرد أن واجهت مهمة إعطاء أحد العملاء الحق في تحرير سجلات PTR الخاصة بالشبكة الفرعية المخصصة لها / 28. ليس لدي أتمتة لتحرير إعدادات BIND من الخارج. لذلك قررت أن أذهب في الاتجاه الآخر - لتفويض العميل قطعة من منطقة الشبكة الفرعية PTR / 24.

يبدو - ما يمكن أن يكون أسهل؟ نحن فقط نصف الشبكة الفرعية بالطريقة الصحيحة ونوجهها إلى NS المرغوب كما هو الحال مع المجال الفرعي. لكن لا. الأمر ليس بهذه البساطة (على الرغم من أنه في الواقع بدائي بشكل عام ، ولكن الحدس لن يساعد) ، ولهذا السبب أكتب هذا المقال.

الذي يريد معرفة ذلك بنفسه يمكن قراءة RFC
الذي يريد حل جاهز ، مرحبا بكم في القط.

من أجل عدم تأخير أولئك الذين يحبون طريقة لصق النسخ ، أولاً سأقوم بنشر الجزء العملي ، وبعد ذلك الجزء النظري.

1. الممارسة. منطقة التفويض / 28

دعنا نقول لدينا شبكة فرعية من 7.8.9.0/24 . نحن بحاجة إلى تفويض الشبكة الفرعية 7.8.9.240/28 إلى عميل DNS 7.8.7.8 ( ns1.client.domain ).

على موفر DNS ، تحتاج إلى العثور على ملف يصف المنطقة العكسية لهذه الشبكة الفرعية. فليكن 9.8.7.in-addr.arpa .
تم تعليق المشاركات من 240 إلى 255 ، إن وجدت. وفي نهاية الملف ، اكتب ما يلي:

255-240 IN NS 7.8.7.8 $GENERATE 240-255 $ CNAME $.255-240 

لا تنسى زيادة المناطق التسلسلية والقيام بها

 rndc reload 

على هذا ، الجزء مزود انتهت. نمررها إلى نظام أسماء النطاقات العميل.

أولاً ، قم بإنشاء /etc/bind/master/255-240.9.8.7.in-addr.arpa مع المحتوى التالي:

 $ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain. 

وفي named.conf ، أضف وصف ملفنا الجديد:

 zone "255-240.9.8.7.in-addr.arpa." IN { type master; file "master/255-240.9.8.7.in-addr.arpa"; }; 

ب إعادة تشغيل عملية الربط.

 /etc/init.d/named restart 

هذا كل شيء. الآن يمكنك التحقق.

 #> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain. 

يرجى ملاحظة أنه لا يتم توفير سجل PTR فقط ، ولكن أيضًا CNAME. يجب أن يكون كذلك. إذا كنت تتساءل لماذا ، ثم مرحبا بكم في الفصل التالي.

2. النظرية. كيف يعمل؟

من الصعب تكوين مربع أسود وتصحيحه. أسهل بكثير إذا فهمت ما يحدث في الداخل.

عندما نقوم بتفويض نطاق فرعي في مجال المجال ، نكتب شيئًا مثل هذا:

 client.domain. NS ns1.client.domain. ns1.client.domain. A 7.8.7.8 

نطلب من الجميع مطالبة أننا لسنا مسؤولين عن هذا الموقع ونقول من المسؤول. ويتم إعادة توجيه جميع الطلبات إلى client.domain إلى 7.8.7.8. عند التحقق ، نرى الصورة التالية (حذف ما لدى العميل هناك. لا يهم):

 # host test.client.domain test.client.domain has address 7.8.9.241 

أي أبلغنا أن هناك مثل هذا السجل A والملكية الفكرية 7.8.9.241. لا توجد معلومات غير ضرورية.

ولكن كيف يمكن القيام بنفس الشيء مع شبكة فرعية؟

لأن نظرًا لأن خادم DNS الخاص بنا مسجل في RIPE ، عند طلب عنوان IP PTR من شبكتنا ، فسيظل إرسال الطلب الأول إلينا. المنطق هو نفسه كما هو الحال مع المجالات. ولكن فقط كيفية إدخال الشبكة الفرعية في ملف المنطقة؟

نحن نحاول إدخاله مثل هذا:

 255-240 IN NS 7.8.7.8 

و ... لم تحدث معجزة. نحن لا نتلقى أي إعادة توجيه الطلب. الشيء هو أن الربط ليس مدركًا على الإطلاق أن هذه الإدخالات في ملف المنطقة العكسية هي عناوين بروتوكول الإنترنت وأكثر من ذلك حتى لا يفهمون إدخال النطاق. بالنسبة له ، هذا مجرد مجال فرعي رمزي. أي لربط لن يكون هناك فرق بين " 255-240 " و " ouruperclient ". وطلب طلب الانتقال إلى حيث يجب أن يكون ، يجب أن يبدو العنوان في الطلب كما يلي: 241.255-240.9.8.7.in-addr.arpa . أو هكذا ، إذا استخدمنا نطاقًا فرعيًا للحرف: 241.oursuperclient.9.8.7.in-addr.arpa . هذا يختلف عن المعتاد: 241.9.8.7.in-addr.arpa .

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

وهنا يأتي دور CNAME .

من جانب الموفر ، تحتاج إلى إنشاء اسم مستعار لجميع عناوين IP الخاصة بالشبكة الفرعية بتنسيق يؤدي إلى إعادة توجيه الطلب إلى DNS العميل.

 255-240 IN NS ns1.client.domain. 241 IN CNAME 241.255-240 242 IN CNAME 242.255-240  .. 

هذا هو للعمل الدؤوب =).

وبالنسبة للكسل ، التصميم أدناه مناسب أكثر:

 255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240 

سيتم الآن تحويل طلب المعلومات على 7.8.9.241 من 241.9.8.7.in-addr.arpa على خادم DNS الخاص بالمزود إلى 241.255-240.9.8.7.in-addr.arpa وسيتم الانتقال إلى عميل DNS.

سيحتاج العميل إلى معالجة هذه الطلبات. وفقًا لذلك ، نقوم بإنشاء منطقة 255-240.9.8.7.in-addr.arpa . في ذلك ، يمكننا بشكل أساسي نشر سجلات معاكسة لأي عنوان IP للشبكة الفرعية بالكامل / 24 ، ولكن لن يتم سؤالك إلا عن تلك التي سيقوم الموفر بإعادة توجيهها إلينا ، لذلك لن تكون قادرًا على اللعب =).
للتوضيح ، سأقدم مثالاً على محتويات ملف المنطقة العكسية على جانب العميل:

 $ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain. 

يرجع ذلك إلى حقيقة أننا نستخدم CNAME من جانب الموفر ، واستجابة لطلب البيانات على عنوان IP ، نحصل على سجلين وليس واحدًا.

 #> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain. 

ولا تنسى تكوين ACL بشكل صحيح. لأنه من غير المنطقي أن تأخذ منطقة PTR لنفسك ولا تجيب على أي شخص من الخارج =).

Source: https://habr.com/ru/post/ar451890/


All Articles