Після півтора року розробки реліз кешируючого DNS-сервера що відповідає за рекурсивне перетворення імен. PowerDNS Recursor побудований на одній кодовій базі з PowerDNS Authoritative Server, але рекурсивний та авторитетний DNS-сервери PowerDNS розвиваються в рамках різних циклів розробки та випускаються у формі окремих продуктів. Код проекту ліцензія 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 Cookies для захисту від 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). До 1232 також зменшено значення параметра truncation-threshold, що відповідає за обрізання відповідей клієнту.
Інші зміни в PowerDNS Recursor 4.2:
- Додано підтримку механізму (X-Proxied-For), що є еквівалентом HTTP-заголовка X-Forwarded-For для DNS, що дозволяє передати відомості про 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