Inicjatywa DNS flag day 2020 mająca na celu rozwiązanie problemów z fragmentacją i wsparciem dla TCP

Dziś szereg dużych usług DNS i producentów serwerów DNS przeprowadzi wspólne wydarzenie Dzień flagi DNS 2020, mające na celu zwrócenie uwagi na rozwiązanie problemach problemów z fragmentacją IP podczas przetwarzania dużych komunikatów DNS. Jest to druga podobna inicjatywa, w zeszłym roku "Dzień flagi DNS" skoncentrował się na poprawnym przetwarzaniu zapytań EDNS.

Uczestnicy inicjatywy Dzień flagi DNS 2020 wzywają do ustalenia zalecanych rozmiarów buforów dla EDNS na poziomie 1232 bajtów (rozmiar MTU 1280 minus 48 bajtów na nagłówki), a także do wprowadzenia przetwarzania zapytań przez TCP jako obowiązkowo wspieranego na serwerach. W RFC 1035 obowiązkowe jest tylko wsparcie dla przetwarzania zapytań przez UDP, podczas gdy TCP wskazane jest jako pożądane, ale nieobowiązkowe do działania. Nowe RFC 7766 i RFC 5966 wyraźnie klasyfikują TCP jako jedną z obowiązkowych funkcji, niezbędnych do poprawnej pracy DNS. W ramach prowadzony inicjatywy proponuje się wymusić przejście od wysyłania zapytań przez UDP do zastosowania TCP w przypadkach, gdy ustalony rozmiar bufora EDNS jest niewystarczający.

Proponowane zmiany zlikwidują zamieszanie związane z wyborem rozmiaru bufora EDNS i rozwiążą problem z fragmentacją dużych komunikatów UDP, przetwarzanie których często prowadzi do utraty pakietów i przekroczeń czasowych po stronie klienta. Po stronie klienta rozmiar bufora EDNS będzie stały, a duże odpowiedzi będą od razu wysyłane do klienta przez TCP. Wyłączenie wysyłania dużych komunikatów przez UDP również rozwiąże problemy z odrzucaniem dużych pakietów na niektórych zaporach ogniowych i pozwoli zablokować atak ataków na pamięć podręczną DNS opartych na manipulacji fragmentowanymi pakietami UDP (przy podziale na fragmenty, drugi fragment nie zawiera nagłówka z identyfikatorem, dlatego może być fałszowany, co wystarczy, aby pasowała suma kontrolna).

Od dzisiaj uczestniczący w inicjatywie dostawcy DNS, w tym CloudFlare, Quad 9, Cisco (OpenDNS) i Google, stopniowo zmienią Rozmiar bufora EDNS z 4096 do 1232 bajtów na swoich serwerach DNS (zmiana EDNS będzie rozłożona na 4-6 tygodni i z czasem będzie obejmować coraz większą liczbę zapytań). Odpowiedzi na zapytania UDP, które nie mieszczą się w nowym limicie, będą wysyłane przez TCP. Producenci serwerów DNS, w tym BIND, Unbound, Knot, NSD i PowerDNS, wydadzą aktualizacje zmieniające domyślny rozmiar bufora EDNS z 4096 do 1232 bajtów.

Ostatecznie wprowadzone zmiany mogą prowadzić do problemów z rozwiązywaniem przy użyciu serwerów DNS, których odpowiedzi DNS przez UDP przekraczają 1232 bajty i które nie mogą wysłać odpowiedzi przez TCP. Eksperyment przeprowadzony przez Google wykazał, że zmiana rozmiaru bufora EDNS praktycznie nie wpłynie na poziom awarii — przy buforze 4096 bajtów liczba obcinanych zapytań UDP wynosi 0.345%, a liczba niedostępnych odpowiedzi powtarzających się przez TCP — 0.115%. Przy buforze 1232 bajtów wskaźniki te wynoszą 0.367% i 0.116%. Wprowadzenie wsparcia TCP jako obowiązkowej funkcji DNS spowoduje problemy w interakcji z około 0.1% serwerów DNS. Zauważa się, że w obecnych warunkach praca tych serwerów bez TCP jest i tak niestabilna.

Administratorzy autorytatywnych (authoritative) serwerów DNS powinni upewnić się, że ich serwer odpowiada przez TCP na porcie sieciowym 53 i że ten port TCP nie jest blokowany przez zaporę sieciową. Autorytatywny serwer DNS nie powinien również wysyłać odpowiedzi UDP, których rozmiar przekracza
żądany rozmiar bufora EDNS. Na samym serwerze rozmiar bufora EDNS powinien być ustawiony na 1232 bajty. Do resolverów stawiane są w przybliżeniu takie same wymagania — obowiązkowa możliwość odpowiedzi przez TCP, obowiązkowe wsparcie wysyłania powtarzających się zapytań przez TCP przy otrzymywaniu obciętej odpowiedzi UDP oraz ustawienie bufora EDNS na 1232 bajty.

Za konfigurację rozmiaru bufora EDNS w różnych serwerach DNS odpowiadają następujące parametry: