Ваш VPN надсилає три DNS-сервери: який із них відповідає?
Додаткові записи можуть бути резервом, маршрутом для окремого домену або залишком фізичного з'єднання. Зіставте кожен з областю дії, перш ніж називати список витоком.
Відкрийте сторінку налаштувань після підключення, і ви побачите три адреси DNS; питання аудиту — яка з них обробила ваш останній запит. Саме число нічого не вирішує, бо клієнтське розсилання, фізичний інтерфейс і політика для окремих доменів пишуть в одне й те саме подання. Ці записи мають різні області дії, і саме область, а не позиція, визначає, хто відповідає. Почніть із розділення джерел, потім перевірте той, якому належить важливе для вас ім'я.
Чому список довший за ваш профіль
VPN-клієнт розсилає адреси розпізнавача для тунельного з'єднання, а операційна система тримає їх поруч із тим, що вже мав фізичний інтерфейс. Маршрутизатор, корпоративна оренда DHCP, другий VPN і політика для окремих доменів додають кожен свій запис. Тому три адреси на сторінці можуть означати три області дії, а не три кандидати на одне завдання. Читати число як доказ витоку — перша помилка цього аудиту.
У межах одного інтерфейсу клієнт справді пробує свої сервери по порядку, тож упорядкований список не є безглуздим. Чергою не є об'єднане подання, де записи профілю, фізичного з'єднання й правил для окремих доменів стоять поруч без єдиного ранжування. Ця відмінність визначає, що ви перевіряєте: порядок пояснює поведінку в межах однієї області, а область пояснює все інше.
Зашифрований DNS ламає картину зсередини застосунку. Браузер або клієнт чату з власним розпізнавачем DNS-over-HTTPS надсилає запити повністю повз список операційної системи, тому адреси на сторінці налаштувань описують трафік, який застосунок ніколи не створював. Перевірте власне налаштування розпізнавача застосунку, перш ніж звинувачувати профіль у неправильно отриманому імені.
Що показує кожна з трьох перевірок
Кожне джерело залишає слід в іншому місці, і жодна команда не показує всі. Ось зіставлення, яке варто тримати поруч зі сторінкою налаштувань:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
У системі з systemd-resolved авторитетною є resolvectl status, бо вона повідомляє про DNS для кожного з'єднання разом із доменами маршрутизації. macOS відповідає через scutil --dns, яка перелічує розпізнавачі з областю в порядку їх спроб. Windows ділить дві половини: Get-DnsClientServerAddress для серверів за інтерфейсами і Get-DnsClientNrptPolicy для правил суфіксів. Запустіть команду, що належить фактично використовуваному розпізнавачу, бо на машині з середовищем контейнерів і настільним розпізнавачем може бути встановлено більше одного.
Резервний розпізнавач, який не може відповісти за вашу зону
Другий запис зазвичай існує для доступності, а доступність працює лише тоді, коли резерв знає імена. Запитайте публічний розпізнавач про внутрішнє ім'я хоста, і він поверне NXDOMAIN або відповідь за шаблоном із домену пошуку, що не має до вас жодного стосунку. Неперевірений резервний перехід тоді створює збій саме в той момент, коли він потрібен.
Split DNS існує, щоб цього не допустити: суфікси компанії йдуть до розпізнавача, який тримає зону, а публічні імена залишаються на стандартному шляху. Задум надійний, і він залежить від повноти списку суфіксів. Microsoft документує політику розпізнавача для кожного суфікса, яка керує цим у Windows, і та сама ідея проявляється як домени маршрутизації в systemd-resolved і як розпізнавачі з областю в macOS.
Порівняйте зони, за які резерв має право відповідати, із суфіксами в політиці. Це порівняння знаходить прогалину перш ніж користувач повідомить, що один внутрішній сайт перестав розв'язуватися після зміни тунелю.
Запитуйте через політику, а не в обхід неї
Запитуйте через розпізнавач операційної системи, бо прямий запит до сервера обходить політику і повідомляє лише те, що сказав би цей сервер. Різниця між двома відповідями і є вся суть:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Якщо системний запит повертає приватну адресу, а прямий запит повертає NXDOMAIN, політика працює, і слабке місце — резерв. Якщо обидва повертають ту саму публічну відповідь, ім'я розв'язується поза задуманою областю, і список суфіксів — те місце, куди слід дивитися. Збережіть обидва виводи, бо суперечка про розпізнавач вирішується швидше двома рядками, ніж знімком екрана сторінки налаштувань.
Потім перевірте шлях збою, бо резерв, який ніхто не тестував, — це припущення. Зробіть бажаний розпізнавач чорною дірою для одного запиту і подивіться, яка адреса повернеться:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Видаліть цей маршрут одразу після завершення запиту, інакше наступна людина успадкує загадку. Якщо в цьому вікні внутрішні імена все ще розв'язуються, на них відповіло щось поза задуманою областю. Якщо ж вони натомість завершуються тайм-аутом, резерв відсутній або правильно обмежений, і власний журнал розпізнавача скаже, що саме це було.
Вирішіть: залишити, обмежити чи видалити
Залиште другий розпізнавач, якщо він відповідає за потрібний вам простір імен і залишається доступним під профілем. Обмежте його областю, якщо він має бачити один суфікс і нічого більше, і видаліть його, якщо в нього немає ні області, ні задокументованої мети. Запис без роботи — майбутній витік без користі, а значення за замовчуванням від постачальника не є метою.
Запишіть результат у чотири стовпці: суфікс, розпізнавач, інтерфейс і власник. Цей рядок відповідає на наступне питання аудиту швидше за будь-який знімок екрана і переживає оновлення клієнта, яке тихо перевпорядковує список.