Czy zapytania DNS zawsze są przesyłane przez UDP?

Spędziłem trochę czasu na badaniu tego tematu i wydaje się, że nie mogę znaleźć dokładnej odpowiedzi, więc jestem całkiem pewien, że nie jest to duplikat, i chociaż moje pytanie opiera się na potrzebie bezpieczeństwa, myślę, że nadal jest bezpiecznie zapytaj tutaj, ale daj mi znać, czy muszę przenieść to do społeczności bezpieczeństwa.

Zasadniczo, czy zapytania DNS używają kiedykolwiek protokołu TCP (jeśli tak, to w jakim scenariuszu może się to zdarzyć)? Znów mówię tylko o zapytaniach. Czy mogą podróżować przez TCP? Jeśli domeny mogą mieć maksymalnie 253 bajty, a pakiety UDP mogą mieć nawet 512 bajtów, czy zapytania nie będą zawsze wychodzić jako UDP? Nie sądziłem, że możliwe do rozwiązania zapytanie może być wystarczająco duże, aby wymagać użycia TCP. Jeśli serwer DNS dostanie kiedykolwiek żądanie domeny większej niż 253 bajty, czy serwer go upuści / nie spróbuje go rozwiązać? Jestem pewien, że podjąłem tu fałszywe założenia.

W pewnym kontekście współpracuję z grupą bezpieczeństwa, aby wbudować zapytania DNS w ich narzędzie do monitorowania bezpieczeństwa iz różnych powodów zdecydowaliśmy, że przechwycimy ten ruch poprzez standardowe przechwytywanie pakietów na serwerach DNS i kontrolerach domen. Podstawowym wymaganiem jest przechwycenie wszystkich zapytań DNS, aby mogli zidentyfikować, który klient próbował rozwiązać daną domenę. W oparciu o ten wymóg nie zajmujemy się przechwytywaniem odpowiedzi DNS lub innego ruchu, takiego jak transfery stref, co wynika również z faktu, że musimy maksymalnie ograniczyć objętość dziennika. W związku z tym planujemy przechwytywać tylko zapytania DNS przeznaczone dla serwera DNS i wysyłane przez UDP. Aby uzyskać więcej kontekstu (rodzaj zakradającego się tu zakresu pytań), teraz podniesiono, że możemy potrzebować rozszerzenia bezpieczeństwa ” widzialność, aby mogli monitorować aktywność, np. ukryte kanały działające w systemie DNS (co oznaczałoby konieczność przechwytywania również odpowiedzi DNS, a następnie ruchu TCP). Ale nawet w tego rodzaju scenariuszu myślałem, że wszelki wychodzący ruch DNS będzie miał postać zapytań / zapytań i że zawsze będą one przekraczały UDP, nawet jeśli pochodzą ze złośliwego źródła (z powodu mojego rozumowania w pierwszym akapicie). Pojawia się więc kilka dodatkowych pytań:

• Czy nie uchwycilibyśmy co najmniej połowy rozmowy z podejściem, które przedstawiłem? A może klient kiedykolwiek wyśle ​​ruch DNS, który nie jest w formie zapytania? (może jak odpowiedź na odpowiedź serwera DNS, a może kończy się to przez TCP)

• Czy zapytania DNS można modyfikować, aby używały protokołu TCP? Czy serwer DNS zaakceptuje i odpowie na zapytanie DNS przychodzące przez TCP?

Nie jestem pewien, czy jest to istotne, ale ograniczamy żądania DNS do autoryzowanych serwerów DNS i blokujemy cały ruch wychodzący przez port 53. Jestem zdecydowanie debiutantem, więc przepraszam, jeśli moje pytanie jest niezgodne, i daj mi znać jak powinienem zmodyfikować.

Normalne zapytania DNS używają portu UDP 53, ale dłuższe zapytania (> 512 oktetów) otrzymają odpowiedź „obciętą”, co powoduje konwersację TCP 53 w celu ułatwienia wysyłania / odbierania całego zapytania. Ponadto serwer DNS łączy się z portem 53, ale samo zapytanie pochodzi z losowego portu o wysokim numerze (49152 lub nowszy) wysyłanego do portu 53. Odpowiedź zostanie zwrócona do tego samego portu z portu 53.

