A VPN kijavította a DNS-t, vagy csak újrahasznált egy gyorsítótárazott választ?

Egy oldal megnyitása másodpercekkel az alagút felállása után nem bizonyítja, hogy a DNS most működik, bár a jegy általában ezt állítja. Ebben a megfigyelésben semmi sem követelt lekérdezést: a név a változás előtt feloldódhatott, és egy olyan gyorsítótárból használódhatott újra, amelyet az alagút soha nem érintett. Két különböző teszt ugyanazt a képernyőt eredményezi.

Hasonlítsa össze, mit gyakorolt valójában az egyes tesztek, mielőtt a változásnak tulajdonítja a javulást.

Az oldal betöltése nem lekérdezés

Az alkalmazás és a feloldó közötti minden réteg élettartama alatt megjegyezhet egy választ. Az operációs rendszer tart egyet, a böngésző a sajátját tartja, és egy hosszú élettartamú kapcsolattal rendelkező alkalmazás a munkamenet során már semmit sem oldhat fel. Ezért egy alagútváltás után sikeres betöltés a memória, nem pedig az útválasztás bemutatása lehet. A hiba hiánya nem a lekérdezés jelenléte.

Ez a megkülönböztetés megváltoztatja, mit kellene legközelebb tesztelnie. Ha a cél annak bizonyítása, hogy az új feloldó válaszol, olyan lekérdezésre van szüksége, amelyet nem lehet kiszolgálni egy olyan gyorsítótárból, amelyet nem ürített ki.

Egy gyorsítótárazott sikert annak bizonyítékaként olvasni, hogy egy korábban elérhetetlen kiszolgáló helyreállt, ennek a hibának a legdrágább változata, mert hamis feltevésre zárja le az incidenst.

Számolja meg a gyorsítótárakat, mielőtt következtet

Négyet érdemes megnevezni: az alkalmazás saját feloldását, az operációs rendszer ügyfél-gyorsítótárát, a böngésző belső állapotát és azt a rekurzív feloldót, amelyhez a lekérdezés végül eljut. Mindegyiknek külön élettartama és külön ürítési módja van. Az egyik ürítése és a másik tesztelése az, ahogy az emberek arra jutnak, hogy az ürítés semmit sem tett. Egyetlen ürítőparancs soha nem dönti el a kérdést.

A negatív válaszokat is gyorsítótárazzák. Egy hiányzóként jelentett név a hálózat javítása után is hiányzó maradhat, amit törött alagútként olvasnak, pedig egy még le nem járt TTL. A DNS-specifikáció leírja, hogyan kell ezeket az adatokat tárolni és újrahasználni.

Az eseményt rögzítse, ne a benyomást

Írja le, hogy a három dolog közül melyik változott: a rekord, a feloldóhoz vezető útvonal vagy egy ügyfélbeállítás. A rekordszerkesztés a saját ütemezése szerint terjed, az útvonalváltozás újracsatlakozáskor lép életbe, és a böngészőbeállítás csak arra a böngészőre érvényes. Egyetlen előtte-utána állapotba sűrítésük olyan idővonalat ad, amelyet senki sem tud auditálni.

Jegyezze fel az időt, a használt feloldót és a kapott választ, beleértve azt az esetet is, amikor a válasz negatív. Ez olyan tény, amelyet másvalaki ellenőrizhet.

Végezze el az összehasonlítást kétszer, ugyanúgy

Ürítse ki a tesztelni kívánt gyorsítótárat, őrizze meg az eredeti megfigyelést, majd kérdezzen úgy, hogy a lehető legtöbb memóriát megkerülje. A feloldó név szerinti megnevezése megmondja, mit tud az a feloldó; nem mondja meg, melyik feloldót választotta volna az alkalmazás.

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

Windowson az ügyfél-gyorsítótár ürítése a DNS-ügyfél-gyorsítótárat üríti, és semmi mást. Nem írja le a böngésző privát állapotát, és nem üríti a felsőbb kiszolgálót, ezért a rá épülő teszt csak szűken értelmezhető. Mondja meg, melyik gyorsítótárat ürítette, valahányszor az eredményről beszámol.

Ezután tesztelje újra a tényleges alkalmazást friss kéréssel és a szándékolt feloldószabályzattal aktívan. Egy másik szabályzat alatt keletkezett eredmény nem vihető át.