Zły DNS przez VPN? Jeden serwer autorytatywny może być nieaktualny

Połącz się z VPN i jedna nazwa hosta rozwiązuje się na wczorajszy adres albo na nic. Rozłącz się i znów działa. Odruch każe winić resolver narzucony przez tunel, ale częstszą przyczyną jest opublikowany serwer nazw, który przestał otrzymywać aktualizacje strefy. Nowa trasa po prostu dotarła do innego autorytetu niż ten, z którego pochodziła odpowiedź z pamięci podręcznej.

Objaw zmienia się wraz z resolverem

Resolver rekurencyjny zwraca to, co powiedział mu autorytet, a następnie trzyma tę odpowiedź przez TTL. Jeśli tunel narzuci inny resolver albo zmieni trasę tak, że stary nie jest już osiągalny, klient pyta inny autorytet i dostaje inną odpowiedź. Domena nie zmieniła się w tej chwili; zmienił się twój obraz jej.

Dlatego ta sama nazwa może działać w jednym biurze, a zawodzić z hotelu, i dlatego czyszczenie lokalnej pamięci podręcznej pomaga tylko czasami. Czyszczenie pamięci wysyła pytanie ponownie do tego samego autorytetu.

Testem rozstrzygającym jest bezpośrednie zapytanie do każdego opublikowanego serwera.

Pytaj każdy autorytet bezpośrednio

Zacznij od delegacji, a nie od listy, którą pamiętasz. Zapytaj rodzica o zbiór NS, a następnie odpytaj każdą nazwę z tego zbioru o rekord, którego potrzebujesz. Dwa zapytania o tę samą nazwę do różnych autorytetów od razu pokazują, czy strefa jest spójna.

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

Zrób to samo dla rekordów NS w szczycie strefy, ponieważ delegacja rodzica i własny zbiór NS strefy mogą się różnić po migracji. Numery seryjne w SOA to następna rzecz do porównania, a mocno opóźniony serwer wtórny to problem transferu, nie odpowiedzi.

Wykonuj te zapytania z sieci, która zawodzi, nie tylko ze swojego biurka.

Oddziel widoki zamierzone od zepsutych

Niektóre domeny celowo odpowiadają inaczej w zależności od regionu lub grupy resolverów, a konfiguracje z podzielonym horyzontem są normalne w sieciach firmowych.

Pytanie brzmi, czy różnica jest udokumentowana i stabilna. Niezamierzony widok wygląda inaczej: jeden autorytet ma rekord, którego pozostałe nigdy nie otrzymały, albo brakuje mu tego, który wszystkie dzielą. Wskazówki RFC 2182 dotyczące wyboru i wdrażania traktują dostępność autorytatywną jako wspólną odpowiedzialność, i to jest tutaj właściwe ramy. Nadmiarowość istnieje tylko wtedy, gdy każdy opublikowany serwer potrafi odpowiedzieć zamierzonymi danymi, a nie tylko przyjąć połączenie na porcie 53.

Serwer odpowiadający SERVFAIL łatwiej zdiagnozować niż ten, który odpowiada pewnie i błędnie.

Migracja ujawnia to, co ukryła pamięć podręczna

Podczas przenoszenia dostawcy zmieniają się dwa miejsca autorytatywne: delegacja rodzica i własne rekordy NS strefy. Oba trzeba zaktualizować, a oba są buforowane na czas swoich TTL. Jeśli stary serwer pozostanie włączony i nadal będzie obsługiwał poprzednią strefę, klienci, których resolvery go pytają, będą nadal dostawać starą odpowiedź długo po tym, jak przełączenie wyglądało na zakończone.

Dokładnie ten stan ukrywa długowieczna pamięć podręczna. Stacja robocza, która działała cały tydzień, rozmawiała z resolverem trzymającym świeżą odpowiedź od nowego autorytetu, podczas gdy stary nadal rozdawał nieaktualne dane wszystkim innym.

Zmiana resolvera na laptopie naprawia ten laptop i nic więcej.

Napraw strefę, nie resolver

Ustal, które serwery mają być autorytatywne dla strefy, popraw zarządzaną strefę lub delegację tak, aby każdy z nich serwował zamierzone dane, i zachowaj zaplanowaną nadmiarowość. Usunięcie serwera nazw, bo jedno wyjście VPN dostało dziwną odpowiedź, zmniejsza dostępność i zostawia niespójność na miejscu.

Następnie ponownie wykonaj bezpośrednie zapytania z obu sieci i poczekaj na wygaśnięcie TTL zmienionego rekordu.

Potwierdź, że odpowiedź jest stabilna z każdego autorytetu, i zapisz zamierzony widok w dokumentacji strefy, aby następną różnicę łatwo było sklasyfikować.