Jakiego portu używa DNS? Port 53 i kiedy nie

Jakiego portu DNS używa dla zwykłego zapytania?

Zwykłe zapytanie, tego rodzaju, które Twoja przeglądarka wysyła dziesiątki razy na minutę, wychodzi jako pojedynczy pakiet UDP na port 53 i tą samą drogą wraca. RFC 1035 nazywa UDP "zalecaną metodą dla standardowych zapytań w internecie", bo nie wymaga żadnego uzgadniania: jeden pakiet w jedną stronę, jeden z powrotem, gotowe. Dlatego właśnie DNS wydaje się natychmiastowy, gdy działa, i dlatego wystarczy jeden zgubiony pakiet, żeby wydawał się zepsuty, skoro UDP samo z siebie nie ponawia próby za Ciebie. Oprogramowanie resolvera na Twoim urządzeniu albo routerze obsługuje ponowną próbę, zwykle wobec drugiego skonfigurowanego serwera, jeśli pierwszy milczy.

Kiedy DNS używa zamiast tego TCP?

Dwie sytuacje przenoszą wymianę DNS na port TCP 53. Pierwsza to transfer strefy, w którym serwer pomocniczy pobiera pełną kopię strefy z serwera podstawowego. RFC 1035 jasno stwierdza, że "UDP nie jest dopuszczalne dla transferów stref", bo operacja potrzebuje niezawodnego, uporządkowanego strumienia, nie pojedynczego pakietu na zasadzie best effort. Druga to odpowiedź, która nie zmieści się w rozmiarze wiadomości UDP używanym w danej chwili. Wtedy serwer odsyła obcięty pakiet UDP z ustawionym bitem TC (truncated), a zgodny resolver zauważa ten bit i wysyła to samo zapytanie ponownie przez TCP, żeby dostać pełną odpowiedź. Możesz wymusić to zachowanie sam i zobaczyć pełną odpowiedź bezpośrednio:

dig +tcp example.com

Codzienne zapytania rzadko potrzebują tej ścieżki, ale istnieje ona właśnie po to, żeby DNS dalej działał, gdy odpowiedź urośnie ponad to, co zmieści jeden pakiet UDP, a zdarza się to częściej niż kiedyś.

Czym był limit 512 bajtów i co go zmieniło?

RFC 1035 ustaliło rozmiar wiadomości UDP na 512 bajtów, wliczając nagłówek, nie licząc samych nagłówków IP czy UDP. Ta liczba była hojna w 1987 roku, gdy odpowiedź DNS to była garstka rekordów adresowych. Przestała być hojna, gdy podpisy DNSSEC, dłuższe nazwy hostów i rekordy z wieloma adresami IP stały się czymś normalnym, bo podpisana odpowiedź z rekordem RRSIG rutynowo sama w sobie przekracza 512 bajtów.

RFC 6891, opublikowane w 2013 roku, naprawiło ten sufit, nie ruszając samego protokołu na drucie: EDNS0 dodaje pseudorekord OPT, który pozwala resolverowi ogłosić "największy ładunek UDP, jaki może zostać złożony i dostarczony w stosie sieciowym żądającego", a RFC sugeruje 4096 bajtów jako praktyczny punkt startowy. Resolver i serwer, które oba wspierają EDNS0, mogą wymieniać się odpowiedziami kilkukrotnie większymi niż stary limit 512 bajtów w jednym pakiecie UDP, i dopiero wtedy przechodzić na TCP, gdy nawet ten większy limit nie wystarcza. Niemal każdy resolver używany dziś, w tym Twój własny system operacyjny, mówi domyślnie w EDNS0, więc ta zmiana zaszła już bez żadnego działania z Twojej strony.

Dlaczego zapory dopuszczające tylko UDP 53 powodują realne problemy

Reguła zapory napisana lata temu i nigdy od tamtej pory nierewidowana często brzmi "zezwól na UDP port 53, odrzuć wszystko inne związane z DNS". Ta reguła blokuje rezerwowy mechanizm TCP, którego protokół potrzebuje, a spowodowana przez to awaria jest łatwa do błędnej diagnozy, bo większość zapytań wciąż działa dobrze. Zawodzą tylko te, które urosną ponad limit UDP, i robią to w sposób wyglądający na losowy: domena rozwiązuje się normalnie przez większość czasu, a potem przekracza limit czasu, zwłaszcza gdy w grę wchodzi walidacja DNSSEC, bo walidujący resolver musi pobrać rekordy RRSIG i DNSKEY obok odpowiedzi, o którą pytał.

Praktycznym skutkiem jest to, że strefy podpisane DNSSEC oraz każdy zestaw rekordów z wieloma wartościami (na przykład domena z tuzinem serwerów pocztowych) stają się niestabilne za zaporą przepuszczającą tylko UDP, podczas gdy wszystko inne wygląda zdrowo. Blokowanie wychodzącego TCP 53, albo blokowanie go tylko w jednym kierunku, jest jedną z częstszych, zadanych sobie samemu awarii DNS, i rzadko pojawia się w podstawowym sprawdzeniu łączności, bo takie sprawdzenie zwykle próbuje tylko UDP.

DNS over TLS i DNS over HTTPS: różne porty, te same zapytania

Dwa nowsze transporty niosą te same zapytania i odpowiedzi DNS, ale przenoszą je zupełnie poza port 53. DNS over TLS, zdefiniowane w RFC 7858, opakowuje każde zapytanie w sesję TLS na porcie TCP 853, wybranym tak, żeby operator sieci wciąż mógł widzieć, że dzieje się DoT (i zablokować to) nawet bez odszyfrowywania, bo sam port jest wyraźnym sygnałem.

