The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +/
Сообщение от opennews (??), 16-Июл-19, 13:08 
После полутора лет разработки представлен (https://blog.powerdns.com/2019/07/15/powerdns-recursor-4-2-0.../) релиз кэшируюшего DNS-сервера PowerDNS Recursor 4.2 (https://www.powerdns.com/recursor.html), отвечающего за рекурсивное преобразование имён. PowerDNS Recursor построен на одной кодовой базе с PowerDNS Authoritative Server, но рекурсивный и авторитетный DNS-серверы  PowerDNS развиваются  в рамках разных циклов разработки и выпускаются в форме отдельных продуктов. Код проекта распространяется (https://github.com/PowerDNS/pdns) под лицензией GPLv2.


В новой версии устранены все замечания, связанные с обработкой DNS-пакетов с флагами EDNS. В старых версиях PowerDNS Recursor до 2016 года практиковалось игнорирование пакетов с не поддерживаемыми флагами EDNS, без отправки ответа в старом формате, отбрасывая флаги EDNS, как того требует спецификация. Ранее подобное нестандартное поведение поддерживалось в BIND в форме обходного манёвра, но в рамках проведённой (https://www.opennet.ru/opennews/art.shtml?num=49999) в феврале инициативы DNS flag day (https://dnsflagday.net/2020/), разработчики DNS-серверов приняли решение отказаться от данного хака.


В PowerDNS основные проблемы в обработке пакетов с EDNS были устранены ещё в 2017 году в выпуске 4.1, а в выпущенной в 2016 году ветке 4.0 всплывали отдельные несовместимости, возникающие при определённом стечении обстоятельств и в общем виде не мешающие нормальной работе.  В PowerDNS Recursor 4.2, как и в BIND 9.14 (https://www.opennet.ru/opennews/art.shtml?num=50372), удалены обходные пути поддержки авторитетных серверов, некорректно отвечающих на запросы с флагами EDNS. До сих пор, если после отправки запроса с флагами EDNS через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS. Отныне данное поведение отключено, так как наличие подобного кода приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies для защиты от DDoS-атак.

В следующем году решено провести мероприятие DNS flag day 2020 (https://dnsflagday.net/2020/), призванное сфокусировать внимание на решении (https://tools.ietf.org/html/draft-bonica-intarea-frag-fragil...) проблем (https://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html) с IP-фрагментацией при обработке DNS-сообщений большого размера. В рамках инициативы планируется (https://lists.dns-oarc.net/pipermail/dns-operations/2019-May...)  зафиксировать рекомендованные размеры буферов для EDNS до значений на уровне 1200 байт, а также  перевести (https://github.com/dns-violations/dnsflagday/issues/89) обработку запросов по TCP в разряд обязательно поддерживаемых на серверах. Сейчас обязательна поддержка обработки запросов по UDP, а TCP желателен, но не обязателен для работы (стандарт предписывает наличие возможности отключения TCP). Предлагается удалить из стандарта опцию отключения TCP и стандартизировать переход от отправки запроcов по UDP к применению TCP в случаях, когда установленного размера буфера EDNS недостаточно.

Предложенные в рамках инициативы изменения избавят от путаницы с выбором размера буфера EDNS и решат проблему с фрагментацией больших UDP-сообщений, обработка которых нередко приводит к потере пакетов и таймаутам на стороне клиента. На стороне клиента размер буфера EDNS будет постоянным, а большие ответы сразу будут отправляться клиенту по TCP. Исключение отправки больших сообщений по UDP также позволит блокировать атаки (https://indico.dns-oarc.net/event/31/contributions/692/attac...) по отравлению кэша  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:


-  Добавлена поддержка механизма XPF (https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04) (X-Proxied-For), представляющего собой эквивалент HTTP-заголовка X-Forwarded-For для DNS, позволяющего передать сведения об IP-адресе и номере порта изначального инициатора запроса, перенаправленного через промежуточные прокси и балансировщики нагрузки (например dnsdist). Для включения XPF предусмотрены опции "xpf-allow-from (https://doc.powerdns.com/recursor/settings.html#xpf-allow-from)" и "xpf-rr-code (https://doc.powerdns.com/recursor/settings.html#xpf-rr-code)";
-  Улучшена поддержка EDNS-расширения Client Subnet (https://tools.ietf.org/html/rfc7871.html) (ECS), позволяющая передавать в DNS-запросах авторитетному DNS-серверу сведения о подсети, из которой был отравлен транслируемый по цепочке изначальный запрос (данные об исходной подсети клиента необходимы для эффективной работы сетей доставки контента). В новом выпуске добавлены настройки для выборочного контроля за применением EDNS Client Subnet: "ecs-add-for (https://doc.powerdns.com/recursor/settings.html#ecs-add-for)" со списком сетевых масок, для которых IP будет использован в ECS в исходящих запросах. Для адресов, которые не подпадают под указанные маски, будет использован общий адрес, указанный в директиве "ecs-scope-zero-address (https://doc.powerdns.com/recursor/settings.html#ecs-scope-ze...)". Через директиву "use-incoming-edns-subnet (https://doc.powerdns.com/recursor/settings.html#use-incoming...)" можно определить подсети, входящие запросы с заполненными значениями ECS из которых не будут заменяться;


-  Для серверов, обрабатывающих большое число запросов в секунду (более 100 тысяч), предложена директива "distributor-threads (https://doc.powerdns.com/recursor/settings.html#distributor-...)", определяющая число потоков для приема входящих запросов и их распределения между рабочими потоками (имеет смысл только при использовании режима "pdns-distributes-queries=yes (https://doc.powerdns.com/recursor/settings.html#pdns-distrib...)").

-  Добавлена настройка public-suffix-list-file (https://doc.powerdns.com/recursor/settings.html#public-suffi...) для определения собственного файла со списком публичных суффиксов (https://publicsuffix.org/) доменов, в которых пользователи могут регистрировать свои поддомены, вместо встроенного в PowerDNS Recursor списка.


Проект PowerDNS также объявил о переходе на шестимесячный цикл разработки, в соответствии с которым следующий значительный релиз PowerDNS Recursor 4.3 ожидается в январе 2020 года. Обновления для значительных выпусков будут формироваться в течение года, после чего ещё полгода будут выпускаться исправления уязвимостей. Таким образом поддержка ветки PowerDNS Recursor 4.2 продлится до января 2021 года. Аналогичные изменения цикла разработки приняты для продукта PowerDNS Authoritative Server, выпуск 4.2 которого ожидается в ближайшее время.


Основные особенности PowerDNS Recursor:


-  Средства для удалённого сбора статистики;
-  Мгновенный перезапуск;
-  Встроенный движок для подключения обработчиков на языке Lua;
-  Полноценная поддержка DNSSEC и DNS64 (https://doc.powerdns.com/recursor/dns64.html);
-  Поддержка RPZ (Response Policy Zones) и возможность определения чёрных списков;
-  Механизмы борьбы со спуфингом;
-  Возможност...

URL: https://blog.powerdns.com/2019/07/15/powerdns-recursor-4-2-0.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=51102

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +3 +/
Сообщение от Аноним (1), 16-Июл-19, 13:08 
> Улучшена поддержка EDNS-расширения Client Subnet (ECS), позволяющая передавать в DNS-запросах авторитетному DNS-серверу сведения о подсети, из которой был отравлен транслируемый по цепочке изначальный запрос (данные об исходной подсети клиента необходимы для эффективной работы сетей доставки контента).

Хм...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +3 +/
Сообщение от Вы забыли заполнить поле Name. (?), 16-Июл-19, 13:45 
В этом мире я уже ничему не удивляюсь.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  –3 +/
Сообщение от Аноним (2), 16-Июл-19, 13:19 
> Отныне данное поведение отключено, так как наличие подобного
> кода приводило к увеличению задержек из-за повторной отправки
> пакетов, повышению нагрузки на сеть и неоднозначности при
> отсутствии ответа из-за сетевых сбоев

вот теперь-то SERVFAIL вместо "увеличения задержек" - это как нада, ага.
И однозначна, ага. "чотанеработает", куда уж однозначней.

отдельно прикольно будет операторам, сдуру поапгрейдившимся на это ненужно, объяснять клиентам, что "самавиновата" и "проблема на той стороне" (с которой и не связаться никак - dns-то не работает)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +2 +/
Сообщение от Аноним (1), 16-Июл-19, 14:41 
Ну это всё же более прозрачное поведение, чем просто дропать пакеты, а отправляющей стороне рестрансмитить наугад.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  –2 +/
Сообщение от пох. (?), 16-Июл-19, 16:47 
так на поведение того конца никак повлиять и не удастся - там хз что древнее стоит, к чему может и подойти-то уже нельзя (иначе б давно и так работало). Дропало и будет дропать.

Отправляющая сторона в любом случае делает несколько повторных попыток (мало ли, почему мог потеряться пакет), просто раньше она последнюю делала с убранными лишними флагами.

то есть никакого технического смысла в этом улучшизме - нет. Соответственно, описание - явная попытка обмануть публику. Вот и спрашивается - а чего это они так активизировались, причем, в лучших традициях, не предоставив выбора пользователю (что, блжад, опять мешало воспользоваться условной компиляцией или добавить настройку?)

полагаю, ни для чего хорошего.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +/
Сообщение от PnDx (ok), 17-Июл-19, 12:55 
Внутри любого рекурсора прописан алгоритм, так или иначе балансирующий между потреблением ресурсов и вероятностью получить таки ответ. Например, в unbound в коде даже не поленились оставить ссылку на соотв. страницу из Кнута (все бы так делали).
В хидерах, соответственно (если писала не совсем бестолочь, что не факт для pdns. Лазал как-то в код их интерфейса к ldap), несколько констант для подкрутки.
Почему их не вытаскивают в конфиг? Видимо, считают своё видение мира единственно верным. Пришлось самому покрутить для лагающих каналов (которые иногда — данность).
Альтернативно можно продолжать использовать bind9 с кучей алгоритмических подпорок. Но там столько вариантов cache poisoning, что я например умаялся его поддерживать. Дешевле получилось открутить дурной hardening из unbound и исправить ляп в коде с "перевёрнутым" insecure.

* Что до резолвера pdns, я пока не вижу его нишу. Для common case есть unbound. Для модно-микросервисного есть knot resolver. А этот куда?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +/
Сообщение от пох. (?), 17-Июл-19, 13:09 
> * Что до резолвера pdns, я пока не вижу его нишу.

ну если у тебя уже стоит их authoritative и ты заложился на его апи в ста местах - перелезать на knot может показаться грустно, а поставить еще и рекурсор от того же разработчика - вполне осмысленным ходом.

сам по себе этот рекурсор, понятно, мало кому нужен.

P.S. а bind9, думаю, в любом случае недолго осталось

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

7. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +1 +/
Сообщение от Ivan_83 (ok), 17-Июл-19, 01:45 
То самое чувство когда тебя насаживают на прогресс :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +1 +/
Сообщение от Kuromi (ok), 17-Июл-19, 05:54 
Тем не менее проведенный уже в 2019 DNS day заставил изрядное количество организаций наконец обновить софт. Так что все к лучшему.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +/
Сообщение от www2 (??), 19-Июл-19, 21:26 
Не всегда обновление "софта" - к лучшему.

В случае сетевых программ это ещё может иметь смысл, т.к. старые версии программ перестают поддерживаться, в них обнаруживаются уязвимости, которые не будут исправлены никогда. Т.к. любой компьютер в сети может представлять опасность для других компьютеров, то использование старых версий программ уже не является только личным делом владельца компьютера.

В остальных случаях бывает так, что новые версии программ зачастую не содержат ничего критически нужного, но ресурсов потребляют больше. А бывает, что перестаёт работать то, что уже работало и нужно ещё и денег за новую версию куда-нибудь занести.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020"  +/
Сообщение от Kuromi (ok), 19-Июл-19, 22:31 
> Не всегда обновление "софта" - к лучшему.
> В случае сетевых программ это ещё может иметь смысл, т.к. старые версии
> программ перестают поддерживаться, в них обнаруживаются уязвимости, которые не будут исправлены
> никогда. Т.к. любой компьютер в сети может представлять опасность для других
> компьютеров, то использование старых версий программ уже не является только личным
> делом владельца компьютера.
> В остальных случаях бывает так, что новые версии программ зачастую не содержат
> ничего критически нужного, но ресурсов потребляют больше. А бывает, что перестаёт
> работать то, что уже работало и нужно ещё и денег за
> новую версию куда-нибудь занести.

Ну, самое хорошее что акция заставила обновить софт многие российские банки. А вы сами представляете себе что таоке банк и как быстро они там реагируют.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру