Inayos ba ng VPN ang DNS, o ginamit lang muli ang naka-cache na sagot?

Ang pagbubukas ng pahina ilang segundo matapos umangat ang tunnel ay hindi patunay na gumagana na ang DNS, kahit karaniwang sinasabi ito ng tiket. Wala sa obserbasyong iyon ang nangangailangan ng tanong: maaaring naresolba ang pangalan bago ang pagbabago at muling ginamit mula sa cache na hindi kailanman hinawakan ng tunnel. Dalawang magkaibang pagsubok ang gumagawa ng parehong screen.

Ihambing kung ano ang tunay na sinanay ng bawat pagsubok bago iugnay ang pagbabago.

Ang pag-load ng pahina ay hindi tanong

Bawat layer sa pagitan ng application at resolver ay pinapayagang tandaan ang sagot sa buong buhay nito. Ang operating system ay may isa, ang browser ay may sarili, at ang application na may pangmatagalang koneksyon ay maaaring hindi na muling magresolba ng anuman sa session. Kaya ang matagumpay na pag-load pagkatapos ng pagbabago ng tunnel ay maaaring pagpapakita ng memorya at hindi ng routing. Ang kawalan ng pagkabigo ay hindi pagkakaroon ng tanong.

Binabago ng pagkakaibang iyon ang dapat mong subukan sa susunod. Kung ang layunin ay ipakita na sumasagot ang bagong resolver, kailangan mo ng tanong na hindi maihahatid mula sa cache na hindi mo nilinis.

Ang basahin ang naka-cache na tagumpay bilang patunay na ang server na dating hindi maabot ay nakabawi ay ang pinakamahal na bersyon ng pagkakamaling ito, dahil isinasara nito ang insidente sa maling palagay.

Bilangin ang mga cache bago magpasya

Apat ang dapat pangalanan: ang sariling resolusyon ng application, ang client cache ng operating system, ang panloob na estado ng browser, at anumang recursive resolver na narating ng tanong sa huli. Bawat isa ay may hiwalay na buhay at hiwalay na paraan ng paglinis. Ang linisin ang isa at subukan ang iba ay ang paraan ng paghihinuha ng mga tao na walang ginawa ang paglinis. Isang utos ng paglinis ang hindi kailanman nagtatapos ng usapin.

Ang mga negatibong sagot ay naka-cache din. Ang pangalang iniulat na wala ay maaaring manatiling wala pagkatapos ayusin ang network, na binabasa bilang sirang tunnel kapag ito ay TTL na hindi pa nag-expire. Inilalarawan ng detalye ng DNS kung paano dapat itago at gamitin muli ang datos na ito.

Itala ang pangyayari, hindi ang impresyon

Isulat kung alin sa tatlong bagay ang nagbago: ang record, ang daan patungo sa resolver, o isang setting ng client. Ang pag-edit ng record ay kumakalat ayon sa sariling iskedyul, ang pagbabago ng ruta ay nagkakabisa sa muling pagkonekta, at ang setting ng browser ay nalalapat lamang sa browser na iyon. Ang pagsama sa kanila sa isang before-and-after ay gumagawa ng timeline na walang makakapag-audit.

Itala ang oras, ang ginamit na resolver at ang natanggap na sagot, kabilang ang kaso kung negatibo ang sagot. Iyon ay katotohanang maaaring tiyakin ng iba.

Gawin ang paghahambing nang dalawang beses sa parehong paraan

Linisin ang cache na balak mong subukan, itago ang orihinal na obserbasyon, pagkatapos ay magtanong sa paraang lumalampas sa pinakamaraming memorya. Ang tahasang pagpangalan sa resolver ay nagsasabi kung ano ang alam ng resolver na iyon; hindi nito sinasabi kung aling resolver ang pipiliin ng application.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Sa Windows, ang paglinis ng client cache ay naglilinis ng DNS client cache at wala nang iba. Hindi nito inilalarawan ang pribadong estado ng browser at hindi naglilinis ng upstream server, kaya ang pagsubok na binuo dito ay maiintindihan lamang nang makitid. Sabihin kung aling cache ang nilinis mo tuwing iniuulat mo ang resulta.

Pagkatapos ay subukan muli ang aktwal na application gamit ang bagong kahilingan at ang nilalayong patakaran ng resolver na aktibo. Ang resultang ginawa sa ilalim ng ibang patakaran ay hindi naililipat.