2026.2 Series Release Notes

23.0.0.0rc1

New Features

  • TLSA recordset type has been added. All users can now create and manage TLSA records via the API and the OpenStack client. This enables DANE-based certificate validation directly through Designate.

  • The worker can now optionally sign NOTIFY and SOA poll messages with a TSIG key. In split-horizon deployments where the DNS server routes queries based on TSIG keys, this ensures that NOTIFY and serial polling reach the correct view regardless of the worker’s source IP.

    To enable, set tsigkey_id on pool nameservers and/or pool targets in pools.yaml, referencing a TSIG key created via the Designate API. When not set, the worker sends unsigned queries as before.

  • The zone import endpoint (POST /v2/zones/tasks/imports) now accepts application/json as a content type in addition to text/dns. When using JSON, the request body can include a zonefile field containing the zonefile content and an optional attributes field with zone attributes (e.g. pool_id). This allows imported zones to be scheduled to a specific pool, which was previously not possible. The existing text/dns behavior is unchanged.

Known Issues

  • Only standard TLSA parameters are supported (usage, selector, matching type, certificate data). Arbitrary extensions or non-standard formats are not currently supported.

Upgrade Notes

  • A new tsigkey_id column has been added to the pool_nameservers table. Run designate-manage database upgrade to apply the migration. The column is nullable and defaults to NULL, so no action is required for existing deployments.

  • A database migration adds STOPPED to the service_statuses enum.

  • Python 3.10 support has been dropped. The minimum version of Python now supported is Python 3.11.

Security Issues

  • Fixed a TXT and SPF recordset validation gap that allowed a value containing an unescaped literal newline character to be accepted and persisted, and NAPTR and CERT validation gaps that allowed a trailing newline in the NAPTR flags, service, or regexp fields, or in a numeric CERT cert_type or cert_algo field, through due to regular expressions anchored with a trailing $, which (without re.MULTILINE) matches immediately before a trailing newline rather than strictly at the end of the string. A CERT certificate field could separately carry a literal newline through unrejected, since base64 decoding ignores embedded newlines. In all cases the persisted value later failed to parse when designate-mdns rendered an AXFR response for the zone, which aborted the entire zone transfer to the backend nameserver. Because any project with recordset-create permission on a zone (including a project a PRIMARY zone has been shared with) could create such a value, this allowed one project’s malformed recordset to block publication of every other recordset in the same zone, including recordsets belonging to other projects.

    TXT and SPF record values, and CERT certificate values, are now rejected at validation time if they contain a literal newline character, and NAPTR’s flags, service, and regexp fields and CERT’s cert_type and cert_algo fields are now anchored with \Z so a trailing newline is correctly rejected. As defense in depth, designate-mdns now logs and skips any individual recordset that still fails to parse, both while rendering an AXFR response and while answering a direct record query, instead of aborting the whole zone transfer or leaving the query unanswered — including recordsets in system-generated catalog zones.

    See bug 2162105 for more information.

  • Added Post-Quantum Cryptography (PQC) readiness configuration. A new [pqc] configuration group provides check_mode (disabled/permissive/strict) to validate certificate algorithms used in backend TLS connections, and tls_minimum_version to enforce a minimum TLS protocol version for backends using direct TLS (NSD4). The NSD4 and PDNS4 backends now reject disabled TLS certificate verification when check_mode is set to strict. check_mode defaults to permissive, which only logs warnings for quantum-vulnerable certificates or disabled TLS verification and never blocks startup or rejects existing configuration; operators who want no certificate-check log output from [pqc] can set check_mode = disabled. This does not affect the unconditional HMAC-MD5 TSIG warning described below, which is independent of check_mode. See bug 2149793.

