دو سایت، یک ناحیهٔ DNS خصوصی: رکوردها از آنِ کیست؟

میزبانی را در سایت سبز اضافه می‌کنید، برای کاربران سبز حل می‌شود، و دفتر زرد هنوز NXDOMAIN می‌گیرد. این نه شکست VPN است و نه resolver خراب؛ این یک شکاف مالکیت در ناحیهٔ خصوصی است. دو فهرست رکورد که مستقل ویرایش می‌شوند فقط به این دلیل که سایت‌ها می‌توانند به هم برسند یک ناحیه نمی‌شوند. راه‌حل یک طرح انتشار است، نه یک قاعدهٔ دیگر دیوار آتش.

نشانه، مالک غایب را نام می‌برد

احتمالاً هر سایت یک بازنویسی محلی، یک ورودی Pi-hole یا یک خط dnsmasq دارد که کسی وقتی نامی لازم بود اضافه کرده است. رکورد سبز فقط روی resolver سبز وجود دارد، پس کاربری در سایت زرد از resolver خودش می‌پرسد و پاسخ صادقانهٔ "چنین نامی وجود ندارد" را می‌گیرد. پاسخ کهنه متفاوت به نظر می‌رسد: میزبان جابه‌جا شده، یک سایت نسخهٔ خود را به‌روز کرده و دیگری هنوز نشانی قدیمی را برمی‌گرداند.

هیچ‌کدام از این دو الگو با پاک‌کردن کش برای مدت طولانی درست نمی‌شود. کش یک resolver ارسال‌کننده رونوشتی از پاسخی است که یک بار گرفته، نه اختیاری که نام‌های تازه منتشر می‌کند، بنابراین کشی که امروز کار می‌کند چیزی دربارهٔ میزبان فردا نمی‌گوید. مستندات BIND نقش‌های اصلی، ثانویه، بازگشتی و ارسال‌کننده را دقیقاً به همین دلیل جداگانه توصیف می‌کند.

پس پرسش طراحی باریک و پاسخ‌پذیر است: چه کسی می‌تواند رکورد بسازد، و آن رکورد چگونه به هر resolverی می‌رسد که باید برایش پاسخ دهد؟

گزینهٔ A: یک ناحیهٔ معتبر با ثانویه‌ها

یک اصلی برای internal.example.com اجرا کنید و بگذارید ثانویه‌های پشتیبانی‌شده ناحیه را در هر سایت بگیرند. resolver بازگشتی هر سایت از ثانویهٔ محلی خود می‌پرسد، پس پاسخ‌ها از منبع معتبر می‌آیند نه از کش، و تغییری که یک بار انجام شده منتقل می‌شود نه دوباره تایپ.

این چیدمان تصمیم‌های صریحی می‌خواهد که به‌آسانی به تعویق می‌افتند و گران از دست می‌روند. چه کسی می‌تواند ناحیه را ویرایش کند؟ کدام سرورها اجازهٔ انتقال آن را دارند، و از طریق کدام نشانی‌ها؟ کاربران در زمانی که تونل بین سایت‌ها قطع است چه باید ببینند؟ ثانویه همچنان از آخرین رونوشت خود پاسخ می‌دهد، که معمولاً همان رفتاری است که می‌خواهید، اما باید یک انتخاب اعلام‌شده باشد نه غافلگیری در هنگام قطعی.

انتقال ناحیه را به ثانویه‌های شناخته‌شده بر اساس نشانی محدود کنید و در جایی که پیاده‌سازی پشتیبانی می‌کند از امضای تراکنش استفاده کنید. انتقال باز، رونوشتی از فضای نام داخلی شما برای هر کسی است که به درگاه برسد.

هزینه هماهنگی است: یک مسیر ویرایش، یک بازبینی تغییر، و درک مشترک از اینکه هنگام اشتباه بودن یک رکورد چه کسی کشیک است.

گزینهٔ B: یک زیردامنه برای هر سایت

green.internal.example.com را به سایت سبز و yellow.internal.example.com را به سایت زرد واگذار کنید. هر سایت نسبت به نام‌های خودش معتبر می‌شود و ناحیهٔ والد فقط رکوردهای واگذاری را حمل می‌کند. رقابت بر سر یک فایل از بین می‌رود و یک تیم محلی می‌تواند بدون انتظار برای تغییر مرکزی میزبان اضافه کند.

واگذاری باید در والد وجود داشته باشد، با رکوردهای NS که به سرورهای معتبر سایت اشاره می‌کنند. ارسال شرطی برای زیردامنه جایگزین معتبری است وقتی واگذاری کامل عملی نیست، اما این یک تنظیم resolver است نه یک واقعیت منتشرشده، پس هر resolver به همان قاعده نیاز دارد.

هزینه جابه‌جا می‌شود نه اینکه از بین برود: ناحیهٔ والد هنوز مالک می‌خواهد و ساختن سایت تازه اکنون تغییری در دو جا است نه یک جا.

بگذارید هر resolver از انتخاب پیروی کند

resolver تأییدشده و دامنهٔ جستجو را از طریق پیکربندی پشتیبانی‌شده به کاربران بدهید و مطمئن شوید که resolver مسیر VPN مجاز به هر سرور DNS راه دوری دارد که باید از آن بپرسد. برنامه‌ها هم به مسیرهایی به نشانی‌های خصوصی نیاز دارند که آن پاسخ‌ها برمی‌گردانند، چون نام درست بدون مسیر هنوز یک اتصال شکسته است.

اگر Pi-hole حل محلی را فراهم می‌کند، بنویسید کدام رکوردها را دارد و کدام پرس‌وجوها را ارسال می‌کند. دو فهرست Pi-hole که مستقل ویرایش می‌شوند هنوز تکرار نمی‌شوند. در Pi-hole v6، خطوط سفارشی dnsmasq از طریق گزینه‌های سمت میزبان مانند TOML، CLI یا متغیرهای محیطی تنظیم می‌شوند و از طریق API نمایش داده نمی‌شوند؛ بارگذاری فایل‌های /etc/dnsmasq.d/ گزینهٔ جدایی است که به‌طور پیش‌فرض خاموش است.

سپس از هر دو طرف با نامی آزمایش کنید که باید همه‌جا دیده شود:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

پاسخ SOA به شما می‌گوید که resolver زرد خود را معتبر می‌داند، از ثانویه می‌پرسد، یا فقط ارسال می‌کند. این‌ها طراحی‌های متفاوت با حالت‌های خرابی متفاوت‌اند و پاسخ معمولاً مشخص می‌کند کدام را واقعاً پیاده کرده‌اید.

با سه مورد پذیرش تمام کنید: یک نام از هر سایت، یک رکورد که در عرض یک ساعت تغییر کرده، و پیوند بین سایت‌ها در دسترس نباشد. طراحی‌ای که فقط اولی را می‌گذراند، طرح انتشاری روی کاغذ و بازنویسی محلی در تولید دارد.