Rekordy DNS klientów VPN: właściciel, TTL i sprzątanie to osobne sprawy
Adres VPN, rekord DNS i wpis w pamięci podręcznej mają odrębnych właścicieli: zdecyduj, kto może publikować nazwę, które interfejsy się rejestrują i kiedy rekordy wygasają.
Laptopy łączą się, otrzymują adres VPN, a nazwa, którą rozwiązują inne systemy, nadal wskazuje na wczorajszy adres biurowy. Nic nie zawiodło: adres został przydzielony, rekord nie został zaktualizowany, a pamięć podręczna wciąż trzyma starą odpowiedź. To trzy obiekty z trzema właścicielami, i tylko jeden z nich należy do VPN. Planowanie publikacji oznacza decyzję, kto zapisuje nazwę, które interfejsy uczestniczą i kiedy znikają nieaktualne dane.
Objaw: nazwa, która podąża za złym adresem
Z urządzenia tunel jest podniesiony i adres VPN odpowiada. Ze stacji roboczej kolegi ta sama nazwa hosta rozwiązuje się na prywatny adres, którego urządzenie już nie ma, więc połączenie kończy się przekroczeniem czasu wobec maszyny, która się przeniosła. Rekord jest autorytatywny i błędny, co jest gorsze niż brak. Wszyscy mu ufają i nikt nie może się połączyć.
Odwrotny przypadek jest cichszy: rekord znika i nazwa przestaje się w ogóle rozwiązywać. Oba wyniki pochodzą z tej samej luki w projekcie i żadnego nie naprawia obniżenie TTL. Krótszy czas życia pamięci podręcznej zmienia to, jak długo przetrwa błędna odpowiedź, a nie to, czy zostanie zapisana.
Zacznij od pytania, który obiekt jest nieaktualny. Adres przydzielony przez VPN, rekord w strefie i odpowiedź w pamięci podręcznej resolvera mają różne czasy życia i różnych właścicieli.
Trzy obiekty, trzech właścicieli
VPN posiada przydział adresów i może wydać adres z wewnętrznej puli, zanim jakakolwiek wymiana DHCP dotrze do laptopa. Strefa DNS posiada rekord, a jej model bezpieczeństwa decyduje, kto może go utworzyć lub zmienić. Pamięć podręczna resolvera posiada kopię, której czytelnik właśnie używa, i nic, co robi urządzenie, nie może do niej dotrzeć.
Założenie, że jeden komponent robi wszystkie trzy rzeczy, jest miejscem, w którym projekt się łamie. Adres wyglądający na przydzielony z zarządzanego zakresu nie dowodzi, że serwer DHCP wykonał rejestrację, a udana rejestracja nie dowodzi, że czytelnicy odświeżyli pamięć podręczną.
| 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 |
Kto może aktualizować rekord
W strefie zintegrowanej z Active Directory i z bezpiecznymi aktualizacjami dynamicznymi uprawnienia żyją na samym rekordzie. Rekord utworzony przez konto usługi DHCP może nie być zapisywalny przez konto komputera laptopa, a późniejsza zmiana modelu własności to przejście, nie przełącznik. Dlatego konflikt własności przetrwa każde ustawienie po stronie klienta.
Wytyczne Microsoftu dotyczące aktualizacji dynamicznych preferują rejestrację po stronie klienta dla przyłączonych do domeny punktów końcowych hybrydowych. Przyjęcie ich oznacza świadome przeniesienie istniejących rekordów, a nie tylko zaznaczenie pola na karcie VPN i nadzieję, że stary właściciel ustąpi.
Gdy usługa DHCP musi rejestrować inne klasy urządzeń, daj jej obsługiwany model poświadczeń i uprawnień dla tej roli. Trzymaj rekordy wprost i odwrotne w jednym planie, ponieważ często utrzymują je różne komponenty i jeden z nich bywa zapominany.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042
Pierwsze polecenie pokazuje, które adresy urządzenie uważa za swoje i czy połączenie jest ustawione na ich rejestrowanie. Drugie i trzecie porównują to, co rozwiązuje klient, z tym, co strefa naprawdę przechowuje, i to oddziela problem pamięci podręcznej od problemu autorytatywnego.
Trzy zegary, nie jeden
Publikacja i odświeżanie to pierwszy zegar: moment, w którym upoważniony aktualizator ogłasza zmianę adresu. TTL pamięci podręcznej to drugi: jak długo resolver może trzymać otrzymaną odpowiedź. Autorytatywne sprzątanie to trzeci: jak nieaktualne rekordy są usuwane przez proces rejestracji albo przez starzenie i zamiatanie.
Te zegary są niezależne, a ich mylenie daje poprawki, które nie działają. Zmiana w jednym jest niewidoczna dla dwóch pozostałych. Krótki TTL skraca życie odpowiedzi z pamięci podręcznej i nie daje żadnego uprawnienia do aktualizacji. Zamiatanie usuwa rekordy, które nie zostały odświeżone, i nie naprawi rekordu, którego nigdy nie zapisał właściwy właściciel.
Ustaw TTL według tego, jak szybko czytelnicy muszą zobaczyć zmianę, a zamiatanie według tego, jak długo porzucone urządzenie ma zachować nazwę. Żadna z tych liczb nie decyduje, kto może zapisać rekord, i żadna wartość TTL nie zamienia przydziału adresów w uprawnienia administracyjne DNS.
Zaplanuj publikację dla urządzenia wędrującego
Zdecyduj, które interfejsy uczestniczą w rejestracji. Domowy adres Wi-Fi, adres VPN i stary adres biurowy służą różnym odbiorcom, a publikowanie wszystkich daje nazwę z kilkoma odpowiedziami o nierównej użyteczności. Rejestruj te interfejsy, do których zamierzeni czytelnicy naprawdę mogą dotrzeć.
Zachowaj stabilną nazwę komputera jako tożsamość, a adresy traktuj jako jej atrybuty. Zachowaj rekordy odnajdywania domeny potrzebne urządzeniu i nie wyłączaj rejestracji całkowicie, aby rozwiązać problem zduplikowanych rekordów, który naprawiłaby zmiana uprawnień.
Zapisz przydzielacza, aktualizatora i właściciela sprzątania w jednym rekordzie, z nazwanymi zamierzonymi czytelnikami. Gdy nazwa znów wskaże zły adres, ten rekord powie ci, który z trzech sprawdzić najpierw, zamiast zaczynać dochodzenie od nowa.