NXDOMAIN через VPN не означає збою тунелю

Спокусливо прочитати один невдалий запит як доказ того, що тунель зазнав краху, особливо якщо ім'я працювало десять хвилин тому. Відповідь каже інше. NXDOMAIN — це завершена транзакція DNS, у якій розв'язувач заявив, що запитане ім'я не існує; зламаний тунель зазвичай дає тишу, тайм-аут або спробу розв'язання через неправильний сервер. Версія аргументу без wireshark — це один запит, один відповідач і один код відповіді, і цю трійку варто зафіксувати до будь-яких змін конфігурації.

Що насправді доводить відповідь

DNS розділяє результати, які клієнти часто зводять до однієї помилки. Неіснуюче ім'я дає негативну відповідь із кодом NXDOMAIN, а ім'я, що існує, але не має запису запитаного типу, дає успішну відповідь із порожнім розділом відповіді. Для застосунку обидва виглядають як щось непотрібне, і лише один із них означає, що ім'я неправильне.

Ця різниця вирішує, де має бути виправлення. Відсутній запис AAAA на хості, який має запис A, не означає відсутнього хоста, а перевипуск сертифіката або перебудова тунелю в гонитві за цим марнує єдину доступну підказку. Різниця також задає форму подальших дій: проблема імені виправляється в зоні, а проблема типу виправляється запитом правильного запису або визнанням того, що сімейство адрес просто відсутнє.

Міф: відсутнє приватне ім'я означає, що тунель не спрацював

Міф живе тому, що ці дві події так часто приходять разом. Клієнт підключається до VPN, операційна система зберігає розв'язувач, якому вже довіряла, і внутрішнє ім'я, яке тепер потрібне, запитується в сервера, що ніколи не чув про приватну зону. Цей сервер відповідає чесно й негативно. Тунель несе пакет; відповідь просто про простір імен, який відповідач не обслуговує.

Конфігурації split-horizon роблять це звичною справою: те саме ім'я зони існує публічно й усередині з різним вмістом, і лише внутрішній розв'язувач знає приватні записи. Тому отримання негативної відповіді, що виглядає авторитетною, — це доказ того, який розв'язувач відповів, а не доказ стану інтерфейсу.

Результат визначають дві деталі конфігурації. Тунель має проштовхнути або вибрати внутрішній розв'язувач, і клієнт має застосувати цей вибір до шуканого імені. Правило для окремого домену, яке називає суфікс, трохи відмінний від введеного запису, відправить запит публічним шляхом, і відповідь буде правильною та марною.

Питайте правильний розв'язувач із правильним ім'ям

Записуйте відповідача раніше, ніж записуєте вердикт. Запит, який не показує, який сервер відповів, не може відрізнити проблему політики від проблеми простору імен, а їхні виправлення не пов'язані.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Перші два рядки показують, що вирішив локальний розв'язувач і кого він запитає. Запит +search відтворює те, що робить застосунок, додаючи суфікс пошуку, і це часто справжній запит, а не той, що введено в діагностичному інструменті. Останній рядок питає внутрішній сервер напряму, обходячи політику клієнта; якщо це вдається, а звичайний запит зазнає невдачі, зона гаразд, а маршрутизація запитів — ні.

Негативне кешування пояснює затримку після виправлення

Негативні відповіді кешуються за задумом, і RFC 2308 описує, як час життя негативного кешу виводиться із запису повноважень зони. Тому виправлення запису або правила розв'язувача не гарантує негайної зміни на клієнті, а повтор запиту, який і далі повертає кешовану відповідь, нічого нового не доводить. Лише інший відповідач, інше ім'я або очищений кеш дають свіжі докази.

Очистіть локальний кеш, потім повторіть той самий запит до того самого відповідача. У системах із локальною службою розв'язувача це одна команда; в інших це перезапуск служби або утиліта платформи, і конкретний інструмент менш важливий, ніж повторення після цього ідентичного тесту.

Відокремте ім'я від шляху

Щойно ім'я розв'язується в очікувану приватну адресу, DNS як тема завершується, і наступним питанням стає шлях застосунку. Хост, який відповідає на запити, але відмовляє в з'єднанні, має іншу проблему, і продовжувати налаштовувати розв'язувачі після правильної відповіді — це спосіб, у який інцидент набуває трьох не пов'язаних змін. Порівняйте розв'язану адресу з тією, на якій служба насправді слухає, перш ніж вважати, що вони збігаються.

Зберігайте запис: запит, відповідач, код і розв'язану адресу. Цей запис також робить перевірюваним пізніший звіт, і він — різниця між діагнозом та історією про тунель, що здавався повільним.