DNS-rigels fan VPN-klanten: eigner, TTL en opromjen binne aparte saken
In VPN-adres, in DNS-rigel en in cache-yngong hawwe aparte eigners: beslute wa’t de namme publisearje mei, hokker ynterfaces registrearje en wannear’t rigels ferjierje.
Laptops meitsje ferbining, krije in VPN-adres, en de namme dy’t oare systemen oplosse wiist noch altyd nei it kantoaradres fan juster. Neat mislearre: in adres waard tawiisd, in rigel waard net bywurke, en in cache hâldt noch it âlde antwurd. Dat binne trije objekten mei trije eigners, en mar ien fan har heart by it VPN. Publikaasje plenje betsjut beslute wa’t de namme skriuwt, hokker ynterfaces meidogge en wannear’t ferâldere gegevens ferdwine.
It symptoom: in namme dy’t it ferkearde adres folget
Fan it apparaat ôf stiet de tunnel en antwurdet it VPN-adres. Fan ’e wurkstasjon fan in kollega ôf oplost deselde hostnamme nei in prive-adres dat it apparaat net mear hat, sadat de ferbining ôfrint tsjin in masine dy’t ferhuze is. De rigel is autorityf en ferkeard, wat slimmer is as ûntbrekkend. Elk fertrout derop en nimmen kin ferbine.
It omkearde gefal is stiller: de rigel ferdwynt en de namme hâldt hielendal op mei oplossen. Beide útkomsten komme fan deselde leechte yn it ûntwerp, en gjinien wurdt reparearre troch de TTL te ferleegjen. In koartere cache-libben feroaret hoe lang it ferkearde antwurd oerlibbet, net oft it skreaun wurdt.
Begjin mei te freegjen hokker objekt ferâldere is. It adres dat it VPN tawiisde, de rigel yn ’e sône en it antwurd yn ’e cache fan in oplosser hawwe ferskillende libbensdieren en ferskillende eigners.
Trije objekten, trije eigners
It VPN besit de adrestawizing en kin it adres út in ynterne pool jaan sûnder dat in DHCP-útwikseling de laptop berikt. De DNS-sône besit de rigel, en har feiligensmodel beslút wa’t dy oanmeitsje of feroarje mei. De cache fan ’e oplosser besit de kopy dy’t in lêzer no brûkt, en neat dat it apparaat docht kin dêryn komme.
Oannimme dat ien komponent alle trije docht is it plak dêr’t it ûntwerp brekt. In adres dat liket te kommen út in beheard berik bewiist net dat in DHCP-tsjinner de registraasje die, en in slagge registraasje bewiist net dat lêzers har cache ferfrisse hawwe.
| 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 |
Wa’t de rigel bywurkje mei
Yn in sône dy’t yntegrearre is mei Active Directory en feilige dynamyske bywurkingen libje de rjochten op ’e rigel sels. In rigel dy’t makke is troch in DHCP-tsjinstakkoart is miskien net skriuwber troch it kompjûterakkoart fan ’e laptop, en it eignerskipsmodel letter feroarje is in oergong, net in skeakel. Dêrom oerlibbet in eignerskips konflikt elke ynstelling oan ’e kliïntkant.
De rjochtline fan Microsoft oer dynamyske bywurkingen foarkiest registraasje oan ’e kliïntkant foar hybrid-einpunten dy’t oan it domein keppele binne. Dat oannimme betsjut besteande rigels bewust oerdrage, net gewoan in fakje oanfinkje op ’e VPN-adapter en hoopje dat de âlde eigner wykt.
Wêr’t in DHCP-tsjinst foar oare apparaatklassen registrearje moat, jou har it stipe leauws- en rjochtemodel foar dy rol. Hâld foarút- en efterút-rigels yn itselde plan, want se wurde faak troch ferskillende komponenten ûnderhâlden en ien fan har wurdt meastentiids fergetten.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042It earste kommando lit sjen hokker adressen it apparaat mient te hawwen en oft de ferbining ynsteld is om se te registrearjen. It twadde en tredde fergelykje wat in kliïnt oplost mei wat de sône eins bewarret, en dat skiedt in cache-problem fan in autorityf probleem.
Trije klokken, net ien
Publikaasje en ferfrisking is de earste klok: wannear’t de autorisearre bywurker oankundiget dat in adres feroare is. De cache-TTL is de twadde: hoe lang in oplosser it ûntfongen antwurd hâlde mei. Autorityf opromjen is de tredde: hoe’t ferâldere rigels fuorthelle wurde troch it registraasjeproses of troch ferâldering en skjinferskowing.
Dizze klokken binne ûnôfhinklik, en se trochinoar helje jout repataasjes dy’t net wurkje. In feroaring yn ien is ûnsichtber foar de oare twa. In koarte TTL ferkoartet it libben fan in cache-antwurd en jout gjin bywurkingsrjocht. Skjinferskowing hellet rigels fuort dy’t net ferfrisse binne, en it kin in rigel net reparearje dy’t nea troch de juste eigner skreaun is.
Stel de TTL yn op hoe fluch lêzers in feroaring sjen moatte, en it opromjen op hoe lang in ferlitten apparaat in namme hâlde moat. Gjin fan beide getallen beslút wa’t de rigel skriuwe mei, en gjin TTL-wearde makket adrestawizing ta DNS-bestjoersrjochten.
Plen publikaasje foar in rûnreizgjend apparaat
Beslute hokker ynterfaces meidogge oan ’e registraasje. In thús-Wi-Fi-adres, in VPN-adres en in âld kantoaradres tsjinje ferskillende publyk, en se allegear publisearje jout in namme mei ferskate antwurden fan ûngelikense nut. Registrearje de ynterfaces dy’t de bedoelde lêzers echt berikke kinne.
Hâld de stabile kompjûternamme as identiteit en behannelje de adressen as attributen dêrfan. Bewarje de domeinûntdekkingsrigels dy’t it apparaat nedich hat, en skeakelje de registraasje net folslein út om in probleem mei dûbele rigels op te lossen dat in rjochteferoaring reparearje soe.
Skriuw de tawizer, de bywurker en de eigner fan it opromjen yn ien rigel, mei de bedoelde lêzers neamd. As de namme wer nei it ferkearde adres wiist, fertelt dy rigel dy hokker fan ’e trije oft earst ûndersocht wurde moat, ynstee fan it ûndersyk opnij te begjinnen.