Înregistrările DNS ale clienților VPN: proprietar, TTL și curățare sunt separate

Laptopurile se conectează, primesc o adresă VPN, iar numele pe care îl rezolvă celelalte sisteme indică în continuare adresa de birou de ieri. Nimic nu a eșuat: o adresă a fost alocată, o înregistrare nu a fost actualizată și un cache păstrează încă răspunsul vechi. Sunt trei obiecte cu trei proprietari, iar doar unul dintre ele aparține VPN-ului. Planificarea publicării înseamnă să decizi cine scrie numele, ce interfețe participă și când dispar datele învechite.

Simptomul: un nume care urmează adresa greșită

De pe dispozitiv, tunelul este activ și adresa VPN răspunde. De pe stația de lucru a unui coleg, același nume de gazdă se rezolvă la o adresă privată pe care dispozitivul nu o mai are, așa că conexiunea expiră în fața unei mașini care s-a mutat. Înregistrarea este autoritativă și greșită, ceea ce este mai rău decât lipsa ei. Toți se bazează pe ea și nimeni nu se poate conecta.

Cazul invers este mai silențios: înregistrarea dispare și numele nu se mai rezolvă deloc. Ambele rezultate provin din aceeași lipsă de proiectare, iar niciunul nu se remediază prin scăderea TTL-ului. O durată mai mică a cache-ului schimbă cât timp supraviețuiește răspunsul greșit, nu dacă este scris.

Începeți prin a întreba care obiect este învechit. Adresa alocată de VPN, înregistrarea din zonă și răspunsul din cache-ul unui resolver au durate de viață și proprietari diferiți.

Trei obiecte, trei proprietari

VPN-ul deține alocarea adreselor și poate livra adresa dintr-un pool intern fără ca vreun schimb DHCP să ajungă la laptop. Zona DNS deține înregistrarea, iar modelul său de securitate decide cine o poate crea sau modifica. Cache-ul resolverului deține copia pe care o folosește acum un cititor, iar nimic din ce face dispozitivul nu poate ajunge acolo.

Presupunerea că o singură componentă face toate trei este locul unde proiectarea se rupe. O adresă care pare să vină dintr-un interval administrat nu dovedește că un server DHCP a făcut înregistrarea, iar o înregistrare reușită nu dovedește că cititorii și-au reîmprospătat cache-ul.

Cine poate actualiza înregistrarea

Într-o zonă integrată cu Active Directory și cu actualizări dinamice sigure, permisiunile trăiesc pe înregistrarea însăși. O înregistrare creată de un cont de serviciu DHCP poate să nu fie scriibilă de contul de computer al laptopului, iar schimbarea ulterioară a modelului de proprietate este o tranziție, nu un comutator. De aceea un conflict de proprietate supraviețuiește oricărei setări din partea clientului.

Îndrumările Microsoft despre actualizările dinamice preferă înregistrarea pe partea clientului pentru punctele finale hibride în domeniu. Adoptarea lor înseamnă transferarea deliberată a înregistrărilor existente, nu doar bifarea unei casete pe adaptorul VPN și speranța că vechiul proprietar va ceda.

Când un serviciu DHCP trebuie să înregistreze alte clase de dispozitive, dați-i modelul de acreditări și permisiuni acceptat pentru acel rol. Păstrați înregistrările directe și inverse în același plan, pentru că sunt adesea întreținute de componente diferite și una dintre ele este de obicei uitată.

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

Prima comandă arată ce adrese crede dispozitivul că are și dacă conexiunea este setată să le înregistreze. A doua și a treia compară ce rezolvă un client cu ce stochează de fapt zona, iar asta separă o problemă de cache de una autoritativă.

Trei ceasuri, nu unul

Publicarea și reîmprospătarea sunt primul ceas: când actualizatorul autorizat anunță că o adresă s-a schimbat. TTL-ul cache-ului este al doilea: cât timp poate un resolver să păstreze răspunsul primit. Curățarea autoritativă este al treilea: cum sunt eliminate înregistrările învechite de procesul de înregistrare sau de îmbătrânire și măturare.

Aceste ceasuri sunt independente, iar confundarea lor produce corecții care nu funcționează. O schimbare la unul este invizibilă pentru celelalte două. Un TTL scurt scurtează viața unui răspuns din cache și nu acordă nicio permisiune de actualizare. Măturarea elimină înregistrările care nu au fost reîmprospătate și nu poate repara o înregistrare pe care proprietarul corect nu a scris-o niciodată.

Setați TTL-ul după cât de repede trebuie cititorii să vadă o schimbare, iar măturarea după cât timp trebuie un dispozitiv abandonat să păstreze un nume. Niciunul dintre cele două numere nu decide cine poate scrie înregistrarea, iar nicio valoare TTL nu transformă alocarea adreselor în drepturi de administrare DNS.

Planificați publicarea pentru un dispozitiv aflat în mișcare

Decideți ce interfețe participă la înregistrare. O adresă Wi-Fi de acasă, o adresă VPN și o adresă veche de birou servesc publicuri diferite, iar publicarea tuturor produce un nume cu mai multe răspunsuri de utilitate inegală. Înregistrați interfețele pe care cititorii vizați le pot atinge cu adevărat.

Păstrați numele stabil al computerului ca identitate și tratați adresele ca atribute ale acestuia. Păstrați înregistrările de descoperire a domeniului de care are nevoie dispozitivul și nu dezactivați înregistrarea în bloc pentru a rezolva o problemă de înregistrări duplicate pe care o schimbare de permisiuni ar rezolva.

Scrieți alocatorul, actualizatorul și proprietarul curățării într-o singură înregistrare, cu cititorii vizați numiți. Când numele indică din nou adresa greșită, acea înregistrare vă spune pe care dintre cei trei să-l inspectați primul în loc să reluați ancheta de la zero.