Po półtora roku rozwoju wydanie buforującego serwera DNS , odpowiedzialny za rekursywną konwersję nazw. PowerDNS Recursor jest zbudowany w oparciu o tę samą bazę kodu, co serwer autorytatywny PowerDNS, ale rekurencyjne i autorytatywne serwery DNS PowerDNS są opracowywane w różnych cyklach rozwoju i wydawane jako osobne produkty. Kod projektu licencjonowany na licencji GPLv2.
Nowa wersja eliminuje wszystkie problemy związane z przetwarzaniem pakietów DNS z flagami EDNS. W starszych wersjach PowerDNS Recursor sprzed 2016 r. istniała praktyka ignorowania pakietów z nieobsługiwanymi flagami EDNS bez wysyłania odpowiedzi w starym formacie, odrzucając flagi EDNS zgodnie z wymaganiami specyfikacji. Wcześniej to niestandardowe zachowanie było obsługiwane w programie BIND w formie obejścia, ale w zakresie w inicjatywach lutowych , twórcy serwerów DNS postanowili porzucić ten hack.
W PowerDNS główne problemy z przetwarzaniem pakietów za pomocą EDNS zostały wyeliminowane w 2017 roku w wersji 4.1, a w gałęzi 2016 wydanej w 4.0 roku pojawiły się indywidualne niezgodności, które pojawiają się w określonych okolicznościach i ogólnie nie zakłócają normalnego działania operacja. W PowerDNS Recursor 4.2, jak w , Usunięto obejścia umożliwiające obsługę autorytatywnych serwerów, które niepoprawnie odpowiadają na żądania za pomocą flag EDNS. Do tej pory, jeśli po wysłaniu żądania z flagami EDNS nie było odpowiedzi po pewnym czasie, serwer DNS zakładał, że flagi rozszerzone nie są obsługiwane i wysyłał drugie żądanie bez flag EDNS. To zachowanie zostało teraz wyłączone, ponieważ ten kod powodował zwiększone opóźnienia z powodu retransmisji pakietów, zwiększone obciążenie sieci i niejednoznaczność w przypadku braku odpowiedzi z powodu awarii sieci, a także uniemożliwiał wdrożenie funkcji opartych na EDNS, takich jak pliki cookie DNS w celu ochrony przed atakami DDoS.
Podjęto decyzję o zorganizowaniu wydarzenia w przyszłym roku zaprojektowany tak, aby skupiać uwagę z fragmentacją IP podczas przetwarzania dużych wiadomości DNS. W ramach inicjatywy naprawić zalecane rozmiary buforów dla EDNS na 1200 bajtów, oraz Przetwarzanie żądań za pośrednictwem protokołu TCP jest niezbędną funkcją na serwerach. Teraz wymagana jest obsługa przetwarzania żądań poprzez UDP, a protokół TCP jest pożądany, ale nie wymagany do działania (standard wymaga możliwości wyłączenia protokołu TCP). Proponuje się usunięcie opcji wyłączenia protokołu TCP ze standardu i ujednolicenie przejścia od wysyłania żądań przez UDP do korzystania z protokołu TCP w przypadkach, gdy ustalony rozmiar bufora EDNS jest niewystarczający.
Zmiany zaproponowane w ramach inicjatywy wyeliminują zamieszanie przy wyborze wielkości bufora EDNS oraz rozwiążą problem fragmentacji dużych komunikatów UDP, których przetwarzanie często prowadzi do utraty pakietów i przekroczeń limitów czasu po stronie klienta. Po stronie klienta rozmiar bufora EDNS będzie stały, a duże odpowiedzi będą natychmiast wysyłane do klienta przez protokół TCP. Unikanie wysyłania dużych wiadomości przez UDP również umożliwi blokowanie do zatruwania pamięci podręcznej DNS, polegającej na manipulacji pofragmentowanymi pakietami UDP (przy podzieleniu na fragmenty drugi fragment nie zawiera nagłówka z identyfikatorem, więc można go sfałszować, do czego wystarczy tylko zgodność sumy kontrolnej) .
PowerDNS Recursor 4.2 uwzględnia problemy z dużymi pakietami UDP i przełącza na wykorzystanie rozmiaru bufora EDNS (edns-outgoing-bufsize) wynoszącego 1232 bajty zamiast dotychczas stosowanego limitu 1680 bajtów, co powinno znacząco zmniejszyć prawdopodobieństwo utraty pakietów UDP . Wybrano wartość 1232, ponieważ jest to maksimum, przy którym rozmiar odpowiedzi DNS, biorąc pod uwagę IPv6, mieści się w minimalnej wartości MTU (1280). Do 1232 obniżono także wartość parametru truncation-threshold, który odpowiada za przycinanie odpowiedzi do klienta.
Inne zmiany w PowerDNS Recursor 4.2:
- Dodano obsługę mechanizmu (X-Proxied-For), który jest odpowiednikiem DNS nagłówka HTTP X-Forwarded-For, umożliwiającym przesyłanie informacji o adresie IP i numerze portu pierwotnego requestera przez pośrednie proxy i moduły równoważenia obciążenia (takie jak dnsdist) . Aby włączyć XPF, dostępne są opcje „"A"";
- Ulepszona obsługa rozszerzenia EDNS (ECS), który umożliwia przesyłanie w zapytaniach DNS do autorytatywnego serwera DNS informacji o podsieci, z której początkowe żądanie przesłane wzdłuż łańcucha zostało zatrute (dane o podsieci źródłowej klienta są niezbędne do efektywnego działania sieci dostarczania treści) . Nowa wersja dodaje ustawienia umożliwiające selektywną kontrolę nad wykorzystaniem podsieci klienta EDNS: „» z listą masek sieci, dla których adres IP będzie używany w ECS w żądaniach wychodzących. W przypadku adresów, które nie mieszczą się w określonych maskach, adres ogólny określony w dyrektywie „„. Poprzez dyrektywę”» możesz zdefiniować podsieci, z których przychodzące żądania z wypełnionymi wartościami ECS nie będą zastępowane;
- W przypadku serwerów przetwarzających dużą liczbę żądań na sekundę (ponad 100 tysięcy) dyrektywa „", który określa liczbę wątków odbierających przychodzące żądania i rozdzielających je pomiędzy wątki robocze (ma sens tylko przy użyciu opcji "").
- Dodano ustawienie za pomocą którego możesz zdefiniować własny plik domeny, w których użytkownicy mogą rejestrować swoje subdomeny, zamiast listy wbudowanej w PowerDNS Recursor.
Projekt PowerDNS ogłosił również przejście do sześciomiesięcznego cyklu rozwojowego, a kolejne główne wydanie PowerDNS Recursor 4.3 spodziewane jest w styczniu 2020 r. Aktualizacje istotnych wydań będą opracowywane przez cały rok, po czym na kolejne sześć miesięcy będą udostępniane poprawki luk. Tym samym wsparcie dla gałęzi PowerDNS Recursor 4.2 potrwa do stycznia 2021 roku. Podobne zmiany w cyklu rozwoju wprowadzono dla serwera autorytatywnego PowerDNS, którego wersja 4.2 ma zostać wydana w najbliższej przyszłości.
Główne cechy PowerDNS Recursor:
- Narzędzia do zdalnego gromadzenia statystyk;
- Natychmiastowy restart;
- Wbudowany silnik do łączenia handlerów w języku Lua;
- Pełna obsługa DNSSEC i ;
- Wsparcie dla RPZ (Response Policy Zones) i możliwość definiowania czarnych list;
- Mechanizmy zapobiegające fałszowaniu;
- Możliwość rejestrowania wyników rozdzielczości jako pliki strefy BIND.
- Aby zapewnić wysoką wydajność, we FreeBSD, Linux i Solaris zastosowano nowoczesne mechanizmy multipleksowania połączeń (kqueue, epoll, /dev/poll), a także wydajny parser pakietów DNS zdolny do przetwarzania dziesiątek tysięcy równoległych żądań.
Źródło: opennet.ru