Dlaczego prywatna strefa Route 53 zwraca NXDOMAIN dla nazw publicznych

Prywatne strefy Route 53 zastępują odpowiedź dla nazwy, zamiast scalać ją z rekordem publicznym, i to zaskakuje ludzi w najgorszym momencie. Dodaj jeden rekord wewnętrzny dla api.example.net w prywatnej strefie dla example.net, powiąż ją z VPC, a każda inna nazwa pod tą nadrzędną będzie teraz odpowiadana wyłącznie z prywatnej strefy. Klient, który wczoraj mógł dotrzeć do www.example.net dziś otrzymuje odpowiedź negatywną. Poniższy opis zaczyna się od tego nieudanego zapytania i przechodzi na zewnątrz do strefy, która na nie odpowiedziała.

Zacznij od zapytania, nie od konsoli

Odtwórz błąd na kliencie, który go zgłosił, i zapisz dokładną nazwę oraz typ rekordu. Nazwa, która zawodzi dla A może nadal rozwiązywać się dla AAAA, a przeglądarka ponawiająca zapytanie o nazwę z pamięci podręcznej ukrywa, która z nich się zepsuła. Uruchom zapytanie dwa razy: raz przez resolver, którego klient naprawdę używa, i raz z tropieniem, które go omija.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Drugie polecenie jest tym ważnym. Jego wiersz stanu i sekcja authority wskazują strefę, która wytworzyła odpowiedź, więc możesz odróżnić odpowiedź negatywną z prywatnej strefy od przekroczenia czasu, zablokowanego portu lub resolvera, który nigdy nie otrzymał zapytania. resolvectl pokazuje, o który serwer nadrzędny zapytano, i często nie jest to resolver, o którym zakładałeś, że przesłał go VPN.

Jeśli zapytanie z tropieniem zwraca adres publiczny, a zwykłe nie, rekord publiczny jest nietknięty i odpowiada widok prywatny. To jedno porównanie decyduje, która połowa reszty tej strony cię dotyczy.

Przeczytaj, która strefa odpowiedziała

Odpowiedź niosąca NXDOMAIN z SOA strefy prywatnej w sekcji authority jest ostateczną odpowiedzią tej strefy, a nie nieudanym wyszukiwaniem. Route 53 Resolver wybrał prywatną strefę hostowaną, ponieważ nazwa się zgadzała, następnie nie znalazł rekordu żądanego typu, a udokumentowanym zachowaniem jest zwrócenie odpowiedzi negatywnej zamiast przekazania pytania do publicznego DNS.

Wybór podąża za szczegółowością. Przy kilku nakładających się prywatnych przestrzeniach nazw wygrywa najbardziej szczegółowa pasująca strefa, a szersza prywatna strefa nadrzędna nie dostaje drugiej szansy dla nazwy, której wybrana strefa podrzędna nie ma. Reguły przekazywania dodają kolejną warstwę, ponieważ reguła resolvera dla konkretnej domeny może wyprzedzić powiązanie prywatnej strefy hostowanej. Wypisz powiązania i reguły, zanim uznasz, że strefa jest pusta.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Oba polecenia wymagają danych logowania do konta, które posiada strefę, a drugie potrzebuje identyfikatora strefy z pierwszego. Zastąp go własnym; powyższy symbol zastępczy celowo nie jest prawdziwy.

Dlaczego wygrywa strefa prywatna

To powiązanie sprawia, że strefa jest widoczna dla VPC, a resolver w tej VPC je stosuje. Prywatna strefa niepowiązana z VPC, z której pochodzi ruch klienta, nie ma żadnego efektu, natomiast powiązanie z niewłaściwą VPC daje prywatną odpowiedź niewłaściwej populacji. Sprawdź listę powiązań przed edycją rekordów, bo strefa może być poprawna i mimo to niewidoczna.

Nakładające się przestrzenie nazw to drugie źródło zamieszania. Prywatna strefa dla example.net i prywatna strefa dla api.example.net obie pasują do zapytania API i odpowiada ta bardziej szczegółowa. Jest to przydatne, gdy chcesz wąskiej wewnętrznej przestrzeni nazw, i niebezpieczne, gdy w wąskiej strefie brakuje rekordu, który ma szersza. Rozważania dotyczące prywatnych stref hostowanych w dokumentacji Route 53 opisują zarówno zachowanie przechodzenia w dół, jak i pierwszeństwo reguł, i warto je przeczytać przed dodaniem drugiej nakładającej się strefy.

Nic z tego nie zmienia strefy publicznej. Publiczne resolvery nadal poprawnie odpowiadają na publiczne rekordy, i dlatego wszystkim spoza VPC błąd wygląda na problem klienta.

Wybierz przestrzeń nazw, zanim dodasz rekordy

Jeśli prywatne nazwy potrzebne są tylko nowej rodzinie usług wewnętrznych, daj jej dedykowaną prywatną subdomenę i zostaw publiczną strefę nadrzędną w spokoju. Nazwa taka jak internal.example.net nie może przesłonić www.example.net, a promień rażenia brakującego rekordu ogranicza się do nazw, które wymyśliłeś w tym celu. Kosztem jest to, że istniejące adresy URL i certyfikaty mogą nie pasować do nowej nazwy.

Gdy publiczni i prywatni użytkownicy muszą zachować tę samą nazwę hosta, DNS z widokiem dzielonym jest obsługiwanym projektem i wymaga, aby rekordy w każdym widoku były utrzymywane jawnie. Szeroka prywatna strefa z jednym rekordem nie zachowuje publicznych zależności pod tą strefą; zastępuje je strefą, która ma jeden rekord.

Przed skierowaniem populacji klientów do widoku prywatnego zinwentaryzuj nazwy, które aplikacja naprawdę wywołuje. Hosty logowania, hosty zasobów statycznych, cele przekierowań i punkty końcowe API psują się pierwsze, a zwykle są rozrzucone po rekordach kilku zespołów.

Prześledź ścieżkę resolvera, a potem trasę

Laptop widzi widok prywatny tylko wtedy, gdy jego zapytania docierają do resolvera, który ma powiązanie. Edycja pliku hosts na serwerze VPN niczego nie publikuje podłączonym klientom, a klient skonfigurowany z publicznym resolverem nadal będzie otrzymywać publiczne odpowiedzi, dopóki tunel jest aktywny. Potwierdź adres resolvera, który otrzymał klient, a następnie powtórz zapytanie z klienta, a nie z serwera.

Gdy nazwa się rozwiąże, sprawdź trasę do zwróconego adresu jako osobny krok, na przykład za pomocą ip route get przeciwko adresowi, który zwróciło zapytanie. Poprawna prywatna odpowiedź bez trasy do adresu to problem trasowania, a odpowiedź o brakującym rekordzie to problem widoku DNS; traktowanie ich jako jednego problemu daje poprawki, które się nie utrzymują. Pozostaw kontrole nazwy hosta TLS i certyfikatu usługi bez zmian, ponieważ prywatny adres zmienia, dokąd idzie połączenie, a nic w tym, który certyfikat jest ważny.

Zakończ, zapisując w notatce o zmianie strefę, powiązanie, resolver i zweryfikowane nazwy. Wtedy następna osoba dodająca rekord będzie wiedzieć, która przestrzeń nazw jest autorytatywna dla tej populacji klientów.