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

Пазете стабилното име на компютъра като идентичност и третирайте адресите като негови атрибути. Запазете записите за откриване на домейн, които устройството изисква, и не изключвайте регистрацията изцяло, за да решите проблем с дублирани записи, който промяна на разрешенията би поправила.

Запишете разпределителя, обновяващия и собственика на изчистването в един запис, с посочени предвидени четци. Когато името отново сочи грешния адрес, този запис ви казва кой от трите да проверите първо, вместо да започвате разследването отначало.