icomHOST

Wszystko o domenach i hostingach

Jak działają rekordy SRV na serwerach

Jak działają rekordy SRV na serwerach

icomhost.pl 31 marca, 2026

Rekordy SRV to jeden z najbardziej niedocenianych mechanizmów warstwy nazw w sieciach i usługach hostingowych. Dzięki nim aplikacje nie muszą znać konkretnego adresu ani portu serwera; wystarczy, że potrafią zapytać system nazw o punkt dostępu do usługi. To dlatego telefonia SIP, katalogi LDAP, komunikatory XMPP, Kerberos w Active Directory czy nawet popularne gry sieciowe mogą z łatwością odnajdywać właściwy backend bez twardego kodowania parametrów połączenia. Gdy raz zrozumiesz logikę działania rekordów DNS i ich konsekwencje dla dostępności oraz skalowania, stają się one naturalnym elementem projektowania nowoczesnej infrastruktury. Rekord SRV wskazuje gdzie (domena docelowa) i jak (protokół, port) połączyć się z daną SRV. W świecie hostingu to prosty sposób na oddzielenie nazwy usługi od fizycznej lokalizacji serwera, co ułatwia migracje, podmiany i automatyzację. Jeśli zarządzasz wieloma serwerami, usługami w chmurze lub korzystasz z usług operatorów VoIP, rekordy SRV to niezbędne narzędzie – działające w tle, a jednak krytyczne dla wygody użytkownika i niezawodności. Koncepcja jest prosta: klient pyta o nazwę usługi i otrzymuje uporządkowaną listę punktów końcowych, do których może się podłączyć. Co ważne, rekordy SRV potrafią nie tylko wskazać hosta i numer portu, ale także przekazać preferencje, które ułatwiają automatyczny wybór najlepszej ścieżki komunikacji dla danej usługa.

Co to jest rekord SRV i z czego się składa

SRV (Service Locator) to rekord zasobu w strefie DNS opisany w RFC 2782, którego zadaniem jest wskazanie punktów końcowych dla konkretnej usługi. Składnia nazwy SRV przewiduje dwa poziomy z podkreśleniami: _service._proto.domena. Przykłady:

  • _sip._tcp.example.com – odnajdywanie serwerów SIP po TCP dla domeny example.com
  • _xmpp-server._tcp.example.org – federacja XMPP (połączenia serwer-serwer) po TCP dla example.org
  • _minecraft._tcp.example.net – serwer gry Minecraft po TCP dla example.net

Sam rekord SRV zawiera pięć najważniejszych pól danych:

  • priorytet (priority) – liczba całkowita określająca pierwszeństwo w wyborze serwera. Niższa wartość oznacza wyższy priorytet. Klient próbuje najpierw serwerów o najniższym priorytecie; wyższe priorytety służą zazwyczaj jako zapas.
  • waga (weight) – liczba całkowita, proporcjonalna szansa wyboru serwera w obrębie tej samej grupy priorytetu. To mechanizm miękkiego równoważenia ruchu między równorzędnymi serwerami.
  • port (port) – numer portu TCP/UDP, pod który klient ma się połączyć.
  • cel (target) – w pełni kwalifikowana nazwa domenowa hosta świadczącego usługę (zwykle FQDN zakończony kropką w strefie). Ten host musi mieć rekordy A/AAAA.
  • TTL oraz klasa (IN) – czas życia rekordu w cache i klasa protokołu, zwykle IN (Internet).

Przykładowy wpis w strefie (zaprezentowany opisowo): dla _sip._tcp.example.com możemy zdefiniować dwa serwery o priorytecie 10 i wagach 80/20, oba na porcie 5060, wskazujące odpowiednio na sip1.example.com. i sip2.example.com. Tak skonfigurowany tandem każe klientom preferować serwer pierwszy w czterech piątych przypadków, a drugi w jednej piątej – o ile priorytet jest ten sam. Jeśli dodamy trzeci rekord o priorytecie 20, będzie on używany dopiero wtedy, gdy wszystkie serwery priorytetu 10 nie będą dostępne.

Ważna uwaga zgodna z RFC: pole docelowe (target) w SRV nie powinno wskazywać aliasu CNAME. Powinno wskazywać nazwę, pod którą istnieją bezpośrednie rekordy A/AAAA. To ograniczenie zapobiega niejednoznaczności i zbytniej kaskadzie rozwiązań, upraszczając pracę klienta i minimalizując ryzyko błędów.

