Globalny weryfikator rekordu SRV
Podczas gdy standardowe rekordy A i AAAA ograniczają się do tłumaczenia nazwy domeny na adres IP, rekord SRV (Service) jest znacznie bardziej złożony. Zdefiniowany w RFC 2782, rekord SRV ustanawia ustandaryzowany sposób definiowania dokładnej nazwy hosta, protokołu oraz precyzyjnego numeru portu dla określonych aplikacji sieciowych. Są one podstawą wykrywania usług w przedsiębiorstwach, intensywnie wykorzystywaną dla Microsoft Active Directory, routingu SIP/VoIP, komunikatorów internetowych XMPP i potężnych architektur serwerów dla wielu graczy (np. rozwiązywanie _minecraft._tcp.example.com).
Składnia i wiązanie portów (Port Binding)
Rekord SRV jest natychmiast rozpoznawalny ze względu na swoją sztywną strukturę formatowania. Nazwa rekordu musi zaczynać się od podkreślenia oznaczającego usługę, po którym następuje podkreślenie oznaczające protokół transportowy, dołączone do domeny bazowej (np. _sip._tls.example.com). Powstały Payload dostarcza łączącemu się klientowi cztery określone punkty danych: Priorytet (Priority), Waga (Weight), Port docelowy oraz Kanoniczna docelowa nazwa hosta (Hostname). Umożliwia to administratorom uruchamianie wielu odrębnych usług pod jednym adresem IP przy użyciu niestandardowych portów, bez wymagania od użytkowników końcowych zapamiętywania i wpisywania numerów portów w swoich klientach.
Natywny Failover i ważony Load Balancing
Najpotężniejszą cechą rekordu SRV jest jego natywna, wielopoziomowa logika routingu. Liczba całkowita określająca Priorytet działa dokładnie tak jak w rekordzie MX; podłączający się klienci zawsze będą najpierw próbowali negocjować handshake z serwerem o najniższym priorytecie. Zapewnia to natychmiastową nadmiarowość w celu przełączania awaryjnego (Failover). Jeśli wiele rekordów ma dokładnie ten sam priorytet, uruchamiana jest wartość wyrażająca Wagę (Weight). Działa to jako proporcjonalny Load Balancer. Jeśli serwer A ma wagę 75, a serwer B wagę 25, aplikacja klienta przekieruje 75% nowych połączeń do serwera A. Pozwala to inżynierom na inteligentne kierowanie ruchu w klastrach o różnych pojemnościach sprzętowych.
Dlaczego HTTP ignoruje rekordy SRV
Powszechnym pytaniem od młodszych programistów jest to, dlaczego ruch internetowy (HTTP/HTTPS) nie wykorzystuje rekordów SRV w celu osiągnięcia natywnego równoważenia obciążenia (Load Balancing). Odpowiedź jest czysto historyczna. Zanim rekordy SRV zostały ustandaryzowane, konwencje architektoniczne polegające na tym, że HTTP działał ściśle na porcie 80, a HTTPS na porcie 443, zostały już powszechnie zakodowane na stałe w każdej przeglądarce internetowej. Przeniesienie stron internetowych na model wyszukiwań SRV dodałoby ogromną karę za rozwiązywanie (wymagającą dodatkowych żądań round-trips) przy marginalnych korzyściach. Zamiast tego HTTP opiera się na usługach Load Balancer w warstwie aplikacji oraz routingu IP typu Anycast.