Ĉu la VPN riparis DNS-on, aŭ nur reuzis konservitan respondon?

Malfermi paĝon kelkajn sekundojn post kiam la tunelo ekfunkcias ne pruvas, ke DNS nun funkcias, kvankam la bileto kutime tion diras. Nenio en tiu observo postulis serĉon: la nomo eble estis solvita antaŭ la ŝanĝo kaj reuzita el kaŝmemoro, kiun la tunelo neniam tuŝis. Du malsamaj testoj produktas la saman ekranon.

Komparu, kion ĉiu testo efektive ekzercis, antaŭ ol atribui la sukceson al la ŝanĝo.

Ŝargi paĝon ne estas serĉo

Ĉiu tavolo inter la aplikaĵo kaj la solvilo rajtas memori respondon dum sia vivdaŭro. La operaciumo tenas unu, la retumilo tenas sian propran, kaj aplikaĵo kun longdaŭra konekto eble neniam plu solvos ion dum la seanco. Sukcesa ŝargo post tunela ŝanĝo do povas esti montrado de memoro prefere ol de enkursigo. La foresto de fiasko ne estas la ĉeesto de serĉo.

Tiu distingo ŝanĝas tion, kion vi devus testi poste. Se la celo estas montri, ke la nova solvilo respondas, vi bezonas serĉon, kiun oni ne povas servi el kaŝmemoro, kiun vi ne malplenigis.

Legi kaŝitan sukceson kiel pruvon, ke antaŭe neatingebla servilo resaniĝis, estas la plej multekosta versio de ĉi tiu eraro, ĉar ĝi fermas la okazaĵon sur falsa premiso.

Kalkulu la kaŝmemorojn antaŭ ol konkludi

Kvar indas nomi: la propra solvado de la aplikaĵo, la klienta kaŝmemoro de la operaciumo, la interna stato de la retumilo, kaj la rekursiva solvilo, kiun la serĉo fine atingas. Ĉiu havas apartan vivdaŭron kaj apartan manieron malplenigi. Malplenigi unu kaj testi alian estas kiel homoj konkludas, ke la malplenigo faris nenion. Unu malpleniga komando neniam solvas la demandon.

Ankaŭ negativaj respondoj estas kaŝmemorigataj. Nomo raportita kiel mankanta povas resti mankanta post kiam la reto estas korektita, kio legiĝas kiel rompita tunelo, kiam ĝi estas TTL, kiu ne eksvalidiĝis. La DNS-specifikaĵo priskribas, kiel ĉi tiuj datumoj devus esti tenataj kaj reuzataj.

Registru la okazaĵon, ne la impreson

Notu, kiu el tri aferoj ŝanĝiĝis: la rikordo, la vojo al la solvilo, aŭ klienta agordo. Redakto de rikordo disvastiĝas laŭ sia propra horaro, ŝanĝo de vojo efikas ĉe rekonekto, kaj retumila agordo validas nur por tiu retumilo. Kunfaldi ilin en unu antaŭ-kaj-post kreas templinion, kiun neniu povas revizii.

Notu la tempon, la uzatan solvilon kaj la ricevitan respondon, inkluzive de la kazo, kiam la respondo estas negativa. Tio estas fakto, kiun iu alia povas kontroli.

Faru la komparon dufoje sammaniere

Malplenigu la kaŝmemoron, kiun vi intencas testi, konservu la originan observon, kaj poste serĉu tiel, ke vi preterpasu kiel eble plej multe da memoro. Nomante la solvilon eksplicite vi ekscias, kion tiu solvilo scias; ĝi ne diras al vi, kiun solvilon la aplikaĵo estus elektinta.

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

En Windows, la malplenigo de la klienta kaŝmemoro malplenigas la DNS-klientan kaŝmemoron kaj nenion alian. Ĝi ne priskribas privatan staton de retumilo kaj ne malplenigas supran servilon, do testo bazita sur ĝi povas esti interpretata nur mallarĝe. Diru, kiun kaŝmemoron vi malplenigis, kiam ajn vi raportas la rezulton.

Poste retestu la faktan aplikaĵon per freŝa peto kaj la celita solvila politiko aktiva. Rezulto produktita sub malsama politiko ne transiĝas.