DNS-rekords van VPN-kliënte: eienaar, TTL en opruiming is aparte dinge
’n VPN-adres, ’n DNS-rekord en ’n kasinskrywing het elkeen ’n eie eienaar: besluit wie die naam mag publiseer, watter koppelvlakke registreer, en wanneer rekords uitfaseer.
Skootrekenaars koppel, kry ’n VPN-adres, en die naam wat ander stelsels opzoek, wys steeds na gister se kantooradres. Niks het gefaal nie: ’n adres is toegeken, ’n rekord is nie opgedateer nie, en ’n kas hou steeds die ou antwoord. Dit is drie objekte met drie eienaars, en net een van hulle behoort aan die VPN. Om publikasie te beplan beteken om te besluit wie die naam skryf, watter koppelvlakke deelneem en wanneer verouderde data verdwyn.
Die simptoom: ’n naam wat die verkeerde adres volg
Op die toestel is die tonnel op en die VPN-adres antwoord. Vanaf ’n kollega se werkstasie los dieselfde gasheernaam op na ’n private adres wat die toestel nie meer het nie, so die verbinding hou op reageer teen ’n masjien wat intussen geskuif het. Die rekord is gesaghebbend en verkeerd, wat erger is as ontbreek. Almal vertrou dit en niemand kan koppel nie.
Die omgekeerde geval is stiller: die rekord verdwyn en die naam los glad nie meer op nie. Beide uitkomste kom uit dieselfde leemte in die ontwerp, en nie een word reggemaak deur die TTL te verlaag nie. ’n Korter kasleeftyd verander hoe lank die verkeerde antwoord oorleef, nie of dit geskryf word nie.
Begin deur te vra watter objek verouderd is. Die adres wat die VPN toegeken het, die rekord in die sone en die antwoord in ’n oplosser se kas het verskillende lewensduurte en verskillende eienaars.
Drie objekte, drie eienaars
Die VPN besit die adrestoekenning, en dit kan die adres uit ’n interne poel uitgee sonder dat enige DHCP-uitruiling die skootrekenaar bereik. Die DNS-sone besit die rekord, en sy sekuriteitsmodel besluit wie dit mag skep of wysig. Die oplosser se kas besit die kopie wat ’n leser tans gebruik, en niks wat die toestel doen, kan daarby uitkom nie.
Om te aanvaar dat een komponent al drie doen, is waar die ontwerp breek. ’n Adres wat lyk of dit uit ’n bestuurde reeks kom, bewys nie dat ’n DHCP-bediener die registrasie gedoen het nie, en ’n suksesvolle registrasie bewys nie dat lesers hul kas verfris het nie.
| 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 |
Wie mag die rekord opdateer
In ’n Active Directory-geïntegreerde sone met veilige dinamiese opdaterings leef die regte op die rekord self. ’n Rekord wat deur ’n DHCP-diensrekening geskep is, is dalk nie deur die skootrekenaar se rekenaarrekenning skryfbaar nie, en om die eienaarskapmodel later te verander is ’n oorgang, nie ’n skakelaar nie. Dit is waarom ’n eienaarskapkonflik elke kliëntkant-instelling oorleef.
Microsoft se leidraad vir dinamiese opdaterings verkies kliëntkant-registrasie vir domeingekoppelde hibriede eindpunte. Om dit te aanvaar beteken om bestaande rekords doelbewus oor te dra, nie net om ’n blokkie op die VPN-adapter te merk en te hoop die ou eienaar gee pad nie.
Waar ’n DHCP-diens vir ander toestelklasse moet registreer, gee dit die ondersteunde geloofsbrief- en regtemodel vir daardie rol. Hou voorwaartse en terugwaartse rekords in dieselfde plan, want hulle word dikwels deur verskillende komponente onderhou en een van hulle word gewoonlik vergeet.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042Die eerste opdrag wys watter adresse die toestel dink hy het en of die verbinding gestel is om hulle te registreer. Die tweede en derde vergelyk wat ’n kliënt oplos met wat die sone werklik stoor, wat ’n kasprobleem van ’n gesaghebbende probleem skei.
Drie horlosies, nie een nie
Publikasie en verfrissing is die eerste horlosie: wanneer die gemagtigde opdaterer aankondig dat ’n adres verander het. Kas-TTL is die tweede: hoe lank ’n oplosser die antwoord mag hou wat hy ontvang het. Gesaghebbende opruiming is die derde: hoe verouderde rekords deur die registrasieproses of deur veroudering en skoonmaak verwyder word.
Hierdie horlosies is onafhanklik, en om hulle te verwar lewer regstellings op wat nie werk nie. ’n Verandering aan een is onsigbaar vir die ander twee. ’n Kort TTL verkort die lewe van ’n gekaste antwoord en gee geen opdateringsreg nie. Skoonmaak verwyder rekords wat nie verfris is nie, en dit kan nie ’n rekord herstel wat nooit deur die regte eienaar geskryf is nie.
Stel die TTL volgens hoe vinnig lesers ’n verandering moet sien, en stel skoonmaak volgens hoe lank ’n verlate toestel ’n naam moet hou. Nie een van die twee getalle besluit wie die rekord mag skryf nie, en geen TTL-waarde maak adrestoekenning in DNS-administrasieregte nie.
Beplan publikasie vir ’n swerwende toestel
Besluit watter koppelvlakke aan registrasie deelneem. ’n Tuis-Wi-Fi-adres, ’n VPN-adres en ’n ou kantooradres dien verskillende gehore, en om almal te publiseer lewer ’n naam met verskeie antwoorde van ongelyke nut. Registreer die koppelvlakke wat die beoogde lesers werklik kan bereik.
Hou die stabiele rekenaarnaam as die identiteit en behandel die adresse as eienskappe daarvan. Bewaar die domeinontdekkingsrekords wat die toestel nodig het, en moenie registrasie in die geheel afskakel om ’n duplikaatrekord-probleem op te los wat ’n regteverandering sou regstel nie.
Skryf die toekener, die opdaterer en die opruimingseienaar in een rekord neer, met die beoogde lesers by die naam genoem. Wanneer die naam weer na die verkeerde adres wys, sê daardie rekord vir jou watter van die drie eerste ondersoek moet word, in plaas daarvan om die ondersoek oor te begin.