رکوردهای DNS کلاینت‌های VPN: مالک، TTL و پاک‌سازی جداگانه‌اند
یک نشانی VPN، یک رکورد DNS و یک ورودی در حافظهٔ نهان مالکان جداگانه دارند: تعیین کنید چه کسی می‌تواند نام را منتشر کند، کدام واسط‌ها ثبت می‌شوند و رکوردها چه زمانی کهنه می‌شوند.
لپ‌تاپ‌ها متصل می‌شوند، نشانی VPN می‌گیرند، و نامی که سامانه‌های دیگر حل می‌کنند هنوز به نشانی دفتر دیروز اشاره می‌کند. هیچ چیز شکست نخورده است: نشانی تخصیص یافت، رکورد به‌روز نشد، و حافظه‌ای نهان هنوز پاسخ قدیمی را نگه می‌دارد. این‌ها سه شیء با سه مالک هستند و تنها یکی از آن‌ها متعلق به VPN است. برنامه‌ریزی انتشار یعنی تصمیم درباره اینکه چه کسی نام را می‌نویسد، کدام واسط‌ها مشارکت می‌کنند و داده‌های کهنه چه زمانی ناپدید می‌شوند.
نشانه: نامی که نشانی اشتباه را دنبال می‌کند
از سوی دستگاه، تونل برپاست و نشانی VPN پاسخ می‌دهد. از ایستگاه کاری همکار، همان نام میزبان به نشانی خصوصی‌ای حل می‌شود که دستگاه دیگر آن را ندارد، پس اتصال در برابر ماشینی که جابه‌جا شده است به پایان می‌رسد. رکورد معتبر و اشتباه است، که از نبودنش بدتر است. همه به آن اعتماد می‌کنند و هیچ‌کس نمی‌تواند متصل شود.
حالت معکوس آرام‌تر است: رکورد ناپدید می‌شود و نام دیگر اصلاً حل نمی‌شود. هر دو نتیجه از همان شکاف طراحی می‌آیند و هیچ‌یک با کاهش TTL درست نمی‌شود. عمر کوتاه‌تر حافظهٔ نهان تغییر می‌دهد که پاسخ اشتباه چقدر زنده می‌ماند، نه اینکه نوشته می‌شود یا نه.
با این پرسش شروع کنید که کدام شیء کهنه است. نشانی‌ای که VPN تخصیص داده، رکورد در ناحیه و پاسخ در حافظهٔ نهان یک حل‌کننده عمرها و مالکان متفاوتی دارند.
سه شیء، سه مالک
VPN مالک تخصیص نشانی است و می‌تواند نشانی را از استخری داخلی بدهد بدون آنکه هیچ تبادل DHCP به لپ‌تاپ برسد. ناحیهٔ DNS مالک رکورد است و مدل امنیتی آن تعیین می‌کند چه کسی می‌تواند آن را بسازد یا تغییر دهد. حافظهٔ نهان حل‌کننده مالک نسخه‌ای است که خواننده‌ای اکنون استفاده می‌کند، و هیچ کاری که دستگاه بکند نمی‌تواند به آن برسد.
فرض اینکه یک مؤلفه هر سه کار را انجام می‌دهد همان جایی است که طراحی می‌شکند. نشانی‌ای که به نظر می‌رسد از محدوده‌ای مدیریت‌شده آمده است ثابت نمی‌کند که سرور DHCP ثبت را انجام داده، و ثبت موفق ثابت نمی‌کند که خوانندگان حافظهٔ نهان خود را تازه کرده‌اند.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
چه کسی می‌تواند رکورد را به‌روز کند
در ناحیه‌ای یکپارچه با Active Directory و با به‌روزرسانی‌های پویای امن، مجوزها روی خود رکورد زندگی می‌کنند. رکوردی که حساب سرویس DHCP ساخته است ممکن است برای حساب رایانهٔ لپ‌تاپ قابل نوشتن نباشد، و تغییر مدل مالکیت بعداً یک گذار است، نه یک کلید. به همین دلیل تعارض مالکیت از هر تنظیمی در سمت کلاینت جان سالم به در می‌برد.
راهنمای Microsoft درباره به‌روزرسانی‌های پویا ثبت از سوی کلاینت را برای نقاط پایانی هیبریدی متصل به دامنه ترجیح می‌دهد. پذیرفتن آن یعنی انتقال آگاهانهٔ رکوردهای موجود، نه فقط تیک زدن یک جعبه روی آداپتور VPN و امید به عقب‌نشینی مالک قدیمی.
جایی که سرویس DHCP باید برای کلاس‌های دیگر دستگاه ثبت کند، مدل اعتبارنامه و مجوز پشتیبانی‌شده برای آن نقش را به آن بدهید. رکوردهای پیشرو و معکوس را در یک طرح نگه دارید، چون اغلب مؤلفه‌های مختلف آن‌ها را نگهداری می‌کنند و یکی از آن‌ها معمولاً فراموش می‌شود.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042فرمان نخست نشان می‌دهد دستگاه کدام نشانی‌ها را متعلق به خود می‌داند و آیا اتصال برای ثبت آن‌ها تنظیم شده است. فرمان دوم و سوم آنچه کلاینت حل می‌کند را با آنچه ناحیه واقعاً ذخیره می‌کند مقایسه می‌کنند، و این مشکل حافظهٔ نهان را از مشکل معتبر جدا می‌کند.
سه ساعت، نه یکی
انتشار و تازه‌سازی ساعت نخست است: زمانی که به‌روزکنندهٔ مجاز اعلام می‌کند نشانی تغییر کرده است. TTL حافظهٔ نهان ساعت دوم است: چه مدت یک حل‌کننده می‌تواند پاسخ دریافتی را نگه دارد. پاک‌سازی معتبر ساعت سوم است: چگونه رکوردهای منسوخ با فرایند ثبت یا با کهنگی و جاروب حذف می‌شوند.
این ساعت‌ها مستقل‌اند و اشتباه گرفتن آن‌ها اصلاحاتی به بار می‌آورد که کار نمی‌کند. تغییر در یکی برای دو تای دیگر نامرئی است. TTL کوتاه عمر پاسخ نهان را کوتاه می‌کند و هیچ مجوز به‌روزرسانی نمی‌دهد. جاروب رکوردهایی را حذف می‌کند که تازه نشده‌اند و نمی‌تواند رکوردی را که هرگز مالک درست ننوشته است تعمیر کند.
TTL را بر پایهٔ اینکه خوانندگان باید چقدر سریع تغییر را ببینند تنظیم کنید و جاروب را بر پایهٔ اینکه دستگاه رهاشده چقدر باید نام را نگه دارد. هیچ‌یک از این دو عدد تعیین نمی‌کند چه کسی مجاز به نوشتن رکورد است و هیچ مقدار TTL تخصیص نشانی را به حقوق مدیریت DNS تبدیل نمی‌کند.
انتشار را برای دستگاه سیار برنامه‌ریزی کنید
تعیین کنید کدام واسط‌ها در ثبت مشارکت می‌کنند. نشانی Wi-Fi خانه، نشانی VPN و نشانی دفتر قدیمی به مخاطبان متفاوتی خدمت می‌کنند و انتشار همهٔ آن‌ها نامی با چند پاسخ با سودمندی نابرابر می‌سازد. واسط‌هایی را ثبت کنید که خوانندگان موردنظر واقعاً می‌توانند به آن‌ها برسند.
نام پایدار رایانه را به‌عنوان هویت نگه دارید و نشانی‌ها را ویژگی‌های آن بدانید. رکوردهای کشف دامنه را که دستگاه لازم دارد حفظ کنید و ثبت را به‌طور کلی خاموش نکنید تا مشکلی با رکوردهای تکراری را حل کنید که تغییر مجوز آن را درست می‌کرد.
تخصیص‌دهنده، به‌روزکننده و مالک پاک‌سازی را در یک رکورد بنویسید و خوانندگان موردنظر را نام ببرید. وقتی نام دوباره به نشانی اشتباه اشاره کرد، آن رکورد می‌گوید کدام یک از سه را نخست بررسی کنید، به‌جای آنکه پژوهش را از نو آغاز کنید.