Jak klienci wybierają serwer: algorytm i konsekwencje

Gdy aplikacja lub biblioteka zapytuje o SRV, robi to najczęściej przez lokalny resolver systemowy. Mechanizm wyboru serwera przebiega w kilku krokach:

  • Klient pobiera wszystkie rekordy SRV dla danej usługi i grupuje je po wartości priorytetu.
  • Wybiera grupę o najniższym priorytecie i ignoruje pozostałe, dopóki przynajmniej jeden serwer z tej grupy jest osiągalny.
  • W ramach wybranego priorytetu stosuje losowanie ważone: prawdopodobieństwo wylosowania serwera jest proporcjonalne do jego wagi. Dzięki temu możliwe jest miękkie równoważenie ruchu.
  • Jeśli wybrany serwer nie odpowiada (timeout, błąd TCP, brak odpowiedzi aplikacji), klient powinien spróbować kolejnego kandydata w tej samej grupie; dopiero gdy wszystkie zawiodą, przechodzi do grupy o wyższym priorytecie.
  • Wykorzystywane są rekordy A/AAAA dla pola target, a następnie nawiązanie odbywa się bezpośrednio do wskazanego portu i IP.

Ta logika ma kilka istotnych konsekwencji projektowych. Po pierwsze, SRV świetnie nadaje się do implementacji aktywnej i pasywnej redundancji. Po drugie, wagi nie są substytutem zaawansowanych load balancerów warstwy 4/7 – to raczej mechanizm probabilistycznego rozkładu ruchu, bez świadomości stanu aplikacji. Po trzecie, opóźnienia propagacji (TTL) oraz cache u klientów i pośredników oznaczają, że zmiany nie są natychmiastowe. Dlatego planując awarie kontrolowane, migracje czy testy A/B, warto precyzyjnie zarządzać TTL oraz obserwować zachowanie klientów po stronie logów serwera.

SRV a wysoka dostępność i scenariusze awaryjne

Trio priorytet–waga–port tworzy elastyczny trzon polityk dostępności. Najpopularniejszy wzorzec to aktywny–pasywny: wszystkie rekordy w stanie aktywnym mają ten sam priorytet i niezerową wagę, a w tle czeka zapasowy zestaw serwerów o wyższym priorytecie (czyli gorszym pierwszeństwie). Jeśli cokolwiek pójdzie nie tak u dostawcy lub w danym regionie, klienci automatycznie przejdą do następnej grupy. To właśnie naturalny mechanizm failover wbudowany w DNS. Z kolei gdy chcemy sterować ruchem między centrami danych, manipulujemy wagami w ramach jednego priorytetu, osiągając proporcjonalny rozkład połączeń. Warto pamiętać, że SRV nie monitoruje zdrowia – brak aktywnych checksów to odpowiedzialność poza DNS: systemów monitoringu lub inteligentnych klientów protokołów.

Przykłady zastosowań w praktyce

SIP i VoIP

W świecie telefonii internetowej SRV to standard. Klient SIP szuka wpisów _sip._udp lub _sip._tcp, a w przypadku szyfrowania _sips._tcp. Często poprzedza je logika NAPTR, która pomaga wybrać właściwy protokół i transport (UDP/TCP/TLS), ale to SRV daje właściwą listę hostów i portów. Dzięki temu operator może przenosić infrastrukturę, dodawać regiony i sterować ruchem abonentów bez konieczności aktualizacji konfiguracji w każdym urządzeniu końcowym.

XMPP i federacja

Komunikatory oparte na XMPP wykorzystują _xmpp-client._tcp dla klientów oraz _xmpp-server._tcp dla komunikacji między serwerami. To umożliwia odkrywanie punktów końcowych na podstawie samej domeny użytkownika (np. user@domena.tld), bez twardego wskazywania hostów.

LDAP, Kerberos i Active Directory

Środowiska domenowe Windows używają intensywnie SRV: _ldap._tcp.dc._msdcs.domena dla kontrolerów domeny, _kerberos._tcp/udp dla usług uwierzytelniania. Stacje robocze i serwery wykorzystują te rekordy do automatycznego wyszukiwania odpowiednich usług katalogowych i uwierzytelniających w obrębie lasu domen.

Gry i narzędzia komunikacyjne