Porty sieciowe używane przez DNS | Dokumenty Microsoft

Jeśli więc planujesz przeprowadzić szpiegowanie bezpieczeństwa w zapytaniach DNS ze swojej sieci, musisz wziąć to pod uwagę.

Jeśli chodzi o ruch niezwiązany z wyszukiwaniem, należy wziąć pod uwagę, że DNS wykorzystuje również transfery stref (typ zapytania AXFR) do aktualizacji innych serwerów DNS o nowe rekordy. Człowiek w środku ataku może rozpocząć od takiego przeniesienia, DDOS'ując główny serwer nazw, aby był zbyt zajęty, aby odpowiedzieć na pomocnika proszącego o zaktualizowane rekordy. Haker następnie fałszuje tę samą Podstawową, aby przekazać „zatrute” rekordy do Dodatkowej, która przekierowuje popularne domeny DNS do zainfekowanych hostów.

Dlatego audyt bezpieczeństwa powinien zwracać szczególną uwagę na typ zapytania AXFR, a systemy DNS powinny akceptować wymiany AXFR tylko z określonych adresów IP.

SANS Institute InfoSec Czytelnia | sans.org

Zaczęło się od komentarza do odpowiedzi George'a, ale trwało długo. Większy obraz jest nieco skomplikowany, ponieważ wymaga zrozumienia pewnej historii.

• RFC 1035 pierwotnie wymagał limitu 512 bajtów, aby uniknąć fragmentacji UDP. Pofragmentowane datagramy UDP i TCP zostały wybrane jako opcje ostatniej szansy, aby zminimalizować obciążenie transakcjami DNS. Transfery stref zawsze używają TCP, ponieważ transfery stref z natury zajmują> 512 bajtów. (w ogóle byłoby marnowaniem przepustowości, aby zacząć od UDP)

• Ponowna próba obcięcia TCP jest szeroko obsługiwana, ponieważ została określona w RFC 1123 od 1989 roku.

• EDNS (0) jest zdefiniowany przez RFC 6891 (2013), a wcześniej istniał jako proponowany standard z 1999 roku . Definiuje mechanizm, w którym klienci i serwery mogą negocjować rozmiary UDP większe niż 512. Ze względu na nowość EDNS (0) wiele urządzeń sprzętowych przyjmuje założenia dotyczące struktury pakietów DNS, które powodują odrzucanie zgodnych pakietów. Najczęstszym powodem jest założenie, że komunikaty DNS o długości ponad 512 bajtów są nieprawidłowe, ale jest to jeden z kilku.

Jeśli podzielimy to na obserwowane zachowania:

1. Zapytania DNS zwykle zaczynają się jako UDP, chyba że z góry wiadomo, że odpowiedź będzie za duża na początek. (transfery stref)
2. Odpowiedź może wywołać ponowną próbę TCP w kliencie, jeśli zostanie wyświetlona skrócona odpowiedź. Jest to dość dobrze obsługiwane.
3. Odpowiedź UDP większa niż 512 bajtów może być widoczna, jeśli klient użył EDNS (0) do zareklamowania większego ładunku, a serwer odbierający go obsługuje. Stanie się tak tylko wtedy , gdy sprzęt znajdujący się między nimi nie będzie przeszkadzał i spowoduje spadek lub zniekształcenie pakietu.
4. Klient może podjąć próbę ponownej kwerendy EDNS (0) z mniejszym ładunkiem reklamowanym, jeśli odpowiedź nie zostanie wyświetlona, ​​ale szczegóły mogą się różnić w zależności od implementacji.
   • Ważne jest, aby pamiętać, że odpowiedź, która w końcu ją przenosi, może być zbyt duża, aby zmieściła się w żądanym rozmiarze, co powoduje zachowanie nr 2 powyżej. (yee, spróbuj ponownie TCP)
   • Po stronie klienta może zostać zapamiętany rozmiar, który ostatecznie zakończył się sukcesem. Pozwala to uniknąć marnowania niepotrzebnych zapytań na ponowne przetestowanie. Postępowanie inaczej byłoby dość marnotrawstwem, szczególnie jeśli końcowy wynik wymagałby powrotu protokołu TCP.