DNS over HTTPS, zdefiniowane w RFC 8484, idzie dalej. Wysyła zapytania DNS jako zwykłe żądania HTTPS na porcie 443, tym samym, na którym działa każda inna odwiedzana przez Ciebie strona, a RFC nazywa "możliwość mieszania ruchu DoH z innym ruchem HTTPS na tym samym połączeniu" celowo zaprojektowaną cechą. To jest cały sens DoH: sieć, która filtruje tylko po porcie, nie potrafi odróżnić zapytania DNS od żadnego innego żądania HTTPS, bo są tym samym protokołem na tym samym porcie. Chrome, Firefox i Edge mogą dziś wszystkie domyślnie wysyłać DNS w ten sposób, dlatego zablokowanie "portu 53" w sieci już nie gwarantuje, że zablokowałeś DNS. Gwarantuje, że zablokowałeś klasyczny transport; przeglądarka z włączonym DoH i tak dalej rozwiązuje nazwy przez port 443.

Czym jest mDNS na porcie 5353?

Multicast DNS to inny protokół noszący podobną nazwę. RFC 6762 definiuje go jako urządzenia "wysyłające do multicastowej grupy IP komunikaty zapytań i odpowiedzi w stylu DNS przez UDP na port 5353", adresowane do grupy multicast 224.0.0.251 (albo jej odpowiednika IPv6, FF02::FB), a nie do konkretnego serwera. Nie ma tu w ogóle żadnego centralnego serwera nazw: każde urządzenie w lokalnym segmencie sieci nasłuchuje na porcie 5353 i odpowiada za własną nazwę. Tak drukarka albo głośnik smart staje się osiągalny jako urządzenie.local, bez konfigurowania przez nikogo rekordu DNS. Jest z założenia ograniczony do lokalnego łącza i nie ma nic wspólnego z rozwiązywaniem publicznej nazwy domeny, więc ruch mDNS nigdy nie musi opuszczać Twojego routera.

Jak sprawdzić, czy port 53 jest osiągalny

Zacznij od bezpośredniego zapytania wobec znanego, dobrego resolvera, co mówi Ci, czy zwykłe zapytania UDP w ogóle działają:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Jeśli to się udaje, ale podejrzewasz, że rezerwowa ścieżka TCP jest zablokowana, wymuś TCP i porównaj:

dig +tcp example.com @1.1.1.1

Zapytanie UDP, które się udaje, podczas gdy wersja z wymuszonym TCP przekracza limit czasu, to mocny sygnał, że coś między Tobą a resolverem odrzuca konkretnie TCP 53, dokładnie ten tryb awarii opisany wyżej. Testowanie surowej osiągalności portu spoza własnej sieci jest tym, do czego przydaje się nasze narzędzie do sprawdzania portów: wskaż je na port 53 swojego resolvera albo serwera nazw, a otworzy prawdziwe połączenie TCP z innej sieci, potwierdzając, czy TCP 53 jest w ogóle osiągalny. Czytaj wynik z jednym zastrzeżeniem w pamięci: sprawdzanie portów testuje TCP, więc sukces tam potwierdza, że ścieżka rezerwowa jest otwarta, ale nic nie mówi o UDP, które nie ma żadnego uzgadniania do przetestowania w ten sam sposób. Dla samego zapytania, w tym porównania odpowiedzi z wielu publicznych resolverów i różnych regionów naraz, uruchom narzędzie do zapytań DNS.

Najczęściej zadawane pytania

Czy muszę otworzyć TCP 53 oprócz UDP 53?

Tak, dla wychodzącego ruchu resolvera. Zapora dopuszczająca wyłącznie UDP 53 obsłuży większość zapytań bez problemu, a potem będzie zawodzić nieprzewidywalnie na większych odpowiedziach, zwykle podpisanych DNSSEC, potrzebujących rezerwowego TCP.

Czy zablokowanie portu 53 zatrzymuje cały ruch DNS?

Już nie. Blokuje klasyczny transport UDP/TCP. DNS over HTTPS działa na porcie 443 i wygląda jak każde inne żądanie HTTPS, a DNS over TLS działa na własnym porcie 853, więc przeglądarka albo aplikacja z którymkolwiek włączonym dalej rozwiązuje nazwy.

Czy DNS over HTTPS to ten sam protokół co zwykły DNS?

Zapytania i odpowiedzi to te same rekordy i kody DNS zdefiniowane przez RFC 1035. Zmienia się tylko transport: zamiast surowego pakietu UDP albo TCP na porcie 53, to samo żądanie jest opakowane wewnątrz żądania HTTPS na porcie 443.

Dlaczego dig czasem używa TCP bez polecenia?

Gdy odpowiedź UDP wraca obcięta, z ustawionym bitem TC, zgodny ze standardem klient automatycznie wysyła zapytanie ponownie przez TCP, żeby dostać pełną odpowiedź. Widzisz to najczęściej przy domenach z włączonym DNSSEC albo z wieloma rekordami tego samego typu.

Czy mDNS na porcie 5353 to to samo co DNS mojego dostawcy internetu?

Nie. mDNS działa tylko w Twoim lokalnym segmencie sieci, nie ma centralnego serwera i rozwiązuje nazwy takie jak urządzenie.local dla urządzeń w tym samym łączu. Nie ma żadnego udziału w rozwiązywaniu publicznej domeny, takiej jak example.com.

Jaki jest normalny rozmiar ładunku EDNS0 dzisiaj?

RFC 6891 sugeruje 4096 bajtów jako praktyczną wartość domyślną, a większość obecnych resolverów ogłasza coś w tym zakresie, wyraźnie powyżej pierwotnego sufitu 512 bajtów, zanim przejdzie na TCP dopiero, gdy nawet to nie wystarcza.