Mga DNS record ng mga kliyente ng VPN: may-ari, TTL at paglilinis ay hiwalay

Kumokonekta ang mga laptop, tumatanggap ng address ng VPN, at ang pangalang nireresolba ng ibang sistema ay tumuturo pa rin sa address ng opisina kahapon. Walang nabigo: may inilaan na address, walang na-update na record, at may cache pang nagtatago ng lumang sagot. Ito ay tatlong bagay na may tatlong may-ari, at isa lamang sa kanila ang pag-aari ng VPN. Ang pagpaplano ng paglathala ay nangangahulugang pagpapasya kung sino ang nagsusulat ng pangalan, aling mga interface ang kasali at kailan nawawala ang lumang data.

Sintomas: pangalang sumusunod sa maling address

Mula sa device, buhay ang tunnel at sumasagot ang address ng VPN. Mula sa workstation ng katrabaho, ang parehong hostname ay nireresolba sa isang pribadong address na wala na sa device, kaya nag-timeout ang koneksyon laban sa isang makinang lumipat. Ang record ay awtoritatibo at mali, na mas masahol pa kaysa wala. Lahat ay nagtitiwala rito at walang makakonekta.

Ang kabaligtaran ay mas tahimik: nawawala ang record at tuluyang tumitigil ang pag-resolba ng pangalan. Ang dalawang resulta ay nagmumula sa parehong puwang sa disenyo, at wala sa kanila ang naayos sa pamamagitan ng pagbaba ng TTL. Ang mas maikling buhay ng cache ay nagbabago kung gaano katagal nabubuhay ang maling sagot, hindi kung ito ay nakasulat.

Magsimula sa pagtatanong kung aling bagay ang lipas na. Ang address na inilaan ng VPN, ang record sa zone at ang sagot sa cache ng resolver ay may magkaibang buhay at magkaibang may-ari.

Tatlong bagay, tatlong may-ari

Pag-aari ng VPN ang paglalaan ng address, at maaari nitong ibigay ang address mula sa panloob na pool nang walang palitan ng DHCP na umabot sa laptop. Pag-aari ng zone ng DNS ang record, at ang modelo ng seguridad nito ang nagpapasya kung sino ang makakagawa o makakabago nito. Pag-aari ng cache ng resolver ang kopyang ginagamit ng mambabasa ngayon, at wala sa ginagawa ng device ang makakaabot doon.

Ang pagpapalagay na isang bahagi ang gumagawa ng tatlo ay ang puntong nasisira ang disenyo. Ang address na mukhang galing sa pinamamahalaang saklaw ay hindi nagpapatunay na ang server ng DHCP ang nagrehistro, at ang matagumpay na rehistro ay hindi nagpapatunay na na-refresh ng mga mambabasa ang kanilang cache.

Sino ang maaaring mag-update ng record

Sa zone na isinama sa Active Directory at may mga secure na dynamic na update, ang mga pahintulot ay nasa record mismo. Ang record na ginawa ng service account ng DHCP ay maaaring hindi maisulat ng computer account ng laptop, at ang pagbabago ng modelo ng pagmamay-ari mamaya ay isang transisyon, hindi switch. Kaya't ang hidwaan sa pagmamay-ari ay lumalampas sa bawat setting sa panig ng kliyente.

Mas pinipili ng patnubay ng Microsoft sa mga dynamic na update ang pagrerehistro sa panig ng kliyente para sa mga hybrid endpoint na kaanib sa domain. Ang pagtanggap nito ay nangangahulugang sadyang paglilipat ng mga umiiral na record, hindi lamang pagmamarka ng kahon sa adapter ng VPN at pag-asang susuko ang lumang may-ari.

Kung kailangang magrehistro ng service ng DHCP para sa ibang klase ng device, bigyan ito ng sinusuportahang modelo ng kredensyal at pahintulot para sa tungkuling iyon. Panatilihin ang forward at reverse record sa isang plano, dahil madalas silang pinapanatili ng magkaibang bahagi at ang isa ay karaniwang nakakalimutan.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

Ipinapakita ng unang utos kung aling mga address ang inaakala ng device na mayroon ito at kung nakatakda ang koneksyon na irehistro ang mga ito. Ang pangalawa at pangatlo ay naghahambing ng nireresolba ng kliyente sa aktuwal na itinatago ng zone, at hinihiwalay nito ang problema sa cache mula sa awtoritatibong problema.

Tatlong orasan, hindi isa

Ang paglathala at pag-refresh ay ang unang orasan: kailan inaanunsyo ng awtorisadong nag-a-update na nagbago ang address. Ang TTL ng cache ay ang pangalawa: gaano katagal maaaring itago ng resolver ang natanggap na sagot. Ang awtoritatibong paglilinis ay ang pangatlo: paano inaalis ang mga lipas na record ng proseso ng pagrerehistro o ng pagtanda at pagwawalis.

Ang mga orasang ito ay independiyente, at ang paghahalo sa kanila ay gumagawa ng mga pagwawastong hindi gumagana. Ang pagbabago sa isa ay hindi nakikita ng dalawa. Ang maikling TTL ay nagpapaikli ng buhay ng naka-cache na sagot at hindi nagbibigay ng anumang pahintulot sa pag-update. Ang pagwawalis ay nag-aalis ng mga record na hindi na-refresh, at hindi nito maaayos ang record na hindi kailanman isinulat ng tamang may-ari.

Itakda ang TTL ayon sa bilis na kailangang makita ng mga mambabasa ang pagbabago, at ang pagwawalis ayon sa tagal na dapat itago ng inabandunang device ang isang pangalan. Wala sa dalawang bilang na ito ang nagpapasya kung sino ang makakasulat ng record, at walang halaga ng TTL ang gumagawa sa paglalaan ng address na mga karapatan sa pangangasiwa ng DNS.

Magplano ng paglathala para sa gumagalang device

Magpasya kung aling mga interface ang kasali sa pagrerehistro. Ang address ng Wi-Fi sa bahay, address ng VPN at lumang address ng opisina ay naglilingkod sa magkaibang madla, at ang paglathala sa lahat ay gumagawa ng pangalang may ilang sagot na hindi pantay ang gamit. Irehistro lamang ang mga interface na tunay na naaabot ng inilaang mga mambabasa.

Panatilihin ang matatag na pangalan ng computer bilang pagkakakilanlan at ituring ang mga address bilang mga katangian nito. Panatilihin ang mga record ng pagtuklas ng domain na kailangan ng device, at huwag buong patayin ang pagrerehistro para ayusin ang problema sa doble-dobleng record na maaayos ng pagbabago ng pahintulot.

Isulat ang tagapaglaan, tagapag-update at may-ari ng paglilinis sa isang record, kasama ang mga inilaang mambabasa. Kapag muli nang tumuro ang pangalan sa maling address, sasabihin ng record na iyon kung sino sa tatlo ang unang suriin sa halip na simulang muli ang pagsisiyasat.