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 і нічого більше. Воно не описує приватний стан браузера й не очищає сервер вище за течією, тому тест, побудований на ньому, можна тлумачити лише вузько. Коли повідомляєте результат, кажіть, який кеш ви очистили.

Потім ще раз перевірте сам застосунок свіжим запитом і з активною потрібною політикою резолвера. Результат, отриманий за іншої політики, не переноситься.