Релиз DNS-сервера BIND 9.11, перешедший на новую лицензию05.10.2016 13:15

После двух с половиной лет разработки консорциум ISC представил первый стабильный релиз новой значительной ветки DNS-сервера BIND 9.11. Разработчики рекомендуют повременить с внедрением BIND 9.11 в промышленную эксплуатацию до первого корректирующего выпуска. Поддержка веток 9.9 и 9.10 сохраняется, например, обновления для BIND 9.9 будут выпускаться как минимум до конца 2017 года.

Ветка BIND 9.11 примечательна перелицензированием кодовой базы. Отныне код проекта распространяется под лицензией MPL 2.0 (Mozilla Public License), которая пришла на смену пермиссивной открытой лицензии ISC, созданной более 20 лет назад и являющейся аналогом 2-пунктовой лицензии BSD. Лицензия MPLv2 относится к категории слабого копилефта и требует открывать все внесённые в проект изменения, в то время как лицензия ISC предоставляла полную свободу по использованию кода в своих целях. При использовании MPL изменения требуется открывать только при поставке продукта, содержащего модифицированную версию кода. Для внутреннего использования изменения могут вноситься без их публикации. Лицензия MPL совместима с лицензиями GPLv2 и Apache, и выбрана проектом BIND как разумный компромисс между разрешительной лицензией ISC и жестким копилефтом GPL.

Ключевые новшества BIND 9.11.0:

  • Представлен каталог зон («Catalog Zones») — новый экспериментальный метод поддержания вторичных DNS-серверов. Суть метода в том, что вместо определения на вторичном сервере отдельных записей для каждой вторичной зоны, между первичным и вторичным серверами организуется передача каталога зон. Т.е. настроив трансфер каталога по аналогии с передачей отдельных зон, заводимые на первичном сервере зоны, помеченные как входящие в каталог, будут автоматически создаваться на вторичном сервере без необходимости правки файлов конфигурации (аналогично со вторичного сервера будут удаляться зоны, удалённые на первичном сервере). Сам по себе каталог зон оформляется в виде обычной зоны DNS, включающей список зон с настройками для каждой зоны, что позволяет применять штатные механизмы AXFR/IXFR для информирования другого сервера о наличии обновлений; 0_1475651694.png
  • Реализован интерфейс DynDB (Dynamic Database), позволяющий организовать загрузку зон из внешних баз данных. DynDB выступает в роли альтернативы технологии BIND DLZ (Dynamically-loaded zones), но работает значительно быстрее и поддерживает расширенные возможности. DynDB позволяет создавать модули, которые загружают данных из внешних источников и позволяют работать с ними с той же производительностью и теми же возможностями, как при использовании обычных зон. Например, новый интерфейс задействован в модуле bind-dyndb-ldap, который может применяться для хранения зон в LDAP;
  • Добавлен Dnstap, новый быстрый и гибкий метод для захвата и журналирования трафика DNS. Dnstap позволяет организовать ведение лога как поступающих запросов, так и генерируемых сервером ответов. В отличие от штатных средств ведения логов BIND, новый метод не влияет на производительность и пропускную способность сервера. Собранные данные могут записываться в файл или передаваться другому приложению через unix-сокет. Поддерживается автоматическая ротация файлов с логами. Для приведения логов к читаемому виду предлагается утилита dnstap-read;
  • Включена по умолчанию поддержка DNS Cookies (RFC 7873). Обмен cookie между сервером и клиентом позволяет идентифицировать корректность IP-адреса и защитить сервер и клиента от спуфинга IP-адресов. Управление производится директивами require-server-cookie и send-cookie, для совместного использования ключа для cookie на нескольких серверах можно использовать директиву cookie-secret;
  • Команда «rndc delzone» теперь может применяться к зонам, настройки которых заданы в файле named.conf, а не только к зонам добавленным через команду «rndc addzone» (при этом настройки автоматически не удаляются из named.conf, что требует ручного вмешательства, иначе настройки вернуться после перезапуска named);
  • Возможность сохранения конфигурации зон, добавленных командой «rndc addzone» не в текстом файле, а в БД lmdb (Lightning Memory-Mapped Database). При использовании БД lmdb значительно возростает производительность операций «rndc delzone» и «rndc modzone», так как изменение базы в формате ключ/значение производится значительное быстрее чем переписывание текстового файла;
  • Команда «rndc modzone» теперь может использоваться для перенастройки зон, используя синтаксис, похожий на команду «rndc addzone»;
  • В RNDC обеспечена возможность подключения обработчиков на языке Python. Функциональность реализована через модуль isc.rndc, позволяющий отправлять команды rndc из программ на языке Python;
  • Добавлена команда «rndc nta», позволяющая выставлять метки NTA (Negative Trust Anchors) для резолвера, отключающие проверку по DNSSEC для выбранных доменов. Подобная возможность может потребоваться для временного отключения DNSSEC для доменов, у которых возникли проблемы с настройками (например, просрочен сертификат). По умолчанию время действия метки — 1 час, максимальное время — 1 неделя;
  • Добавлена опция «minimal-any», при установке которой сервер генерирует ответ минимального размера на запросы ANY, которые при обычных условиях приводят к отправке большой порции данных и могут быть использованы для совершения атак. При установке опции «minimal-any» возвращается только одна произвольно выбранная запись RR, вместо вывода всех соответствующих запросу записей;
  • Добавлена новая утилита dnssec-keymgr (DNSSEC Key Manager), предоставляющая средства для автоматизации операций с ключами DNSSEC. Dnssec-keymgr может запускаться через cron и на основании заданных политик /etc/dnssec.policy создавать и обновлять ключи DNSSEC. При изменении политики ключи автоматически перестраиваются для соответствия новым правилам;
  • Добавлена новая утилита mdig, которая является вариантом утилиты dig, поддерживающим одновременную отправку нескольких запросов вместо отправки запросов один за другим;
  • В утилиту dig добавлена порция новых опций:
    • «dig +ednsopt» — выставляет произвольные опции EDNS для отправляемого запроса;
    • «dig +ednsflags» — выставляет определённые флаги EDNS для отправляемого запроса;
    • «dig +[no]ednsnegotiation» — включает/выключает согласование версий EDNS;
    • «dig +header-only» — отправляет запросы без вывода дополнительных секций;
    • «dig +ttlunits» — отображает значения TTL с суффиксами w, d, h, m, s для недель, дней, часов, минут и секунд;
    • «dig +zflag» — выставляет последний неназначенный битовый флаг в заголовке запроса DNS;
    • «dig +dscp=value» — устанавливает значение DSCP для исходящих пакетов;
    • «dig +mapped» — определяет использование маппинга адресов IPv4.

© OpenNet