Serwery gier, takie jak Minecraft, TeamSpeak czy niektóre platformy e-sportowe, wystawiają SRV, aby gracze mogli łączyć się do domeny bez pamiętania nietypowego portu. Dzięki temu użytkownik wpisuje tylko nazwę domeny, a gra sama wie, do jakiego portu i hosta się skierować.

HTTP i nowe typy rekordów

Tradycyjnie przeglądarki nie ufały SRV dla HTTP/HTTPS, preferując A/AAAA, CNAME oraz mechanizmy aplikacyjne (np. Alt-Svc). Jednak rodzina rekordów SVCB/HTTPS (zdefiniowana w nowszych RFC) wprowadza nowocześniejszy sposób publikowania parametrów połączeń dla usług webowych, w tym alternatywnych nazw i portów. W części ekosystemu hostingowego i klienckiego wsparcie staje się coraz bardziej powszechne, choć SRV pozostaje standardem głównie dla innych protokołów.

Projektowanie rekordów SRV pod kątem hostingu

Rozdzielanie ról i domen

W wielu firmach domena aplikacyjna i domena infrastrukturalna to osobne byty. SRV ułatwia ukrycie warstwy fizycznej za stabilnymi nazwami usługowymi. Rekordy można publikować w domenie klienta, wskazując na hosty w prywatnej domenie usługodawcy. Dzięki temu migracja lub skalowanie po stronie dostawcy nie zmienia interfejsu nazwowego widzianego przez użytkowników.

Architektury wieloregionowe

W każdej lokalizacji można utrzymywać serwery o takim samym priorytecie i odpowiednio dobranych wagach. Regiony o większej pojemności mogą mieć wyższą wagę, mniejsze – niższą. W scenariuszach awarii cała grupa o danym priorytecie pozostaje w użyciu tak długo, jak choć jeden z jej członków odpowiada, co sprzyja odporności na błędy pojedynczych węzłów.

Migracje bez przestoju

Strategia „przedłuż i przełącz” polega na obniżeniu TTL rekordów SRV, wprowadzeniu nowego zestawu hostów równolegle z dotychczasowym i stopniowej zmianie wag. Gdy monitoring i logi aplikacji potwierdzą stabilność, można zmniejszać wagę starych hostów do zera, a następnie usunąć je z konfiguracji. Klienci nie odczuwają przerw, a ryzyko jest minimalne.

Najczęstsze pułapki i jak ich uniknąć

  • Niewłaściwy target – pole cel powinno wskazywać FQDN z rekordami A/AAAA, nie CNAME. To wymóg zgodny z RFC 2782.
  • Brak kropki końcowej – w edytorach stref domenowych często należy zakończyć nazwę hosta kropką, aby uniknąć doklejania sufiksów strefy.
  • Skrzyżowanie z MX – e-mail używa MX, nie SRV. Próba sterowania pocztą przez SRV nic nie da; klienci pocztowi go nie odczytają.
  • Ignorowanie TTL – zbyt długi TTL utrudni szybkie przełączenia i testy; zbyt krótki – zwiększy obciążenie DNS i opóźnienia rozwiązań.
  • Panel z blokadą podkreśleń – niektóre starsze narzędzia do DNS w przeszłości odrzucały nazwy z „_”. W nowoczesnych panelach to obsługiwane poprawnie.
  • Nadmierne poleganie na wagach – to nie jest inteligentny load balancer. Wagi nie sprawdzają zdrowia aplikacji.
  • Brak spójności portów – klient użyje portu z SRV. Upewnij się, że firewall i reverse proxy akceptują połączenia na tym samym numerze w każdym regionie.

Konfiguracja SRV w popularnych panelach DNS i hostingach

W większości paneli (cPanel, Plesk, Cloudflare DNS, Route 53, panel rejestratora domen) dodawanie SRV polega na wypełnieniu formularza z polami: nazwa (_service._proto), TTL, priority, weight, port, target. Praktyczne wskazówki:

  • Nazwa – wpisuj z podkreśleniami, np. _sip._tcp. Nie dodawaj domeny, jeśli panel automatycznie ją dokleja.
  • TTL – na czas migracji i testów 60–300 s; produkcyjnie 600–3600 s to zwykle bezpieczny kompromis.
  • Priorytety – 0/10/20 jako czytelna konwencja warstw (aktywni/prior+1/zapas). Ważne, aby niższe oznaczały lepsze.
  • Wagi – przemyślane proporcje (np. 80/20), ale pamiętaj o ograniczeniach braku „świadomości stanu”.
  • Target – pełny FQDN zakończony kropką, np. sip1.provider.net.
  • Cloudflare – SRV działa w trybie DNS only (szara chmurka); proxowanie (orange) nie dotyczy SRV, ponieważ nie jest to HTTP.