Należy również pamiętać, że RFC 7766 pozwala na ponowne użycie połączenia przez TCP i możliwe jest napotkanie potoków zapytań przez TCP na wolności. Niektóre narzędzia nie wykrywają zapytań DNS wykraczających poza pierwsze zaobserwowane w sesji TCP, czego przykładem jest dnscap.

Nie jest RFC 7766 Transport DNS TCP - Wymagania wdrożeniowe .

1. Wprowadzenie

Większość transakcji DNS [ RFC1034 ] odbywa się przez UDP [ RFC768 ]. TCP [ RFC793 ] jest zawsze używany do pełnego transferu strefy (przy użyciu AXFR) i często jest używany do wiadomości, których rozmiary przekraczają pierwotny limit 512 bajtów protokołu DNS. Rosnące wdrażanie DNS Security (DNSSEC) i IPv6 zwiększyło rozmiary odpowiedzi, a tym samym korzystanie z TCP. Konieczność większego wykorzystania protokołu TCP wynika również z ochrony, jaką zapewnia przed fałszowaniem adresów, a tym samym wykorzystaniem DNS w atakach odbicia / wzmocnienia. Jest obecnie szeroko stosowany w ograniczaniu częstości odpowiedzi [ RRL1 ] [ RRL2 ]. Ponadto ostatnie prace nad rozwiązaniami prywatności DNS, takimi jak [ DNS-over-TLS] to kolejna motywacja do ponownego sprawdzenia wymagań DNS-over-TCP.

Sekcja 6.1.3.2 [RFC1123] stanowi:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Jednak niektórzy implementatorzy przyjęli cytowany powyżej tekst w ten sposób, że obsługa protokołu TCP jest opcjonalną funkcją protokołu DNS.

Większość operatorów serwerów DNS obsługuje już protokół TCP, a domyślną konfiguracją większości implementacji oprogramowania jest obsługa protokołu TCP. Główną grupą odbiorców tego dokumentu są ci implementatorzy, których ograniczona obsługa protokołu TCP ogranicza interoperacyjność i utrudnia wdrażanie nowych funkcji DNS.

Dlatego dokument ten aktualizuje podstawowe specyfikacje protokołu DNS, tak że obsługa protokołu TCP jest odtąd WYMAGANA częścią pełnej implementacji protokołu DNS.

Istnieje szereg zalet i wad zwiększonego użycia TCP (patrz Załącznik A ), a także szczegóły implementacji, które należy wziąć pod uwagę. Ten dokument rozwiązuje te problemy i przedstawia TCP jako prawidłową alternatywę transportu dla DNS. Rozszerza zawartość [ RFC5966 ], z dodatkowymi uwagami i wnioskami wyciągniętymi z badań, rozwoju i implementacji TCP w DNS i innych protokołach internetowych.

Chociaż niniejszy dokument nie zawiera żadnych szczególnych wymagań, które muszą spełnić operatorzy serwerów DNS, oferuje operatorom pewne sugestie, które pomogą zapewnić optymalną obsługę TCP na ich serwerach i sieci. Należy zauważyć, że brak obsługi TCP (lub blokowanie DNS przez TCP w warstwie sieci) prawdopodobnie spowoduje błąd rozdzielczości i / lub przekroczenia limitu czasu na poziomie aplikacji.

Nie należy filtrować TCP / 53 w żadnym kierunku. Na przykład nsupdatezapytania mogą korzystać z protokołu TCP, gdy żądanie jest zbyt duże (co może się zdarzyć szybko). Powinieneś więc pozwolić, aby UDP i TCP dla portu 53 (w IPv4 i V6!) Przepływały we wszystkich kierunkach.

Coraz więcej jest też prac nad DNS nad TLS, więc TCP będzie potrzebny w obu kierunkach. Zobacz RFC7858.