Je li VPN popravio DNS ili je samo ponovo iskoristio keširani odgovor?
Stranica koja se učita nakon promjene tunela možda nikada nije izvršila upit. Uporedite keširane i svježe odgovore prije nego što popravku pripišete promjeni.
Otvaranje stranice nekoliko sekundi nakon što tunel proradi nije dokaz da DNS sada radi, iako tiket obično tako kaže. Ništa u tom zapažanju nije zahtijevalo upit: ime je možda razriješeno prije promjene i ponovo iskorišteno iz keša koji tunel nije dotakao. Dva različita testa daju isti ekran.
Uporedite šta je svaki test stvarno provjerio prije nego što promjenu proglasite zaslužnom.
Učitavanje stranice nije upit
Svaki sloj između aplikacije i razrješivača smije pamtiti odgovor tokom svog životnog vijeka. Operativni sistem drži jedan, preglednik drži svoj, a aplikacija s dugotrajnom vezom možda nikada više ništa ne razriješi tokom sesije. Uspješno učitavanje nakon promjene tunela stoga može biti demonstracija pamćenja, a ne rutiranja. Odsustvo kvara nije prisustvo upita.
Ta razlika mijenja ono što trebate testirati sljedeće. Ako je cilj pokazati da novi razrješivač odgovara, potreban vam je upit koji se ne može poslužiti iz keša koji niste očistili.
Čitati keširani uspjeh kao dokaz da se ranije nedostupno poslužiteljsko računalo oporavilo najskuplja je verzija ove greške, jer zatvara incident na pogrešnoj pretpostavci.
Prebrojte keševe prije zaključka
Četiri vrijedi imenovati: vlastito razrješavanje aplikacije, klijentski keš operativnog sistema, unutrašnje stanje preglednika i rekurzivni razrješivač do kojeg upit na kraju stigne. Svaki ima odvojen životni vijek i odvojen način čišćenja. Očistiti jedan i testirati drugi jeste način na koji ljudi zaključe da čišćenje nije ništa učinilo. Jedna naredba za čišćenje nikada ne rješava pitanje.
Negativni odgovori se također keširaju. Ime koje je prijavljeno kao nedostajuće može ostati nedostajuće nakon što se mreža ispravi, što se čita kao pokvaren tunel kad je to TTL koji nije istekao. DNS specifikacija opisuje kako se ti podaci trebaju čuvati i ponovo koristiti.
Zabilježite događaj, a ne dojam
Zapišite šta se od tri stvari promijenilo: zapis, putanja do razrješivača ili klijentska postavka. Izmjena zapisa širi se po vlastitom rasporedu, promjena rute djeluje pri ponovnom povezivanju, a postavka preglednika odnosi se samo na taj preglednik. Sažimanje toga u jedno prije-i-poslije stvara vremensku liniju koju nitko ne može provjeriti.
Zabilježite vrijeme, razrješivač u upotrebi i primljeni odgovor, uključujući slučaj kada je odgovor negativan. To je činjenica koju neko drugi može provjeriti.
Provedite poređenje dva puta na isti način
Očistite keš koji namjeravate testirati, zadržite izvorno zapažanje i zatim upitajte na način koji zaobilazi što je moguće više pamćenja. Izričito imenovanje razrješivača govori vam šta taj razrješivač zna; ne govori vam koji bi razrješivač aplikacija odabrala.
resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example
Na Windowsu čišćenje klijentskog keša briše keš DNS klijenta i ništa drugo. Ne opisuje privatno stanje preglednika i ne čisti poslužitelj uzvodno, pa se test izgrađen na njemu može tumačiti samo usko. Recite koji ste keš očistili kad god izvještavate o rezultatu.
Zatim ponovo testirajte stvarnu aplikaciju svježim zahtjevom i aktivnom namjeravanom politikom razrješivača. Rezultat dobijen pod drugom politikom ne prenosi se.