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

33

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ć.

Caderade
źródło
2
Przywołując @Alnitak, rozmawiamy o twoim dziecku. :)
Andrew B
Jak zmusić domyślne zapytanie DNS do działania w trybie TCP? . Chociaż system OS X / macOS q / a z niektórymi modami działa również w systemie Linux / Windows.
klanomath
Oczywiście w dzisiejszych czasach z DNS przez HTTPS i DNS przez TLS, a wkrótce DNS przez QUIC ...
Patrick Mevzek
Dlaczego nie przekierować wszystkich zapytań DNS do (a) wybranych serwerów DNS?
Craig Hicks

Odpowiedzi:

38

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

George Erhard
źródło
1
Dzięki George, naprawdę pomocne rzeczy! Aby więc szybko wyjaśnić pierwsze zdanie - pakiet UDP może zmieścić tylko 512 bajtów, prawda? Więc jeśli zapytanie DNS było większe niż 512, czy nie zaczynałoby się od TCP bezpośrednio z bramki? Próbowałem to przetestować sam, uruchamiając wireshark i używając nslookup do rozwiązywania dużych domen, ale wydaje się, że blokuje mnie to przed próbowaniem domen większych niż 200 znaków (nie jest to dokładna liczba, ale chodzi o to, że nie mogłem w pełni przetestować tego scenariusza) .
Caderade
3
To nie jest „zapytanie”, ale „odpowiedź” to ponad 512 bajtów, a klient nie wiedziałby, jaka byłaby „odpowiedź”.
AbraCadaver
7
@Caderade Tak, masz rację, że mogą to być TCP lub UDP, jednak tylko transfery stref będą się zaczynać jako TCP. Zapytania klientów będą miały charakter UDP, chyba że otrzymają odpowiedź z serwera z ustawionym bitem obcięcia. Następnie można użyć protokołu TCP.
AbraCadaver
1
Czy mimo to klienci mogą używać protokołu TCP do małych odpowiedzi?
Mehrdad,
2
„Pakiet UDP może zmieścić tylko 512 bajtów” Nie, to założenie, że bufor klienta może zmieścić tylko 512 bajtów, co powoduje, że serwery zachowują się w ten sposób. Serwery mogą być powiadamiane o dłuższym buforze za pomocą EDNS.
Bryan
28

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.

Andrew B.
źródło
Jednym z powodów, dla których należy ustawić bit obcinany, jest ograniczenie szybkości odpowiedzi (RRL). Jako technika ograniczania wzmocnienia DNS serwer może wysyłać skrócone pakiety, aby dobrze zachowujący się klienci przełączali się na TCP, miejmy nadzieję zapobiegając odpowiedziom na pakiety z fałszywych adresów.
Edheldil
Ponowne użycie połączenia: więc naucz swój resolver, aby najpierw poprosił o google.com, zanim poprosi o scantycladladies.com, a następnie dnscap nie zauważy. ;-)
Lenne
6

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.

Ron Maupin
źródło
2
Hej Ron - faktycznie przeczytałem ten komunikat RFC przed opublikowaniem, ale na przykład, jeśli spojrzysz na pierwszy akapit, wydaje się, że podkreśla on, że TCP jest wymagany do obsługi większych odpowiedzi - „Rosnące wdrażanie zabezpieczeń DNS (DNSSEC) i IPv6 ma zwiększone rozmiary odpowiedzi i dlatego użycie TCP ". Ponownie moje pytanie dotyczyło zapytań, ale i tak dziękuję.
Caderade
4
RFC wyraźnie mówi, że protokół DNS musi być obsługiwany przez DNS, i omawia użycie TCP przez klientów. Na przykład „ Klienci korzystający z protokołu TCP dla DNS muszą zawsze być przygotowani do ponownego nawiązania połączenia lub w inny sposób ponowić zaległe zapytania.
Ron Maupin
Słuszna uwaga. Powiedziałbym, że ten komentarz był naprawdę pomocny, biorąc pod uwagę dodatkową przejrzystość. Chodzi mi o to, że faktycznie przeczytałem RFC i nadal nie było dla mnie bardzo jasne, że zapytania mogą zaczynać się przy użyciu TCP, więc kiedy po prostu zrzucisz RFC w celu uzyskania odpowiedzi, chociaż jest to komiczne, nie było to naprawdę pomocne. Przeczytałem mi, że zapytania przechodzą przez UDP, a jeśli odpowiedź jest zbyt duża, serwer DNS poinformuje klienta, że ​​musi zacząć wszystko od nowa i wykonać to przez TCP. Pomyślałem więc, że nadal spełnię moje pierwotne wymaganie, ponieważ uchwyciłbym pierwotne żądanie. Niezależnie od tego, doceniam twój wkład.
Caderade
1
INTERNET STANDARDRFC jest tools.ietf.org/html/rfc1034 . Cytujesz, PROPOSED STANDARDaby wymagać TCP.
AbraCadaver
3
To jest RFC Standard Track, który zaktualizował poprzedni RFC Track Standards o to samo. Ta odpowiedź tutaj na błędzie serwera wyjaśnia takie rzeczy. Nawet w dokumencie, do którego się odwołujesz, napisano: „ W Internecie zapytania są przeprowadzane w datagramach UDP lub przez połączenia TCP. ” RFC 7766 ma wyjaśnić, że TCP jest wymaganą, a nie opcjonalną częścią DNS.
Ron Maupin
3

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.

Patrick Mevzek
źródło
pytanie nie ma nic wspólnego z filtrowaniem, a twoja odpowiedź nic nie dodaje w stosunku do innych odpowiedzi
Bryan
@Bryan dzięki za bardzo pomocny i użyteczny komentarz!
Patrick Mevzek
@PatrickMevzek Zrozumiałem - próbowałem powiedzieć, że zezwalamy na ruch tylko do określonych adresów IP poza naszym obwodem przez port 53 (chociaż dozwolone są TCP i UDP).
Caderade