Hat de VPN DNS reparearre, of gewoan in beware antwurd werbrûkt?

In side iepenje sekonden nei’t de tunnel omheech komt is gjin bewiis dat DNS no wurket, ek al seit it ticket dat gewoanwei. Neat yn dy observaasje frege om in opfraach: de namme kin foar de feroaring oplost wêze en werbrûkt út in bewar dat de tunnel nea oanrekke hat. Twa ferskillende tests meitsje itselde skerm.

Ferlykje wat elke test eins oefene hat foardat jo de feroaring taskriuwe.

In side lade is gjin opfraach

Elke laach tusken de applikaasje en de oplosser mei in antwurd ûnthâlde foar syn libbensdoer. It bestjoeringssysteem hâldt ien, de browser hâldt syn eigen, en in applikaasje mei in langduorjende ferbining sil miskien yn de sesje nea wer wat oplosse. In lading dy’t nei in tunnelferoaring slagget, kin dêrom in demonstraasje fan ûnthâld wêze ynstee fan fan routing. It ûntbrekken fan in flater is net de oanwêzigens fan in opfraach.

Dat ferskil feroaret wat jo hjirnei testen moatte. As it doel is om te sjen te jaan dat de nije oplosser antwurdet, hawwe jo in opfraach nedich dy’t net út in bewar tsjinne wurde kin dat jo net leechmakke hawwe.

In bewarre súkses lêze as bewiis dat in earder ûnberikber tsjinner hersteld is, is de djoerste ferzje fan dizze flater, want it slút it ynsidint op in falske útgongspunt.

Telle de bewarren foardat jo konkludearje

Fjouwer binne it neamen wurdich: de eigen oplossing fan de applikaasje, it kliïntbewar fan it bestjoeringssysteem, de ynterne tastân fan de browser en de rekursive oplosser dy’t de opfraach úteinlik berikt. Elk hat in aparte libbensdoer en in aparte manier om leechmakke te wurden. Ien leechmeitsje en in oare testen is hoe’t minsken konkludearje dat it leechmeitsjen neat die. Ien leechmaakopdracht beslist de fraach nea.

Negative antwurden wurde ek bewarre. In namme dy’t as ûntbrekkend rapportearre waard, kin ûntbrekkend bliuwe nei’t it netwurk korrizjearre is, wat lêzen wurdt as in brutsen tunnel wylst it in TTL is dy’t net ferrûn is. De DNS-spesifikaasje beskriuwt hoe’t dizze gegevens hâlden en werbrûkt wurde moatte.

Skriuw de barren op, net de yndruk

Skriuw op hokker fan trije dingen feroare: it record, it paad nei de oplosser of in kliïntynstelling. In recordbewurking ferspriedt him neffens syn eigen skema, in rûteferoaring jildt by opnij ferbinen, en in browserynstelling jildt allinnich foar dy browser. Se gearfetsje ta ien foar-en-nei leveret in tiidline op dy’t nimmen kontrolearje kin.

Skriuw de tiid, de brûkte oplosser en it ûntfongen antwurd op, ek it gefal wêryn’t it antwurd negatyf is. Dat is in feit dat immen oars kontrolearje kin.

Doch de ferliking twa kear op deselde manier

Meitsje it bewar leech dat jo testen wolle, hâld de oarspronklike observaasje, en freegje dan op in manier dy’t safolle mooglik ûnthâld omseil. It neamen fan de oplosser seit wat dy oplosser wit; it seit net hokker oplosser de applikaasje keazen hawwe soe.

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

Under Windows makket it leechmeitsjen fan it kliïntbewar it DNS-kliïntbewar leech en neat oars. It beskriuwt gjin priveetastân fan in browser en makket gjin boppestreamtsjinner leech, dus in test dy’t dêrop boud is kin allinnich beheind ynterpretearre wurde. Sis hokker bewar jo leechmakke hawwe wannear’t jo it resultaat rapportearje.

Test dan de eigentlike applikaasje opnij mei in farsk fersyk en it bedoelde oplosserbelied aktyf. In resultaat dat ûnder in oar belied produsearre is, draacht net oer.