DNS działa najlepiej wtedy, gdy użytkownik nie musi myśleć o jego istnieniu. Port 53 jest dla tego mechanizmu podstawowym punktem kontaktu: tam trafiają zapytania o domeny, a stamtąd wracają odpowiedzi z rekordami A, AAAA, MX czy TXT. W dalszej części pokazuję, kiedy ruch idzie przez UDP, kiedy przez TCP, co otworzyć w zaporze i jak diagnozować awarie bez zgadywania.
Najważniejsze rzeczy, które trzeba wiedzieć o DNS
- DNS zwykle zaczyna rozmowę po UDP na 53, bo to szybsze i lżejsze dla prostych zapytań.
- Gdy odpowiedź jest zbyt duża albo potrzebny jest transfer strefy, wchodzi TCP.
- Blokada samego UDP często psuje rozwiązywanie nazw, nawet jeśli „coś” nadal odpowiada.
- Za działanie domen odpowiadają przede wszystkim rekordy A, AAAA, MX, TXT, NS i SOA.
- Jeśli potrzebujesz szyfrowania DNS, patrz raczej na DoT albo DoH niż na klasyczny ruch wprost z sieci.
Jak działa DNS, gdy pytanie trafia do serwera
Ja patrzę na DNS jak na krótki dialog między klientem a resolverem, który po drodze może jeszcze zapytać kilka innych serwerów. Najczęściej komputer wysyła zapytanie do resolvera rekurencyjnego, czyli serwera, który samodzielnie odnajduje odpowiedź w imieniu klienta. Taki ruch zwykle startuje po UDP, bo to metoda szybka i mało zasobożerna, a na wyjściu serwer odpowiada z portu źródłowego 53 do wysokiego portu klienta.
Jeśli odpowiedź nie mieści się w klasycznym pakiecie, serwer oznacza ją jako uciętą, a klient może ponowić zapytanie przez TCP. W praktyce oznacza to, że DNS nie jest „jednym protokołem”, tylko prostym schematem: szybkie zapytanie, ewentualny fallback i ewentualnie kolejne kroki, jeśli odpowiedź jest większa niż standardowy rozmiar wiadomości UDP. Przy strefach domenowych dochodzi jeszcze serwer autorytatywny, czyli ten, który przechowuje właściwe dane o domenie, a nie tylko je buforuje.
Ta logika tłumaczy, dlaczego w konfiguracji sieci nie wystarcza myślenie o jednym porcie i jednym protokole. Właśnie z tego wynika następna praktyczna różnica: kiedy UDP wygrywa, a kiedy TCP staje się koniecznością.
Dlaczego UDP dominuje, a TCP nadal jest potrzebny
UDP jest domyślnym wyborem, bo daje niski narzut i szybki czas odpowiedzi. W klasycznym DNS długo obowiązywał limit 512 bajtów na wiadomość UDP, a dziś ten model rozszerza EDNS(0), czyli mechanizm pozwalający negocjować większy rozmiar odpowiedzi. To jednak nie kasuje problemów: zbyt duże pakiety mogą się fragmentować, a fragmentacja lub firewall po drodze potrafią je po prostu zgubić.
| Transport | Do czego służy | Co daje | Gdzie pojawiają się ograniczenia |
|---|---|---|---|
| UDP 53 | Standardowe zapytania o rekordy domen | Niski narzut, szybka odpowiedź, dobra wydajność | Ograniczenia rozmiaru, brak gwarancji dostarczenia, ryzyko ucięcia odpowiedzi |
| TCP 53 | Duże odpowiedzi, transfery stref, fallback po ucięciu pakietu | Stabilność, większe wiadomości, lepsza niezawodność | Większy narzut połączenia i nieco wyższe opóźnienie |
| DoT 853 | Szyfrowany DNS do resolvera | Prywatność i ochrona treści zapytań | Wymaga wsparcia po stronie klienta i serwera |
| DoH 443 | Szyfrowany DNS ukryty w HTTPS | Trudniejszy do filtrowania i podsłuchu | Łatwo miesza się z ruchem webowym, więc komplikuje polityki sieciowe |
W praktyce nie traktuję TCP jako wyjątku, tylko jako obowiązkowy plan B. Jest jeszcze jeden ważny przypadek: transfer strefy, czyli przekazanie pełnych danych domeny między serwerami DNS. To operacja z natury bardziej „ciężka” i właśnie dlatego powinna działać po TCP. Jeśli ktoś próbuje uprościć sieć do samego UDP, zwykle robi sobie problem na własne życzenie.
To prowadzi do pytania, które najczęściej ma znaczenie dla właścicieli domen i administratorów: jakie konkretnie dane przechodzą przez DNS i czemu niektóre rekordy częściej ujawniają problemy niż inne.
Jakie rekordy i operacje domenowe korzystają z DNS
Najczęściej widzę jedno nieporozumienie: ktoś myli panel zarządzania domeną z samym ruchem sieciowym. Zmiana rekordów w panelu rejestratora nie „otwiera” nowego kanału, tylko modyfikuje dane, które potem są odczytywane przez DNS. Dla użytkownika końcowego najważniejsze są rekordy, które decydują o tym, gdzie prowadzi domena, jak działa poczta i czy usługi pomocnicze potrafią się odnaleźć.
| Rekord lub operacja | Po co jest używany | Co widać w praktyce |
|---|---|---|
| A | Wskazuje adres IPv4 dla domeny lub subdomeny | To najprostsza droga z nazwy do serwera WWW |
| AAAA | Wskazuje adres IPv6 | Coraz ważniejszy w nowoczesnych wdrożeniach |
| MX | Określa serwery obsługujące pocztę dla domeny | Błędny wpis potrafi wyłączyć dostarczanie maili |
| TXT | Przenosi dane pomocnicze, np. SPF, DKIM, DMARC lub weryfikacje usług | Często daje duże odpowiedzi, więc szybciej obnaża limit UDP |
| NS i SOA | Opisują delegację i autorytet strefy | Bez nich domena nie ma poprawnie wskazanych serwerów nazw |
| CNAME | Tworzy alias jednej nazwy na drugą | Działa wygodnie, ale trzeba uważać na rekord w strefie głównej |
| PTR | Służy do odwrotnego mapowania IP na nazwę | Ważny przy poczcie, logach i diagnostyce |
| AXFR / IXFR | Przenosi strefę między serwerami | To właśnie tutaj TCP jest standardem, a nie dodatkiem |
Najbardziej podatne na problemy są rekordy TXT oraz rozbudowane strefy z DNSSEC, bo ich odpowiedzi rosną szybciej niż się wydaje. Gdy taka odpowiedź zaczyna się urywać, użytkownik widzi tylko objawy: poczta nie przechodzi weryfikacji, aplikacja nie znajduje hosta albo panel domeny działa „czasem tak, czasem nie”. Z tego miejsca już tylko krok do typowych awarii w sieci.
Gdzie najczęściej pojawiają się problemy z ruchem DNS
Jeżeli DNS przestaje działać, najczęściej winna nie jest sama domena, tylko filtr po drodze albo zbyt uproszczona reguła zapory. Najczęstszy błąd, który widzę, to przepuszczenie tylko jednego transportu. Z zewnątrz wygląda to jak poprawna konfiguracja, a w praktyce część zapytań wraca, część nie wraca wcale, a część kończy się retry po stronie klienta.
- Zablokowany UDP przy jednocześnie otwartym TCP. Krótkie odpowiedzi mogą jeszcze działać, ale normalne rozwiązywanie nazw zaczyna szwankować.
- Zbyt agresywna filtracja wychodzącego DNS. Firmy robią to celowo, żeby wymusić własny resolver, ale wtedy trzeba kontrolować wyjątki.
- Konflikt na hoście. Na maszynie może już działać lokalny resolver, taki jak systemd-resolved, dnsmasq albo AdGuard Home, i wtedy drugi proces nie podniesie nasłuchu na tym samym porcie.
- Za duże odpowiedzi. TXT, DNSSEC i rozbudowane delegacje potrafią wyjść poza komfortowy rozmiar UDP.
- Stare urządzenia i firmware. Nie każde urządzenie poprawnie ponawia zapytanie po TCP, nawet jeśli protokół tego wymaga.
W diagnostyce lubię trzymać się prostych kroków. Najpierw sprawdzam zwykłe zapytanie, potem wymuszam TCP, a dopiero później patrzę w pakiety:
-
dig domena.pl- szybki test podstawowego resolvera. -
dig +tcp domena.pl- sprawdzenie, czy problem dotyczy tylko UDP. -
dig TXT domena.pl- dobry test dla dłuższych odpowiedzi i rekordów pomocniczych.
Jeśli TCP działa, a UDP nie, problem zwykle jest po stronie firewalla, NAT-u albo pośredniego filtra. Jeśli oba warianty zawodzą, trzeba szukać głębiej: w konfiguracji samego resolvera, delegacji strefy albo w lokalnym konflikcie usług. A kiedy wiadomo już, gdzie DNS się łamie, można sensownie podejść do konfiguracji.
Jak ustawić firewall i resolver bez zbędnych komplikacji
Ja dzielę konfigurację DNS według roli, a nie według jednego uniwersalnego szablonu. Inaczej traktuję komputer użytkownika, inaczej firmowy resolver w LAN, a jeszcze inaczej serwer autorytatywny wystawiony publicznie. To podejście pozwala uniknąć sytuacji, w której jeden ruch przepuszczamy za dużo, a drugi za mało.
- Stacja robocza - zwykle potrzebuje tylko ruchu wychodzącego do zaufanego resolvera. Ruch przychodzący można zostawić zamknięty.
- Resolver wewnętrzny - powinien przyjmować zapytania od sieci lokalnej po obu transportach, ale z internetu najlepiej go nie wystawiać, jeśli nie ma takiej potrzeby.
- Serwer autorytatywny domeny - musi obsługiwać zapytania przychodzące po UDP i TCP, bo część klientów zażąda odpowiedzi krótkiej, a część potrzebuje większego pakietu lub transferu strefy.
- Środowisko z szyfrowanym DNS - warto zdecydować, czy klient ma używać DoT, DoH czy klasycznego DNS. Mieszanie wszystkiego bez polityki kończy się chaosem w logach i filtrach.
W firmie lubię też trzymać zasadę split DNS, czyli innego widoku nazw dla sieci wewnętrznej i innego dla świata zewnętrznego. To praktyczne rozwiązanie tam, gdzie część usług ma działać tylko lokalnie, a część musi być publiczna. Taki układ zmniejsza liczbę wyjątków w firewallu i upraszcza debugowanie.
Jeśli chcesz szyfrowania, nie próbuję go „dodać” do klasycznego ruchu na siłę. DoT korzysta ze standardowego portu 853, a DoH przenosi DNS do HTTPS na 443, więc obie opcje zmieniają sposób myślenia o filtracji. To nie jest drobna kosmetyka, tylko realna zmiana w polityce sieciowej.
W praktyce najwięcej błędów rodzi się nie wtedy, gdy reguły są restrykcyjne, tylko wtedy, gdy są nieprecyzyjne. Dlatego przed wdrożeniem warto jeszcze przejść przez kilka kontrolnych pytań.
Zanim zamkniesz ruch DNS, sprawdź te trzy rzeczy
Po pierwsze, ustal, czy mówisz o resolverze, czy o serwerze autorytatywnym. To decyduje o tym, czy ruch ma być przychodzący, wychodzący, czy tylko lokalny w obrębie sieci. Po drugie, sprawdź, czy w środowisku nie działają już alternatywy typu DoT lub DoH, bo wtedy polityka bezpieczeństwa musi obejmować także 853 i 443, a nie tylko klasyczny DNS.
Po trzecie, monitoruj nie tylko błędy, ale też retry do TCP i oznaczenia odpowiedzi jako uciętych. To bardzo szybki sygnał, że odpowiedzi są zbyt duże, firewall je filtruje albo klient nie umie poprawnie przejść z UDP na TCP. Gdy te trzy punkty są pod kontrolą, DNS przestaje być źródłem przypadkowych problemów, a staje się po prostu przewidywalnym elementem infrastruktury.
Jeżeli patrzeć na DNS praktycznie, to nie chodzi o sam numer 53, tylko o cały łańcuch zachowań: krótkie zapytania po UDP, obowiązkowy fallback po TCP, strefy domenowe, rekordy, które łatwo się rozrastają, i coraz częściej także szyfrowane warianty transportu. Najmniej błędów widzę tam, gdzie reguły w firewallu wynikają z roli serwera, a nie z domyślnego szablonu, a diagnostyka zaczyna się od prostego dig, nie od zgadywania.
