След година и половина разработка освобождаване на кеширащ DNS сървър , отговорен за рекурсивното преобразуване на имена. PowerDNS Recursor е изграден на същата кодова база като PowerDNS Authoritative Server, но PowerDNS рекурсивните и авторитетните DNS сървъри са разработени чрез различни цикли на разработка и се пускат като отделни продукти. Код на проекта лицензиран под GPLv2.
Новата версия елиминира всички проблеми, свързани с обработката на DNS пакети с EDNS флагове. По-старите версии на PowerDNS Recursor преди 2016 г. имаха практиката да игнорират пакети с неподдържани EDNS флагове, без да изпращат отговор в стария формат, като отхвърлят EDNS флаговете, както се изисква от спецификацията. По-рано това нестандартно поведение се поддържаше в BIND под формата на заобиколно решение, но в обхвата на през февруари инициативи , разработчиците на DNS сървъри решиха да изоставят този хак.
В PowerDNS основните проблеми при обработката на пакети с EDNS бяха елиминирани през 2017 г. във версия 4.1, а в клона 2016, издаден през 4.0 г., се появиха отделни несъвместимости, които възникват при определен набор от обстоятелства и като цяло не пречат на нормалното операция. В PowerDNS Recursor 4.2, както в , Премахнати заобиколни решения за поддръжка на авторитетни сървъри, които отговарят неправилно на заявки с EDNS флагове. Досега, ако след изпращане на заявка с EDNS флагове нямаше отговор след определен период от време, DNS сървърът приемаше, че разширените флагове не се поддържат и изпращаше втора заявка без EDNS флагове. Това поведение вече е деактивирано, тъй като този код доведе до увеличено забавяне поради повторно предаване на пакети, увеличено натоварване на мрежата и неяснота, когато не отговаря поради мрежови повреди, и предотврати внедряването на базирани на EDNS функции, като например DNS бисквитки, за защита срещу DDoS атаки.
Решено е събитието да се проведе догодина предназначени да фокусират вниманието върху с IP фрагментация при обработка на големи DNS съобщения. Като част от инициативата коригирайте препоръчителните размери на буфера за EDNS на 1200 байта и обработката на заявки чрез TCP е задължителна функция на сървърите. Сега е необходима поддръжка за обработка на заявки чрез UDP и TCP е желателно, но не е необходимо за работа (стандартът изисква възможност за деактивиране на TCP). Предлага се да се премахне опцията за деактивиране на TCP от стандарта и да се стандартизира преходът от изпращане на заявки през UDP към използване на TCP в случаите, когато установеният размер на EDNS буфера не е достатъчен.
Промените, предложени като част от инициативата, ще премахнат объркването при избора на размера на EDNS буфера и ще решат проблема с фрагментацията на големи UDP съобщения, чиято обработка често води до загуба на пакети и изчакване от страна на клиента. От страна на клиента размерът на EDNS буфера ще бъде постоянен и големите отговори ще бъдат изпращани незабавно на клиента през TCP. Избягването на изпращане на големи съобщения през UDP също ще ви позволи да блокирате за отравяне на DNS кеша, базирано на манипулиране на фрагментирани UDP пакети (когато е разделен на фрагменти, вторият фрагмент не включва хедър с идентификатор, така че може да бъде подправен, за което е достатъчно само контролната сума да съвпадне) .
PowerDNS Recursor 4.2 взема предвид проблемите с големи UDP пакети и превключва към използване на размера на EDNS буфера (edns-outgoing-bufsize) от 1232 байта, вместо използваното по-рано ограничение от 1680 байта, което трябва значително да намали вероятността от загуба на UDP пакети . Стойността 1232 е избрана, защото това е максимумът, при който размерът на DNS отговора, като се вземе предвид IPv6, се вписва в минималната MTU стойност (1280). Стойността на параметъра trunction-threshold, който отговаря за изрязването на отговорите към клиента, също е намалена до 1232.
Други промени в PowerDNS Recursor 4.2:
- Добавена поддръжка на механизъм (X-Proxied-For), което е DNS еквивалентът на X-Forwarded-For HTTP хедъра, позволяващ информацията за IP адреса и номера на порта на оригиналния рикуестър да бъде препращана чрез междинни прокси сървъри и балансьори на натоварването (като dnsdist) . За да активирате XPF има опции ""И"";
- Подобрена поддръжка за разширение EDNS (ECS), което ви позволява да предавате в DNS заявки към авторитетен DNS сървър информация за подмрежата, от която първоначалната заявка, предадена по веригата, е била отровена (данните за изходната подмрежа на клиента са необходими за ефективната работа на мрежите за доставка на съдържание) . Новата версия добавя настройки за селективен контрол върху използването на EDNS Client Subnet: "» със списък от мрежови маски, за които IP ще се използва в ECS при изходящи заявки. За адреси, които не попадат в посочените маски, общият адрес, посочен в директивата "". Чрез директивата "» можете да дефинирате подмрежи, от които входящите заявки с попълнени ECS стойности няма да бъдат заменени;
- За сървъри, обработващи голям брой заявки в секунда (повече от 100 хиляди), директивата „", който определя броя на нишките за получаване на входящи заявки и разпределянето им между работни нишки (има смисъл само при използване на "").
- Добавена настройка с който да дефинирате свой собствен файл домейни, в които потребителите могат да регистрират своите поддомейни, вместо списъка, вграден в PowerDNS Recursor.
Проектът PowerDNS също обяви преминаване към шестмесечен цикъл на разработка, като следващото голямо издание на PowerDNS Recursor 4.3 се очаква през януари 2020 г. Актуализации за значими версии ще се разработват през цялата година, след което корекциите на уязвимостите ще бъдат пуснати за още шест месеца. По този начин поддръжката за клона PowerDNS Recursor 4.2 ще продължи до януари 2021 г. Подобни промени в цикъла на разработка са направени за PowerDNS Authoritative Server, който се очаква да пусне 4.2 в близко бъдеще.
Основни характеристики на PowerDNS Recursor:
- Инструменти за дистанционно събиране на статистика;
- Моментално рестартиране;
- Вграден двигател за свързване на манипулатори на езика Lua;
- Пълна поддръжка на DNSSEC и ;
- Поддръжка на RPZ (Response Policy Zones) и възможност за дефиниране на черни списъци;
- Анти-спуфинг механизми;
- Възможност за записване на резултати от разделителната способност като BIND зонови файлове.
- За да се осигури висока производителност, модерни механизми за мултиплексиране на връзки се използват във FreeBSD, Linux и Solaris (kqueue, epoll, /dev/poll), както и високоефективен анализатор на DNS пакети, способен да обработва десетки хиляди паралелни заявки.
Източник: opennet.ru