Ці VPN выправіў DNS, ці проста паўторна выкарыстаў кэшаваны адказ?
Старонка, якая загружаецца пасля змены тунеля, магла ніводнага разу не выканаць запыт. Параўнайце кэшаваныя і свежыя адказы, перш чым прыпісваць выпраўленне.
Адкрыццё старонкі праз некалькі секунд пасля ўзняцця тунеля не даказвае, што DNS цяпер працуе, хоць у заяўцы звычайна гаворыцца менавіта так. Нішто ў гэтым назіранні не патрабавала запыту: імя магло быць вырашана да змены і паўторна выкарыстана з кэша, якога тунель не кранаў. Два розныя тэсты даюць адзін і той жа экран.
Параўнайце, што насамрэч правяраў кожны тэст, перш чым прыпісваць змене поспех.
Загрузка старонкі — гэта не запыт
Кожны пласт паміж праграмай і рэзалверам можа помніць адказ на працягу свайго жыцця. Аперацыйная сістэма трымае адзін, браўзер трымае свой, а праграма з доўгім злучэннем можа болей нічога не вырашаць за сеанс. Таму паспяховая загрузка пасля змены тунеля можа быць дэманстрацыяй памяці, а не маршрутызацыі. Адсутнасць збою не азначае наяўнасць запыту.
Гэта розніца змяняе тое, што вам трэба праверыць далей. Калі мэта — паказаць, што новы рэзалвер адказвае, патрэбны запыт, які не можа быць абслужаны з кэша, які вы не ачысцілі.
Чытаць кэшаваны поспех як доказ таго, што раней недаступны сервер аднавіўся, — самы дарагі варыянт гэтай памылкі, бо ён зачыняе інцыдэнт на ілжывай пасылцы.
Палічыце кэшы, перш чым рабіць выснову
Варта назваць чатыры: уласнае вырашэнне праграмы, кліенцкі кэш аперацыйнай сістэмы, унутраны стан браўзера і той рэкурсіўны рэзалвер, якога запыт у рэшце рэшт дасягае. Кожны мае асобны тэрмін жыцця і асобны спосаб ачысткі. Ачысціць адзін і праверыць другі — гэта спосаб, якім людзі робяць выснову, што ачыстка нічога не дала. Адна каманда ачысткі ніколі не вырашае пытанне.
Адмоўныя адказы таксама кэшуюцца. Імя, якое было паведамлена як адсутнае, можа застацца адсутным пасля выпраўлення сеткі, і гэта чытаецца як зламаны тунель, калі насамрэч TTL яшчэ не скончыўся. Спецыфікацыя DNS апісвае, як гэтыя даныя павінны захоўвацца і паўторна выкарыстоўвацца.
Запішыце падзею, а не ўражанне
Запішыце, што менавіта з трох змянілася: запіс, шлях да рэзалвера або налада кліента. Змена запісу распаўсюджваецца па ўласным раскладзе, змена маршруту дзейнічае пры перападключэнні, а налада браўзера тычыцца толькі гэтага браўзера. Зліццё іх у адзінае «да і пасля» стварае графік, які ніхто не можа праверыць.
Адзначце час, выкарыстаны рэзалвер і атрыманы адказ, у тым ліку выпадак, калі адказ адмоўны. Гэта факт, які іншы чалавек можа праверыць.
Правядзіце параўнанне двойчы адным і тым жа спосабам
Ачысціце кэш, які вы збіраецеся праверыць, захавайце першапачатковае назіранне, а затым зрабіце запыт так, каб абысці як мага больш памяці. Яўнае называнне рэзалвера паказвае, што гэты рэзалвер ведае; яно не паказвае, які рэзалвер выбрала б праграма.
resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example
У Windows ачыстка кліенцкага кэша ачышчае кэш кліента DNS і нічога больш. Яна не апісвае прыватны стан браўзера і не ачышчае вышэйшы сервер, таму тэст, пабудаваны на ёй, можна тлумачыць толькі вузка. Калі паведамляеце вынік, кажыце, які кэш вы ачысцілі.
Затым паўторна праверце саму праграму свежым запытам і з актыўнай патрэбнай палітыкай рэзалвера. Вынік, атрыманы пры іншай палітыцы, не пераносіцца.