Testowanie i diagnostyka: jak sprawdzać SRV

Do weryfikacji użyjesz klasycznych narzędzi systemowych:

  • dig -t SRV _sip._tcp.example.com – zwróci listę kandydatów z priorytetami i wagami.
  • nslookup -type=SRV _xmpp-server._tcp.example.org – prosty test pod Windows i Linux.
  • PowerShell: Resolve-DnsName -Type SRV _ldap._tcp.example.local – przydatne w domenach AD.

Diagnozując problemy, zwracaj uwagę na: dopasowanie nazwy usługi i protokołu, obecność adresów A/AAAA dla nazw docelowych, TTL w odpowiedziach, a także spójność rekordów w replikowanych strefach. W logach aplikacji szukaj błędów połączeń, time-outów, a po stronie serwera – odrzuconych połączeń lub błędnej konfiguracji firewalla.

Bezpieczeństwo i spójność: DNSSEC, DANE i prywatność

Rekordy SRV – jak każde dane DNS – można i warto podpisywać DNSSEC, aby chronić je przed modyfikacją w tranzycie i cache poisoningiem. W świecie usług szyfrowanych TLS przydatny jest też DANE/TLSA, w którym rekord TLSA umieszczany jest obok nazwy portu i protokołu (np. _5061._tcp.domena dla SIPS). To dobra praktyka w środowiskach wymagających podniesionego zaufania do łańcucha kryptograficznego. Dodatkowo wrażliwe zastosowania mogą rozważyć resolvery komunikujące się przez DoT/DoH, minimalizując pasywny podsłuch i manipulację w sieciach lokalnych.

Relacja z innymi rekordami: MX, CNAME, SVCB/HTTPS i NAPTR

  • MX – dedykowany dla poczty; SRV go nie zastępuje.
  • CNAME – docelowy host SRV nie powinien być aliasem CNAME; zamiast tego użyj bezpośrednich rekordów A/AAAA.
  • SVCB/HTTPS – nowa generacja rekordów do publikowania parametrów połączeń (zwłaszcza dla HTTP/HTTP3). Dla protokołów nie-web wciąż dominuje SRV.
  • NAPTR – bywa warstwą decyzyjną nad SRV (np. w SIP), pozwalając klientom wybrać transport (UDP/TCP/TLS) i dopiero potem pobrać właściwe SRV.

SRV w środowiskach kontenerowych i chmurach

Systemy orkiestracji, takie jak Kubernetes, udostępniają nazwy usług wewnątrz klastra i automatycznie generują rekordy SRV dla nazwanych portów usług (szczególnie w usługach headless). To pozwala podsystemom odnajdywać konkretne endpointy (pod’y) i łączyć się wprost, z pominięciem klasycznego load balancingu L4. W chmurach publicznych SRV wspiera automatyczne service discovery między mikroserwisami, gdy nazwy i porty mogą się zmieniać dynamicznie, ale usługa powinna pozostać odnajdywalna pod stałą etykietą nazwową.

Wydajność i cache: jak ustawiać TTL oraz liczyć z opóźnieniami

Każdy rekord DNS jest buforowany. Zbyt krótki TTL zwiększy liczbę zapytań, co może dodać dziesiątki milisekund do zimnych połączeń lub obciążyć resolvery. Zbyt długi utrudni sterowanie ruchem i spowolni przełączanie awaryjne. W praktyce: podczas wdrożeń i migracji warto zejść do 60–300 s, a gdy środowisko ustabilizuje się, podnieść do 600–3600 s, zależnie od wymogów biznesowych. Pamiętaj o negatywnym cache (NSEC/NXDOMAIN) i o tym, że część aplikacji utrzymuje własny cache rekordów niezależny od systemowego.

Scenariusze operacyjne: od teorii do praktyki

Dodanie drugiego regionu

