Po półtora roku prac rozwojowych premiera serwera DNS z pamięcią podręczną , odpowiedzialnego za rekurencyjne przekształcanie nazw. PowerDNS Recursor zbudowany jest na tej samej bazie kodowej co PowerDNS Authoritative Server, ale serwery DNS rekurencyjne i autorytatywne PowerDNS rozwijane są w ramach różnych cykli rozwoju i wydawane w formie oddzielnych produktów. Kod projektu na licencji GPLv2.
W nowej wersji usunięto wszystkie uwagi związane z obsługą pakietów DNS z flagami EDNS. W starych wersjach PowerDNS Recursor do 2016 roku ignorowano pakiety z nieobsługiwanymi flagami EDNS, nie wysyłając odpowiedzi w starym formacie, odrzucając flagi EDNS, jak wymaga specyfikacja. Wcześniej takie niestandardowe zachowanie było wspierane w BIND w formie obejścia, ale w ramach w lutym inicjatywy , deweloperzy serwerów DNS podjęli decyzję o zaprzestaniu korzystania z tego obejścia.
W PowerDNS główne problemy z obsługą pakietów EDNS zostały rozwiązane już w 2017 roku w wersji 4.1, a w wydanym w 2016 roku wydaniu 4.0 występowały pojedyncze niezgodności, pojawiające się przy określonych okolicznościach, które generalnie nie miały wpływu na normalne działanie. W PowerDNS Recursor 4.2, podobnie jak w , usunięto obejścia wspierające autorytatywne serwery, które nieprawidłowo odpowiadały na zapytania z flagami EDNS. Do tej pory, jeśli po wysłaniu zapytania z flagami EDNS przez określony czas nie otrzymano odpowiedzi, serwer DNS uważał, że rozszerzone flagi nie są wspierane i wysyłał ponowne zapytanie bez flagów EDNS. Od teraz takie zachowanie zostało wyłączone, ponieważ obecność tego typu kodu prowadziła do zwiększenia opóźnień z powodu ponownego wysyłania pakietów, zwiększenia obciążenia sieci i niejednoznaczności w przypadku braku odpowiedzi z powodu awarii sieci, a także utrudniała wdrażanie funkcji opartych na EDNS, takich jak stosowanie ciasteczek DNS w celu ochrony przed atakami DDoS.
W następnym roku postanowiono zorganizować wydarzenie , mające na celu zwrócenie uwagi na z fragmentacją IP przy obsłudze wiadomości DNS o dużych rozmiarach. W ramach inicjatywy zarekomendować rozmiary buforów dla EDNS na poziomie do 1200 bajtów, a także obsługę zapytań przez TCP w kategorii obowiązkowo wspieranych na serwerach. Obecnie wymagana jest obsługa zapytań przez UDP, a TCP jest pożądane, ale nieobowiązkowe do działania (standard przewiduje możliwość wyłączenia TCP). Proponuje się usunięcie z standardu opcji wyłączenia TCP i ujednolicenie przejścia od wysyłania zapytań przez UDP do stosowania TCP w przypadkach, gdy ustalony rozmiar bufora EDNS jest niewystarczający.
Proponowane w ramach inicjatywy zmiany rozwiążą problemy z wyborem rozmiaru bufora EDNS oraz rozwiążą kwestię fragmentacji dużych komunikatów UDP, której przetwarzanie często prowadzi do utraty pakietów i przekroczeń czasu na 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. Wykluczenie wysyłania dużych komunikatów przez UDP pozwoli również na blokowanie 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).
W PowerDNS Recursor 4.2 uwzględniono problemy z dużymi pakietami UDP i dokonano przejścia na wykorzystanie rozmiaru bufora EDNS (edns-outgoing-bufsize) w 1232 bajty, zamiast wcześniej stosowanego limitu 1680 bajtów, co powinno znacząco zmniejszyć prawdopodobieństwo utraty pakietów UDP. Wartość 1232 została wybrana, ponieważ jest to maksimum, przy którym rozmiar odpowiedzi DNS z uwzględnieniem IPv6 mieści się w minimalnej wartości MTU (1280). Do 1232 również zmniejszono wartość parametru truncation-threshold, odpowiedzialnego za obcinanie odpowiedzi dla klienta.
Inne zmiany w PowerDNS Recursor 4.2:
- Dodano wsparcie dla mechanizmu (X-Proxied-For), który jest odpowiednikiem nagłówka HTTP X-Forwarded-For w DNS, umożliwiającym przesyłanie informacji o adresie IP oraz numerze portu pierwotnego inicjatora zapytania, przekazywanego przez pośrednie serwery proxy i load balancery (np. dnsdist). Aby włączyć XPF, przewidziano opcje „” i „«;
- Udoskonalona obsługa rozszerzenia EDNS (ECS), pozwalająca przesyłać w zapytaniach DNS do serwera DNS informacje o podsieci, z której wysłano oryginalne zapytanie przesyłane w łańcuchu (informacje o oryginalnej podsieci klienta są niezbędne do skutecznego działania sieci dostarczania treści). W nowej wersji dodano opcje do selektywnego kontrolowania zastosowania EDNS Client Subnet: „” z listą masek sieciowych, dla których IP będzie używany w ECS w wychodzących zapytaniach. Dla adresów, które nie mieszczą się w wskazanych maskach, używany będzie wspólny adres określony w dyrektywie „“. Przez dyrektywę „” można określić podsieci, w których przychodzące zapytania z uzupełnionymi wartościami ECS nie będą wymieniane;
- Dla serwerów przetwarzających dużą liczbę zapytań na sekundę (ponad 100 tysięcy) zaproponowano dyrektywę „«, określająca liczbę wątków do przyjmowania przychodzących żądań i ich rozdzielania między wątki robocze (ma to sens tylko w trybie „«).
- Dodano ustawienie do określenia własnego pliku z domen, w których użytkownicy mogą rejestrować swoje subdomeny, zamiast wbudowanej w PowerDNS Recursor listy.
Projekt PowerDNS ogłosił również przejście na sześciomiesięczny cykl rozwoju, zgodnie z którym następna znacząca wersja PowerDNS Recursor 4.3 jest oczekiwana w styczniu 2020 roku. Aktualizacje dla znacznych wydań będą formowane przez cały rok, po czym przez kolejne pół roku będą wydawane poprawki bezpieczeństwa. W ten sposób wsparcie dla gałęzi PowerDNS Recursor 4.2 potrwa do stycznia 2021 roku. Podobne zmiany cyklu rozwoju przyjęto dla produktu PowerDNS Authoritative Server, którego wersja 4.2 jest oczekiwana w najbliższym czasie.
Główne cechy PowerDNS Recursor:
- Narzędzia do zdalnego zbierania statystyk;
- Natychmiastowy restart;
- Wbudowany silnik do podłączania procesorów w języku Lua;
- Pełne wsparcie dla DNSSEC i ;
- Wsparcie dla RPZ (Response Policy Zones) oraz możliwość definiowania czarnych list;
- Mechanizmy przeciwdziałania spoofingowi;
- Możliwość zapisywania wyników rozwiązywania w postaci plików stref BIND.
- W celu zapewnienia wysokiej wydajności wykorzystuje się nowoczesne mechanizmy multiplexerowania połączeń w FreeBSD, Linux i Solaris (kqueue, epoll, /dev/poll), a także wysoko wydajny parser pakietów DNS, zdolny do obsługi dziesiątek tysięcy równoległych zapytań.
Źródło: opennet.ru
