Dlaczego rekord SRV pomaga tylko klientowi, który sam o niego pyta

Dodanie rekordu SRV do strefy nie uczy żadnego klienta VPN, jak go szukać. Klient musi znać etykietę, zdecydować się wysłać zapytanie i działać według tego, co wróci, a DNS nie może zapewnić pierwszych dwóch rzeczy. Dlatego większość nieudanych planów SRV to problemy klienta w przebraniu DNS. Najpierw przeczytaj zachowanie klienta przy wykrywaniu, a potem publikuj tylko tę etykietę, o którą naprawdę pyta.

Rekord, o który nikt nie pyta, nikomu nie pomoże

SRV publikuje lokalizację usługi; nie ogłasza jej. Nic nie popycha rekordu do klienta i żaden resolver nie oferuje nazwy, o którą nigdy nie pytano. Wyszukiwanie zaczyna się, gdy aplikacja decyduje się je wykonać, więc etykieta musi pochodzić z dokumentacji produktu lub z obserwacji oprogramowania w sieci. Tam, gdzie klient nie ma kroku wykrywania, rekord zmienia strefę i nic więcej.

Dlatego jeden produkt w sieci może zacząć działać, podczas gdy inny nie jest dotknięty tą samą zmianą. Zmienną jest oprogramowanie, a serwer DNS robi dokładnie to, co mu powiedziano. Po edycji odczytaj strefę ponownie, ponieważ błędnie wpisana etykieta łatwo ukrywa się wśród rekordów, które wszystkie wyglądają tak samo.

Przeczytaj pola, zanim je zapiszesz

Rekord niesie cztery wartości i każda odpowiada na inne pytanie: priorytet porządkuje cele, które klient może wypróbować, waga dzieli obciążenie między cele o równej wartości priorytetu, port nazywa port transportowy, a cel nazywa hosta. Specyfikacja pozwala też, aby cel . oznaczał, że usługa jest celowo niedostępna, co jest przydatną odpowiedzią, a nie zepsutą.

Żadne z tych pól nie niesie poświadczeń, polityki certyfikatów ani wersji aplikacji, a klient, który ignoruje wagę, nadal się łączy, tylko bez zamierzonej równowagi. Cel potrzebuje własnych rekordów adresowych i powinien być nazwą kanoniczną, a nie aliasem. Opublikowanie rekordu wskazującego hosta bez nasłuchu daje błąd połączenia, który czyta się jak usterka DNS, a to najdroższy rodzaj wprowadzania w błąd. Opublikuj cały łańcuch albo nic z niego.

Znajdź etykietę, którą klient naprawdę wysyła

Ustal etykietę na podstawie dowodów, a nie domysłu o nazwie produktu. Albo dokumentacja podaje nazwę usługi, albo zrzut pokazuje zapytanie wychodzące z klienta przy starcie. Obie drogi kończą się w tym samym miejscu: dokładna nazwa i typ do sprawdzenia u resolvera.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Porównaj odpowiedź z opublikowanym rekordem znak po znaku, bo podkreślenia i kropka na końcu są częścią nazwy. Pusta odpowiedź na zapytanie, które naprawdę wysłano, wskazuje na strefę, a całkowity brak zapytania wskazuje na klienta, i te ustalenia kierują do różnych zespołów. Prawdziwa odpowiedź wygląda jak wiersz poniżej, gdzie priorytet 20 przegrywa z każdym rekordem o niższym priorytecie, a klient wybiera port 8443 na wskazanym celu.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Cel także musi istnieć

Cel, który się rozwiązuje, to nie to samo co usługa, która odpowiada. Sprawdź rekordy adresowe celu, a następnie sprawdź, czy coś nasłuchuje na opublikowanym porcie i protokole. Rekord TCP wskazujący na odbiornik tylko UDP to niezgodność, której nie naprawi żadna edycja strefy. Trzymaj TTL krótki, dopóki cel jest w ruchu, i wydłuż go, gdy nazwa przestanie się przemieszczać.

Klienci, którzy naprawdę implementują wykrywanie, różnią się tym, ile z rekordu respektują. Niektórzy używają tylko priorytetu, inni traktują wagę jako wskazówkę, a kilku ignoruje port i zakłada wartość domyślną. Te różnice należą do twoich notatek obok etykiety, ponieważ wyjaśniają zachowanie, które inaczej wygląda jak usterka resolvera.

Wykrywanie nie jest uwierzytelnianiem

Odpowiedź SRV mówi, gdzie się połączyć, i nie mówi nic o tym, komu zaufać po przybyciu. Zostaw walidację certyfikatu i kontrole tożsamości serwera w kliencie dokładnie takie, jakie były, bo rekord, który ktoś inny może sfałszować, nie powinien stać się decyzją o zaufaniu. Odpowiedzi DNS można buforować i edytować przez każdego, kto kontroluje strefę, co czyni je złym miejscem do kodowania polityki.

Dla klienta bez obsługi wykrywania rozprowadź profil lub adres URL bramy, który akceptuje, i zanotuj, który produkt używa której metody. Ta notatka powstrzymuje następnego administratora przed dodaniem rekordu i oczekiwaniem, że zadziała wszędzie. Specyfikacja SRV opisuje wybór między celami, a czytanie jej jako mechanizmu autoryzacji to droga, na której przydatny rekord staje się założeniem bezpieczeństwa. Publikuj świadomie, nazwij etykietę w swojej dokumentacji i traktuj klienta jako komponent, który decyduje, czy to wszystko ma znaczenie.