Załóżmy, że masz _sip._tcp.twojadomena.tld z jednym serwerem w Warszawie (priorytet 10, waga 100). Dodając region w Berlinie, ustaw mu ten sam priorytet i wagę 50. Stopniowo zwiększaj lub zmniejszaj wagi, aby uzyskać docelową proporcję ruchu. Monitoring jakości połączeń i obciążenia CPU/RAM na serwerach podpowie, jak zbalansować parametry.

Bezprzerwowa wymiana hosta

Obniż TTL dla SRV i powiązanych rekordów A/AAAA do 300 s tydzień przed oknem zmian. Dodaj nowy host do grupy z małą wagą (np. 5). Obserwuj błędy aplikacji i metryki. Jeśli jest stabilnie, podnoś wagę co kilka godzin. Po 24–48 godzinach, gdy ruch bezproblemowo płynie przez nowy host, ustaw wagę starego na 0 i usuń go z konfiguracji.

Awaria dostawcy

W przypadku globalnej awarii jednego dostawcy najlepiej mieć równoległy zestaw serwerów u drugiego, opublikowany w SRV z tym samym priorytetem i sensownie dobranymi wagami. Jeśli preferujesz deterministyczne przełączenie, nadaj alternatywnemu zestawowi wyższy priorytet i trzymaj go jako „zimny” zapas; klienci sięgną po niego dopiero po wyczerpaniu pierwszej grupy.

Dobre praktyki publikacji i utrzymania

  • Dokumentuj konwencje priorytetów i wag w zespole SRE/NetOps – unikniesz niespójności przy dużej liczbie usług.
  • Utrzymuj spójne nazewnictwo (np. regiony, pozycje w FQDN) – ułatwia grepy i automaty.
  • Automatyzuj generowanie rekordów SRV (IaC, szablony Terraform/Ansible), by ograniczyć błędy literowe i kropki końcowe.
  • Integruj monitoring usług z procesem zmian w SRV – publikuj wagę >0 dopiero, gdy health check spełnia kryteria SLO.
  • Stosuj DNSSEC w strefie i rozważ DANE/TLSA dla usług szyfrowanych.
  • Testuj z perspektywy klienta: emulator protokołu (np. sipp, ldapsearch, xmpp-cli) i traceroute/TCPing do weryfikacji ścieżek sieciowych.

FAQ: częste pytania administratorów

Czy SRV działa z UDP i TCP?

Tak – wskazujesz to w komponencie _proto (np. _udp lub _tcp). Część protokołów ma standardowe, opublikowane kombinacje.

Czy mogę wskazać adres IP zamiast nazwy?

Nie. Pole target to nazwa domenowa, która musi rozwijać się do A/AAAA. To zamierzone – dzięki temu można niezależnie aktualizować IP bez dotykania SRV.

Co jeśli klient ignoruje wagi?

Specyfikacja zaleca losowanie ważone, lecz implementacje bywają różne. Jeśli precyzyjna dystrybucja ruchu jest krytyczna, rozważ dedykowany load balancer L4/L7.

Czy SRV może pomóc w TLS?

Tak, pośrednio. SRV wskaże host i port, a rekordy TLSA/DANE mogą potwierdzić tożsamość certyfikatu dla konkretnego endpointu (np. _5061._tcp.domena dla SIPS). To zwiększa bezpieczeństwo skojarzenia klucza publicznego z usługą.

Podsumowanie: dlaczego warto zaprzyjaźnić się z SRV

Rekordy SRV rozwiązują uniwersalny problem mapowania usług na konkretne punkty końcowe. Umożliwiają abstrakcję nazw usługowych od topologii infrastruktury, a przy tym dostarczają prymitywy potrzebne do sterowania ruchem, konserwacji i odpornych na awarie projektów hostingowych. Dobrze dobrane priorytety i wagi, spójna polityka TTL oraz praktyki bezpieczeństwa (DNSSEC, DANE) sprawiają, że SRV to potężny, a jednocześnie prosty w obsłudze element arsenalu administratora. Kiedyś kojarzone głównie z VoIP i katalogami, dziś znajdują zastosowanie od mikroserwisów w chmurze po serwery gier, a ich znaczenie w dobie automatycznego service discovery tylko rośnie. Świadome wykorzystanie SRV pozwala budować elastyczne, skalowalne i odporne środowiska – bez zbędnych zmian po stronie klientów i bez kompromisów co do jakości doświadczenia użytkownika.