Описание
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.
A flaw was found in the OpenStack Designate mDNS NOTIFY handler. The _handle_notify method performs zone lookups without pool_id scoping, unlike the QUERY and AXFR handlers which were previously updated to be pool-aware. When zones with the same name exist across different DNS pools, the storage layer finds multiple matches and raises a NotFound exception, causing all NOTIFY processing for the affected zone name to fail. This results in denial of service for DNS zone transfer notifications, causing stale zone data on secondary DNS servers. The mDNS NOTIFY path is reachable via unauthenticated UDP on port 5354.
Отчет
Red Hat OpenStack Platform (RHOSP) ships Designate across multiple versions. The mDNS NOTIFY handler DoS can occur whenever zone names collide across pools, regardless of how the colliding zones were created. However, in default configurations, only a single pool is used, making collisions unlikely without administrator action or exploitation of CVE-2026-71193. Multipool deployments using the AttributeFilter scheduler were never a fully supported configuration in any RHOSP version. In RHOSP 13, 16.2, and 17.1 (TripleO deployment), the mDNS service listens on port 5354/UDP by default and does not require authentication for the NOTIFY handler path. For Red Hat OpenStack Services on OpenShift (RHOSO, openstack-18.0), the mDNS service defaults to a ClusterIP service type with no NodePort or LoadBalancer exposure, making port 5354 reachable only within the OpenShift cluster network. This significantly limits the attack surface for the mDNS DoS.
Меры по смягчению последствий
Restrict network access to the mDNS service port (default 5354/UDP and TCP) using firewall rules, allowing only traffic from known DNS master servers. Note that enabling the 'query_enforce_tsig' option does NOT protect the NOTIFY handler path, as it only applies to QUERY and AXFR operations. To prevent the precondition of colliding zones: verify that the 'scheduler_filters' configuration option in the [service:central] section uses 'default_pool' (the default) or 'pool_id_attribute' instead of 'attribute'. This prevents unauthorized creation of zones in alternative pools.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat OpenStack Platform 13 (Queens) | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 17.1 | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 18.0 | openstack-designate | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
4.3 Medium
CVSS3
Связанные уязвимости
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-b ...
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.
EPSS
4.3 Medium
CVSS3