Неправильний DNS через VPN? Один авторитетний сервер може бути застарілим

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

Симптом змінюється разом із розв'язувачем

Рекурсивний розв'язувач повертає те, що йому сказало авторитетне джерело, а потім тримає цю відповідь протягом TTL. Якщо тунель нав'язує інший розв'язувач або змінює шлях так, що старий більше недоступний, клієнт питає інше авторитетне джерело й отримує іншу відповідь. Домен у цей момент не змінився; змінилося ваше уявлення про нього.

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

Розрізняльний тест — прямий запит до кожного опублікованого сервера.

Питайте кожне авторитетне джерело напряму

Починайте з делегування, а не зі списку, який пам'ятаєте. Запитайте в батьківського сервера набір NS, потім запитайте кожне ім'я з цього набору на потрібний вам запис. Два запити про одне ім'я до різних авторитетних джерел одразу показують, чи узгоджена зона.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Зробіть те саме для записів NS на вершині зони, бо після міграції делегування батьківського сервера й власний набір NS зони можуть розходитися. Серійні номери в SOA — наступне, що варто порівняти, а сильно відсталий вторинний сервер — це проблема передачі, а не відповіді.

Виконуйте ці запити з мережі, яка не працює, а не лише зі свого столу.

Відокремте навмисні подання від зламаних

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

Питання в тому, чи різниця задокументована й стабільна. Ненавмисне подання виглядає інакше: в одного авторитетного джерела є запис, якого інші ніколи не отримували, або немає того, який поділяють усі. Настанови RFC 2182 щодо вибору та розгортання розглядають авторитетну доступність як спільну відповідальність, і це правильна рамка тут. Резервування існує лише тоді, коли кожен опублікований сервер може відповісти наміченими даними, а не просто прийняти з'єднання на порту 53.

Сервер, що відповідає SERVFAIL, діагностувати легше, ніж той, що відповідає впевнено й неправильно.

Міграція розкриває те, що приховував кеш

Під час зміни провайдера змінюються два авторитетні місця: делегування батьківського сервера й власні записи NS зони. Обидва треба оновити, і обидва кешуються на час своїх TTL. Якщо старий сервер лишається ввімкненим і далі обслуговує попередню зону, клієнти, чиї розв'язувачі питають його, отримуватимуть стару відповідь ще довго після того, як перемикання виглядало завершеним.

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

Зміна розв'язувача на ноутбуці виправляє цей ноутбук і нічого більше.

Виправте зону, а не розв'язувач

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

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

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