Bug Fixes

  • Zone export now validates the api_export_size quota synchronously before accepting the async export job. Previously, users would receive a 202 Accepted response, then discover the quota violation only after polling the export status, which showed an ERROR state. With this fix, users receive an immediate 413 Request Entity Too Large error when attempting to export a zone that exceeds the quota limit.

    This provides better user experience by giving immediate feedback and prevents wasted resources on doomed async jobs. The implementation uses the same quota validation pattern already employed by zone and recordset creation operations.

    See bug 1960495 for more information.

  • Services now report a STOPPED status on shutdown, fixing duplicate service_status entries when a service restarts on a different host (bug 1998906).

  • Added two periodic producer tasks: one to mark services as DOWN when their heartbeat exceeds a configurable threshold, and another to clean up STOPPED service entries. These tasks are auto-enabled by default when enabled_tasks is not explicitly configured. To exclude them, set enabled_tasks in the [producer] section of your configuration.

  • The periodic cleanup producer task now also deletes stale DOWN service entries whose last heartbeat exceeds a configurable time_threshold (default 7 days). This prevents indefinite accumulation of DOWN entries, particularly in container deployments with randomized hostnames. Set time_threshold to 0 in the [producer_task:periodic_cleanup_stopped_service_status] section to disable cleanup of DOWN entries.

  • Fixed the backend-multipool-bind9 devstack plugin to work with bind9 1:9.20.5-1 and later (Ubuntu 26.04+), where legacy configuration files (zones.rfc1918, named.conf.default-zones, and db.*) were removed in favor of BIND’s native empty-zones-enable directive. The plugin now guards these file copies with existence checks and also copies the new named.conf.root-hints file introduced as a replacement. See bug 2158627 for more information.

  • Fixed mDNS _handle_record_query to use TSIG-based pool scoping when looking up SOA and other record queries. Previously, when the same zone name existed in multiple pools (e.g. split-horizon DNS), the handler would find multiple matching recordsets and return REFUSED. The handler now resolves the zone first using the TSIG key’s pool_id, then looks up the recordset within that zone.

  • Fixed the backend-pdns4 devstack plugin to work with PowerDNS Authoritative Server 5.0+ (Ubuntu 26.04+), where the master and slave configuration settings were removed (deprecated since 4.5.0, removed in 4.9.0). The generated pdns.conf now uses the replacement primary and secondary settings.

  • Fixed bug 2166759 where moving a zone between pools (openstack zone move / the pool_move_zone API) did not bump the SOA serial of either the source or destination pool’s catalog zone, even though the zone’s membership in each pool’s catalog zone had changed. Secondary nameservers that had already transferred either catalog zone had no signal to re-transfer it after the move.

    Both catalog zone serial bumps are performed only after the zone’s pool move is fully committed, avoiding a race where the periodic increment-serial task could pick up the source pool’s catalog zone and NOTIFY secondaries of a new serial before the zone had actually left that pool.

  • Fixed designate-central, designate-worker, and designate-producer starting their RPC server before forking their worker processes. This left every worker process beyond the first without a working RPC listener, so only one process actually handled RPC traffic regardless of the configured workers count, and each worker hung for up to 60 seconds (then required a forceful kill) on shutdown while waiting on a listener that was never started.

  • [bug 1934120] Fixed an issue where TSIG keys could be created with mismatched scope and resource_id values. Previously, it was possible to create a TSIG key with scope='ZONE' but provide a pool UUID in resource_id, or vice versa. This could cause operational issues where TSIG authentication would fail with confusing “Zone not found” errors.

    TSIG key creation and updates now validate that the resource_id matches the specified scope type. If scope='ZONE', the resource_id must be a valid zone UUID. If scope='POOL', the resource_id must be a valid pool UUID. Invalid combinations are rejected with a clear error message at creation/update time.

  • Fixed bug 2166761 where removing a nameserver from a pool via designate-manage pool update (or the update_pool RPC call) would fail with RecordSetNotFound: Could not find RecordSet if the pool had a catalog zone configured. Catalog zones have no NS recordset, so they are now excluded from the nameserver create/delete loops in update_pool. SECONDARY zones have no NS recordset either, and hit the same crash; update_pool now tolerates that too.

  • Also fixed as part of bug 2166761: removing the last nameserver from a pool with a catalog zone configured raised an unhandled IndexError instead of the expected LastServerDeleteNotAllowed error. The check is now performed before the pool update is persisted.

  • Fixed a bug that didn’t allow zones to be moved from non-default pools to default pools.

  • Fixed bug 2166858 where restarting a service’s heartbeat shortly after stopping it could raise RuntimeError: A fixed interval looping call can only run one function at a time. HeartbeatEmitter.stop() now waits for the timer thread to fully exit before returning, instead of just signalling it to stop, matching the pattern oslo.service uses internally.

  • Fixed bug 2166758 where a zone’s (or a pool’s catalog zone’s) SOA MNAME (primary nameserver) was always chosen as whichever ns_records entry happened to be created first in the database, ignoring the priority value pools.yaml requires operators to assign to each nameserver. The entry with the lowest priority value is now used instead; ns_records sharing the same priority still break ties by their existing (creation) order, matching the previous behavior.

    That creation-order-based selection was not even reliably stable: designate-manage pool update deletes and recreates every ns_records entry for a pool on every run, regardless of whether anything actually changed, giving each entry a new created_at (and so a new position in that order) every time.

Other Notes

  • TLSA records follow RFC 6698. Clients and resolvers must support DANE to fully utilize these records. Ensure your DNS server software is updated to support TLSA queries and responses correctly.

  • Documentation has been added to clarify the behavior of designate-manage pool update command. The command uses merge semantics, updating only fields present in the YAML file while preserving existing database values for omitted fields. To clear optional fields such as also_notifies, attributes, or catalog_zone, administrators must explicitly set them to empty values (e.g., also_notifies: [], attributes: {}, or catalog_zone: null). This behavior is now documented in the pool management documentation and configuration file samples.

  • TSIG keys using HMAC-MD5 now always emit a warning (independent of the [pqc] check_mode setting) recommending migration to HMAC-SHA256 or stronger algorithms.

  • [bug 2008693] Added validation to require TSIG keys for zones in non-default pools. When backend nameservers request zone transfers from MDNS without TSIG authentication, MDNS defaults to searching only in the default pool, causing zones in other pools to fail with “ZoneNotFound” errors. The new validation prevents this by rejecting zone creation and pool moves to non-default pools when no TSIG key with scope=POOL exists for that pool. Documentation has been added explaining how to properly configure TSIG keys for multi-pool deployments.