DNS записи VPN клијената: власник, TTL и чишћење су одвојени

Преносни рачунари се повезују, добијају VPN адресу, а име које други системи разрешавају још показује на јучерашњу адресу канцеларије. Ништа није отказало: адреса је додељена, запис није ажуриран, а кеш још држи стари одговор. То су три објекта са три власника, и само један од њих припада VPN-у. Планирање објаве значи одлучити ко пише име, која интерфејса учествују и када нестају застарели подаци.

Симптом: име које следи погрешну адресу

Са уређаја тунел је подигнут и VPN адреса одговара. Са радне станице колеге исто име хоста разрешава се на приватну адресу коју уређај више не држи, па веза истиче према машини која се преселила. Запис је ауторитативан и погрешан, што је горе од недостајућег. Сви му верују и нико не може да се повеже.

Обрнути случај је тиши: запис нестане и име потпуно престане да се разрешава. Оба исхода долазе из исте празнине у дизајну, и ниједан се не исправља снижавањем TTL-а. Краћи животни век кеша мења колико дуго погрешан одговор преживи, а не да ли се записује.

Почните питањем који је објекат застарео. Адреса коју је VPN доделио, запис у зони и одговор у кешу резолвера имају различите животне векове и различите власнике.

Три објекта, три власника

VPN поседује доделу адреса и може издати адресу из интерног пула, а да ниједна DHCP размена не стигне до преносног рачунара. DNS зона поседује запис, и њен безбедносни модел одлучује ко га сме створити или изменити. Кеш резолвера поседује копију коју читалац тренутно користи, и ништа што уређај чини не може до ње допрети.

Претпоставка да једна компонента ради све три је место где се дизајн ломи. Адреса која изгледа да долази из управљаног опсега не доказује да је DHCP сервер обавио регистрацију, а успешна регистрација не доказује да су читаоци освежили кеш.

Ко сме да ажурира запис

У зони интегрисаној са 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 адреса и стара канцеларијска адреса служе различитим публикама, а објава свих даје име са неколико одговора неједнаке користи. Региструјте интерфејсе до којих предвиђени читаоци заиста могу да стигну.

Држите стабилно име рачунара као идентитет и третирајте адресе као његове атрибуте. Сачувајте записе откривања домена који су уређају потребни, и не искључујте регистрацију у целини да бисте решили проблем дуплих записа који би промена дозвола исправила.

Упишите додељивача, ажуратора и власника чишћења у један запис, са именованим предвиђеним читаоцима. Када име поново покаже погрешну адресу, тај запис вам каже кога од тројице прво проверити, уместо да истрагу почнете изнова.