VPN klientu DNS ieraksti: īpašnieks, TTL un tīrīšana ir atsevišķas lietas

Klēpjdatori pieslēdzas, saņem VPN adresi, un vārds, ko atrisina citas sistēmas, joprojām norāda uz vakardienas biroja adresi. Nekas neizgāzās: adrese tika piešķirta, ieraksts netika atjaunināts, un kešatmiņa joprojām tur veco atbildi. Tie ir trīs objekti ar trim īpašniekiem, un tikai viens no tiem pieder VPN. Publicēšanas plānošana nozīmē izlemt, kas raksta vārdu, kuras saskarnes piedalās un kad pazūd novecojuši dati.

Simptoms: vārds, kas seko nepareizajai adresei

No ierīces tuneļa ir uzcelts un VPN adrese atbild. No kolēģa darbstacijas tas pats resursdatora vārds tiek atrisināts uz privātu adresi, kuras ierīcei vairs nav, tāpēc savienojums beidzas ar taimautu pret mašīnu, kas ir pārvietota. Ieraksts ir autoritatīvs un nepareizs, kas ir sliktāk nekā tā trūkums. Visi tam uzticas un neviens nevar pieslēgties.

Pretējais gadījums ir klusāks: ieraksts pazūd un vārds vispār vairs neatrisinās. Abi iznākumi nāk no tās pašas dizaina nepilnības, un nevienu neizlabo TTL samazināšana. Īsāks kešatmiņas mūžs maina to, cik ilgi nepareizā atbilde izdzīvo, nevis vai tā tiek rakstīta.

Sāciet ar jautājumu, kurš objekts ir novecojis. VPN piešķirtajai adresei, ierakstam zonā un atbildei atrisinātāja kešatmiņā ir atšķirīgi mūži un atšķirīgi īpašnieki.

Trīs objekti, trīs īpašnieki

Adrešu piešķiršana pieder VPN, un tas var izsniegt adresi no iekšējā kopuma, nevienai DHCP apmaiņai nesasniedzot klēpjdatoru. Ieraksts pieder DNS zonai, un tās drošības modelis izlemj, kas to drīkst izveidot vai mainīt. Kopija, ko lasītājs pašlaik izmanto, pieder atrisinātāja kešatmiņai, un nekas, ko ierīce dara, tai nevar piekļūt.

Pieņēmums, ka viena komponente dara visus trīs, ir vieta, kur dizains lūzt. Adrese, kas izskatās nākam no pārvaldīta diapazona, nepierāda, ka DHCP serveris veica reģistrāciju, un veiksmīga reģistrācija nepierāda, ka lasītāji atjaunināja savu kešatmiņu.

Kas drīkst atjaunināt ierakstu

Zonā, kas integrēta ar Active Directory un kam ir droši dinamiskie atjauninājumi, atļaujas dzīvo pašā ierakstā. DHCP pakalpojuma konta izveidotu ierakstu var nevarēt rakstīt klēpjdatora datora konts, un īpašumtiesību modeļa vēlāka maiņa ir pāreja, nevis slēdzis. Tāpēc īpašumtiesību konflikts pārdzīvo jebkuru klienta puses iestatījumu.

Microsoft dinamisko atjauninājumu vadlīnijas dod priekšroku klienta puses reģistrācijai domēnam pievienotiem hibrīdajiem galapunktiem. To pieņemt nozīmē apzināti pārnest esošos ierakstus, nevis vienkārši atzīmēt ķeksīti VPN adapterī un cerēt, ka vecais īpašnieks piekāpsies.

Kur DHCP pakalpojumam jāreģistrē citas ierīču klases, dodiet tam attiecīgajai lomai atbalstīto akreditācijas datu un atļauju modeli. Turiet tiešos un apgrieztos ierakstus vienā plānā, jo tos bieži uztur dažādas komponentes un viens no tiem parasti tiek aizmirsts.

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

Pirmā komanda parāda, kuras adreses ierīce uzskata, ka tai ir, un vai savienojums ir iestatīts tās reģistrēt. Otrā un trešā salīdzina, ko klients atrisina, ar to, ko zona patiešām glabā, un tas atdala kešatmiņas problēmu no autoritatīvas problēmas.

Trīs pulksteņi, ne viens

Publicēšana un atjaunināšana ir pirmais pulkstenis: kad pilnvarotais atjauninātājs paziņo, ka adrese ir mainījusies. Kešatmiņas TTL ir otrais: cik ilgi atrisinātājs drīkst turēt saņemto atbildi. Autoritatīvā tīrīšana ir trešais: kā novecojušie ieraksti tiek noņemti reģistrācijas procesā vai novecošanas un tīrīšanas ceļā.

Šie pulksteņi ir neatkarīgi, un to sajaukšana rada labojumus, kas nedarbojas. Izmaiņas vienā nav redzamas pārējiem diviem. Īss TTL saīsina kešotās atbildes mūžu un nepiešķir nekādas atjaunināšanas tiesības. Tīrīšana noņem ierakstus, kas netika atjaunināti, un tā nevar salabot ierakstu, ko nekad nav rakstījis pareizais īpašnieks.

Iestatiet TTL pēc tā, cik ātri lasītājiem jāredz izmaiņas, un tīrīšanu pēc tā, cik ilgi pamesta ierīce drīkst turēt vārdu. Neviens no šiem skaitļiem neizlemj, kas drīkst rakstīt ierakstu, un neviena TTL vērtība nepārvērš adrešu piešķiršanu DNS administrēšanas tiesībās.

Plānojiet publicēšanu klejojošai ierīcei

Izlemiet, kuras saskarnes piedalās reģistrācijā. Mājas Wi-Fi adrese, VPN adrese un vecā biroja adrese apkalpo dažādas auditorijas, un visu publicēšana rada vārdu ar vairākām nevienlīdzīgi noderīgām atbildēm. Reģistrējiet tās saskarnes, kuras paredzētie lasītāji patiešām var sasniegt.

Turiet stabilo datora vārdu kā identitāti un uzskatiet adreses par tā atribūtiem. Saglabājiet domēna atklāšanas ierakstus, kas ierīcei nepieciešami, un neizslēdziet reģistrāciju pilnībā, lai atrisinātu dubultu ierakstu problēmu, ko atrisinātu atļauju maiņa.

Ierakstiet piešķīrēju, atjauninātāju un tīrīšanas īpašnieku vienā ierakstā, nosaucot paredzētos lasītājus. Kad vārds atkal norāda uz nepareizo adresi, šis ieraksts pateiks, kuru no trim pārbaudīt vispirms, nevis sākt izmeklēšanu no jauna.