Поправи ли 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 клиента и нищо друго. То не описва частното състояние на браузъра и не изчиства сървър нагоре по веригата, така че тест, изграден върху него, може да се тълкува само тясно. Кажете кой кеш сте изчистили, когато съобщавате резултата.

След това тествайте отново самото приложение със свежа заявка и с активна желаната политика на резолвера. Резултат, получен при различна политика, не се пренася.