Het die VPN DNS reggemaak, of net ’n gekaste antwoord hergebruik?

Om ’n bladsy oop te maak enkele sekondes nadat die tonnel opkom, is nie bewys dat DNS nou werk nie, al sê die tiket gewoonlik so. Niks in daardie waarneming het ’n opsoeking vereis nie: die naam is dalk voor die verandering opgelos en uit ’n kas hergebruik wat die tonnel nooit aangeraak het nie. Twee verskillende toetse lewer dieselfde skerm.

Vergelyk wat elke toets werklik gedoen het voordat jy die verandering as die oplossing beskou.

Om ’n bladsy te laai is nie ’n opsoeking nie

Elke laag tussen die toepassing en die oplosser mag ’n antwoord vir sy leeftyd onthou. Die bedryfstelsel hou een, die blaaier hou sy eie, en ’n toepassing met ’n langdurige verbinding mag gedurende die sessie nooit weer iets oplos nie. ’n Laai wat ná ’n tonnelverandering slaag, kan dus ’n bewys van geheue eerder as van roetering wees. Die afwesigheid van ’n fout is nie die teenwoordigheid van ’n opsoeking nie.

Daardie onderskeid verander wat jy volgende moet toets. As die doel is om te wys dat die nuwe oplosser antwoord, het jy ’n navraag nodig wat nie uit ’n kas bedien kan word wat jy nie skoongemaak het nie.

Om ’n gekaste sukses te lees as bewys dat ’n voorheen onbereikbare bediener herstel het, is die duurste weergawe van hierdie fout, want dit sluit die voorval op ’n valse veronderstelling.

Tel die kasse voordat jy aflei

Vier is die moeite werd om te noem: die toepassing se eie oplossing, die bedryfstelsel se kliëntkas, die blaaier se interne toestand, en watter rekursiewe oplosser die navraag uiteindelik bereik. Elkeen het ’n aparte leeftyd en ’n aparte manier om skoongemaak te word. Om een skoon te maak en ’n ander te toets, is hoe mense tot die gevolgtrekking kom dat die skoonmaak niks gedoen het nie. Een skoonmaakopdrag beslis nooit die vraag nie.

Negatiewe antwoorde word ook gekas. ’n Naam wat as ontbrekend gerapporteer is, kan ontbrekend bly nadat die netwerk reggestel is, wat as ’n gebreekte tonnel gelees word wanneer dit ’n TTL is wat nie verstryk het nie. Die DNS-spesifikasie beskryf hoe hierdie data bedoel is om gehou en hergebruik te word.

Teken die gebeurtenis aan, nie die indruk nie

Skryf neer watter van drie dinge verander het: die rekord, die pad na die oplosser, of ’n kliëntinstelling. ’n Rekordwysiging versprei op sy eie skedule, ’n roeteverandering tree in werking by herverbinding, en ’n blaaierinstelling geld net vir daardie blaaier. Om hulle in ’n enkele voor-en-na saam te voeg, lewer ’n tydlyn wat niemand kan oudit nie.

Let op die tyd, die oplosser wat gebruik word en die antwoord wat ontvang is, insluitend die geval waar die antwoord negatief is. Dit is ’n feit wat iemand anders kan nagaan.

Voer die vergelyking twee keer op dieselfde manier uit

Maak die kas skoon wat jy van plan is om te toets, hou die oorspronklike waarneming, en vra dan op ’n manier wat soveel geheue as moontlik omseil. Om die oplosser uitdruklik te noem, sê wat daardie oplosser weet; dit sê nie watter oplosser die toepassing sou gekies het nie.

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

Op Windows maak die skoonmaak van die kliëntkas die DNS-kliëntkas skoon en niks anders nie. Dit beskryf nie ’n blaaier se private toestand nie en maak nie ’n opstroombediener skoon nie, so ’n toets wat daarop bou, kan net eng vertolk word. Sê watter kas jy skoongemaak het wanneer jy die resultaat rapporteer.

Toets dan die werklike toepassing weer met ’n vars navraag en die beoogde oplosserbeleid aktief. ’n Resultaat wat onder ’n ander beleid geproduseer is, dra nie oor nie.