DNS latarni Nebula: kto może pytać o które rekordy?

Rola latarni w Nebuli wykonuje dużo pracy, którą ludzie uważają za automatyczną, a odpowiadanie na DNS nie należy do niej. Obsługa nazw to opcjonalny nasłuch, który startuje wyłączony, dlatego host, który dobrze rozwiązuje nazwy w overlay, może w ogóle nie mieć czym rozwiązać laptopa kolegi. Przed włączeniem zdecyduj, kto ma do niego dotrzeć i na jakie typy rekordów jesteś gotów odpowiadać, bo te dwie odpowiedzi się różnią.

Nasłuch jest opcjonalny i domyślnie wyłączony

Wykrywanie i DNS to osobne usługi. Latarnia pomaga peerom się odnajdywać i dodatkowo może odpowiadać na zapytania o nazwy hostów, które zna, ale ta druga część musi być wyraźnie włączona w konfiguracji.

Zdecyduj, które interfejsy i sieci mają docierać do nasłuchu, zanim cokolwiek włączysz. Usługa DNS odpowiadająca na interfejsie, którego nie zamierzałeś, staje się małym wyciekiem informacji bez jednego wpisu w logu, który ktoś przeczyta. Decyzja jest teraz znacznie tańsza niż późniejsze zawężanie, gdy coś zależy już od błędnej odpowiedzi. Dwie linijki konfiguracji łatwiej uzasadnić niż notatkę o incydencie za pół roku.

Rekordy A i TXT nie dzielą odbiorców

Na te dwa typy rekordów odpowiada się w różnych warunkach, a traktowanie ich jako jednej usługi jest błędem, któremu ten artykuł ma zapobiec.

Ta asymetria jest zamierzona, a nie przeoczeniem. Mapowanie nazwy na adres ma niewielką wartość dla osoby z zewnątrz, natomiast metadane certyfikatu opisują tożsamości w twoim overlayu. Nie przenoś założenia z jednego wiersza do drugiego tylko dlatego, że ten sam proces odpowiada na oba.

Odpowiada tylko o własnych hostach latarni

To nie jest ogólny resolver dla twojego biura, chmurowego VPC ani publicznego internetu. Latarnia odpowiada z informacji o hostach, które dostała, dlatego ta funkcja mieszka na węzłach latarni, a nie na każdym peerze.

Gdy nazwa zawodzi i overlay nie ma z tym nic wspólnego, znajdź strefę i resolver, które naprawdę nią zarządzają. Mieszanie resolvera overlay z ogólną konfiguracją DNS hosta daje awarie, które wyglądają losowo, bo niektóre nazwy się rozwiązują, a na inne nic nie odpowiada.

Zwróć też uwagę na punkt wejścia bootstrap. Nazwa hosta używana do dotarcia do pierwszej latarni musi się rozwiązać zwykłą ścieżką, zanim wykrywanie będzie mogło na niej polegać, więc problem jajka i kury wygląda tu dokładnie jak zepsuty overlay. Zgłasza się nawet w ten sam sposób: peer, który nigdy nie wstaje, i żadnego oczywistego powodu. Sprawdź rozwiązywanie nazw, zanim dotkniesz certyfikatów, bo ta kolejność łapie ludzi, którzy zaczęli od trudniejszej połowy.

Sprawdź adres nasłuchu, a potem testuj z zewnątrz

lighthouse.dns.host i lighthouse.dns.port decydują, gdzie nasłuchuje opcjonalna usługa. Przejrzyj te wartości razem z firewallem hosta i polityką sieciową, bo adres nasłuchu jest deklaracją intencji, a nie kontrolą bezpieczeństwa samą w sobie.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

Pytaj z sieci, które zamierzasz dopuścić, nie z samej latarni. Udane zapytanie na latarni dowodzi, że proces działa, i nie mówi ci nic o tym, o co może zapytać host zewnętrzny, a to jest pytanie, które naprawdę się liczy.

Ujawnij to świadomie

Nazwy i metadane certyfikatu to przydatna informacja operacyjna, a użyteczność tnie w obie strony. Zdecyduj, czy nasłuch ma być tylko dla overlaya, które typy rekordów dopuścić i kto przegląda konfigurację, gdy się zmienia.

Potem zapisz to obok ustawień latarni. Następna osoba, która będzie debugować awarię rozwiązywania, inaczej założy, że usługa była tam zawsze. Założy też, że zawsze była osiągalna z miejsca, w którym akurat testuje. Jeden akapit z adresem nasłuchu, dozwolonymi sieciami i typami rekordów oszczędza tej osobie popołudnie, a tobie wiadomość z pytaniem, dlaczego coś się zmieniło.