یک روز با این وظیفه مواجه شدم که به یکی از مشتریانم حق ویرایش رکوردهای PTR زیرشبکه /28 را بدهم که به او اختصاص داده شده است. من اتوماسیونی برای ویرایش تنظیمات BIND از بیرون ندارم. بنابراین، تصمیم گرفتم مسیر دیگری را انتخاب کنم - بخشی از منطقه PTR زیرشبکه /24 را به مشتری واگذار کنم.
به نظر می رسد - چه چیزی می تواند ساده تر باشد؟ ما به سادگی زیر شبکه را همانطور که لازم است ثبت می کنیم و آن را به NS مورد نظر هدایت می کنیم، همانطور که با یک زیر دامنه انجام می شود. اما نه. این به این سادگی نیست (اگرچه در واقعیت به طور کلی ابتدایی است، اما شهود کمکی نمی کند)، به همین دلیل است که من این مقاله را می نویسم.
هر کس می خواهد خودش بفهمد می تواند بخواند
کسی که یک راه حل آماده می خواهد، به گربه خوش آمدید.
برای اینکه کسانی که روش کپی پیست را دوست دارند معطل نشویم ابتدا قسمت عملی و سپس قسمت تئوری را قرار می دهم.
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.harp.
ما در مورد ورودی های 240 تا 255، در صورت وجود، نظر می دهیم. و در انتهای فایل موارد زیر را می نویسیم:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240فراموش نکنید که منطقه سریال را افزایش دهید و انجام دهید
rndc reloadاین بخش ارائه دهنده را کامل می کند. بیایید به سمت dns مشتری برویم.
ابتدا بیایید یک فایل بسازیم /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.
و در نامگذاری شده توضیحی برای فایل جدید ما اضافه کنید:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B فرآیند bind را مجدداً راه اندازی کنید.
/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 وجود دارد و ip آن 7.8.9.241 است. بدون اطلاعات غیر ضروری
چگونه می توان همین کار را با یک زیر شبکه انجام داد؟
زیرا سرور DNS ما در RIPE ثبت شده است، سپس هنگام درخواست یک آدرس IP PTR از شبکه ما، اولین درخواست همچنان برای ما خواهد بود. منطق مانند دامنه ها است. اما چگونه می توان یک زیر شبکه را در یک فایل zone وارد کرد؟
بیایید سعی کنیم آن را به این صورت وارد کنیم:
255-240 IN NS 7.8.7.8و ... معجزه اتفاق نیفتاد. ما هیچ گونه تغییر مسیر درخواستی را دریافت نمی کنیم. موضوع این است که bind حتی نمی داند که این ورودی ها در فایل منطقه معکوس آدرس IP هستند و حتی بیشتر از آن ورودی محدوده را درک نمی کند. برای او، این فقط نوعی زیر دامنه نمادین است. آن ها برای bind هیچ تفاوتی بین "255-240"و"ابر مشتری ما". و برای اینکه درخواست به جایی که باید برود، آدرس در درخواست باید به شکل زیر باشد: 241.255-240.9.8.7.in-addr.arpa. یا اگر از یک زیر دامنه کاراکتر استفاده کنیم به این صورت: 241.oursuperclient.9.8.7.in-addr.arpa. این با حالت معمول متفاوت است: 241.9.8.7.in-addr.harp.
انجام چنین درخواستی به صورت دستی دشوار خواهد بود. و حتی اگر کار کند، هنوز مشخص نیست که چگونه آن را در زندگی واقعی اعمال کنید. پس از همه، در صورت درخواست 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.harp در سرور DNS ارائه دهنده به تبدیل خواهد شد 241.255-240.9.8.7.in-addr.arpa و به سمت کلاینت dns می رود.
طرف مشتری باید به چنین درخواست هایی رسیدگی کند. بر این اساس، ما یک منطقه ایجاد می کنیم 255-240.9.8.7.in-addr.arpa. در آن، اصولاً می‌توانیم ورودی‌های معکوس را برای هر آی‌پی از کل زیرشبکه /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 بگیرید و به کسی از بیرون پاسخ ندهید =).
منبع: www.habr.com