2026.1 Series Release Notes

22.0.1-18

Security Issues

  • Fixed a missing authorization check on the floating IP reverse DNS (PTR) API. PATCH /v2/reverse/floatingips/{region}:{floatingip_id}, used to set or unset a floating IP’s PTR record, previously performed no policy check at all. Any authenticated user in a project - including one holding only the read-only reader role - could create, update, or clear DNS records for that project’s floating IPs. The endpoint now enforces the same project-member (or admin) authorization required by other DNS record write operations.

  • Fixed a zone-ownership check missing from the internal lookup used to find or create the shared reverse-DNS zone for a floating IP’s PTR record. The lookup did not verify that a matching zone was actually owned by Designate’s managed-resource tenant, so a zone created by an unrelated project under a colliding name could be silently reused, causing another tenant’s PTR record to be written into it. The lookup is now scoped to the managed-resource tenant, and a name collision with another tenant’s zone now fails with a clear error instead of silently succeeding.

  • 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.

Bug Fixes

  • Fixed bug 1919495 where IPv6 addresses with compressed notation (using ::`) were incorrectly parsed in notification handlers. The notification handler now uses Python’s ipaddress module to properly normalize and expand IPv6 addresses before processing, ensuring correct handling of all valid IPv6 address formats including compressed notation, fully-specified addresses, and mixed formats.

  • Fixed bug 2095170 where designate-manage pool update --delete (and the delete_pool RPC call) would fail with InvalidOperation: pool must not contain zones when attempting to delete a pool that only contained its own catalog zone. Catalog zones are now excluded from that check, since they are deleted automatically along with the pool.

  • Fixed CAA record flags field validation to allow the full 8-bit octet range (0-255) as specified in RFC 6844. Previously, the flags field was incorrectly limited to values 0-1, preventing users from setting the critical flag (128) or any other valid flag values. [LP#1966982]

  • Fixed an issue where updating only the zone description would incorrectly increment the zone serial number. The serial number is now only incremented when DNS-propagated fields (such as email or TTL) are changed.

  • 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 without a working RPC listener, so only the parent process 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. Heartbeat emitters for these services now also start and stop inside each worker process, so their timer and messaging state are not active in the parent when workers are forked.

  • [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 zone deletion failure when BIND9 is configured with both authoritative and recursive roles. Previously, zone deletion could fail because get_serial() incorrectly interpreted non-authoritative recursive responses as evidence that the zone still existed locally.

  • 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.

22.0.1

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.

  • 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 a bug that didn’t allow zones to be moved from non-default pools to default pools.

Other Notes

  • [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.

22.0.0

Upgrade Notes

  • The designate-api service has been migrated from eventlet to use native Python threading.

    The default number of API threads has been reduced from 1000 to 100 to reflect the change from eventlet greenthreads to native OS threads.

  • Operators should migrate to deploying the Designate API using a WSGI server such as uwsgi or mod_wsgi. This has been the recommended deployment method and is the default in DevStack. The designate-api command will continue to work until the planned removal, but operators are encouraged to migrate to uwsgi deployment as soon as possible.

    See the DevStack configuration at devstack/lib/designate and devstack/files/wsgi/designate-api-wsgi for an example of uwsgi deployment.

  • Complete removal of eventlet from Designate. All services now use native Python threading via oslo.service’s threading backend.

  • Updated oslo.service dependency to >=4.2.0 with the [threading] extra, which is required for the threading backend support.

  • Default thread counts have been adjusted to reduce potential memory issues with Python native threads compared to eventlet greenthreads.

  • The NSD4 backend has been migrated from eventlet to native Python socket/ssl libraries. SSL certificate verification is now configurable and enabled by default.

    New configuration options:

    • verify_ssl: Enable/disable SSL certificate verification (default: true)

    • check_hostname: Enable/disable hostname checking (default: true)

    • ca_certs: Path to CA certificate bundle (default: system CA bundle)

    Breaking Change: Deployments using self-signed certificates must explicitly disable verification or add certificates to the system trust store.

    Configure these options in your pools.yaml file under the NSD4 target’s options section, then run designate-manage pool update. To maintain previous insecure behavior:

    targets:
  - type: nsd4
    options:
      host: 192.0.2.2
      port: 8952
      verify_ssl: false
      check_hostname: false

    Deployments with properly signed certificates require no configuration changes.

  • The designate-central service has been migrated from eventlet to native Python threading.

    Configuration Changes:

    • The default value for [service:central] threads has been reduced from 1000 to 100 to better align with native OS thread resource usage.

    Notable Changes:

    • Blacklist regex timeout mechanism updated to be compatible with native threading.

Deprecation Notes

  • The designate-api service and the designate.api.service module are deprecated and will be removed in a future release. The WSGIService class relies on oslo_service.wsgi and oslo_service.sslutils, which will be removed in oslo.service 2026.2 as part of the eventlet removal effort.

Security Issues

  • The NSD4 backend now defaults to secure SSL certificate verification. Previously, certificate verification and hostname checking were unconditionally disabled.