🌐 Managing Designate DNS-as-a-Service in OpenStack

Designate is OpenStack’s DNS-as-a-service — it lets tenants manage zones and records through the API, and it pushes those changes out to real DNS servers like BIND9 or PowerDNS. It’s deceptively simple until a zone gets stuck in PENDING and you realize Designate has its own database, its own idea of what the backend should contain, and a worker that reconciles the two over a protocol that’s easy to misconfigure. After years of running it, I’ve found Designate problems are almost always in the pool config or the path between the worker and the backend. Here’s how to find them.

How Designate moves a record to a real DNS server

When a tenant creates a zone or record, the Designate API writes it to its own database and marks it PENDING. The designate-worker then talks to the configured pool of DNS servers, pushing the zone via AXFR/NOTIFY (for BIND-style backends) or a native API (for PowerDNS). The designate-mdns (mini-DNS) service answers AXFR requests so the real DNS servers can pull the zone. Once the backend confirms, the status flips to ACTIVE.

That means a stuck zone is almost always a break in this chain: worker can’t reach the backend, the backend can’t AXFR from mdns, or the pool config points at the wrong place. Knowing the chain makes it debuggable.

Step 1: Read zone status and the pool

Start with status:

openstack zone list -c id -c name -c status -c serial
openstack zone show <zone-name>
openstack recordset list <zone-name>

A zone stuck in PENDING means the worker hasn’t successfully pushed it. An ERROR status means a push failed outright. Compare the serial number — Designate increments it on every change, and the backend’s serial must catch up. If Designate’s serial is ahead of what the DNS server is actually serving, propagation is stalled.

Then inspect the pool, which is the config object tying Designate to actual nameservers:

openstack dns service status list
# pools are defined in pools.yaml and loaded with:
designate-manage pool show_config

Step 2: Confirm the worker can reach the backend

Most stuck zones are a connectivity or auth problem between designate-worker/designate-mdns and the DNS servers. For a BIND9 backend, the worker sends a NOTIFY and the BIND server AXFRs the zone from mdns. Verify both directions:

# Can the DNS server pull the zone from mdns?
dig @<mdns-ip> -p 5354 <zone-name> AXFR

# Is BIND configured to allow transfer from mdns and notify Designate?
journalctl -u designate-worker -f
journalctl -u designate-mdns -f

If the AXFR fails, your BIND allow-transfer/also-notify ACLs don’t include the mdns IP, or mdns isn’t listening on the port the pool config expects (5354 by default, not 53). This single mismatch — pool config says one port, mdns binds another — accounts for a huge share of “DNS won’t propagate” tickets.

Step 3: Pool manager and multiple backends

In production you run more than one nameserver, and the pool defines all of them. A common failure: you added a second BIND server to pools.yaml but never re-ran the loader, so the worker doesn’t know about it and zones go ACTIVE while one server silently lacks the records. After any pool change:

designate-manage pool update --file /etc/designate/pools.yaml

Then verify every nameserver in the pool actually serves the zone:

for ns in ns1 ns2; do dig @$ns.example.com <zone-name> SOA +short; done

All of them must return the same, current serial. A divergent serial means one backend fell out of sync — often because it was unreachable during a push and Designate marked the zone done anyway.

Step 4: Recovering a stuck zone

Don’t delete and recreate a PENDING zone — you’ll lose all its records. Force Designate to re-reconcile instead. The cleanest lever is to touch the zone so the worker re-pushes:

openstack zone set <zone-name> --email new-admin@example.com
openstack zone show <zone-name> -c status

Any update re-triggers the worker’s reconcile flow. If the zone is genuinely wedged in ERROR after the backend is fixed, the worker will retry on the next change. Watch designate-worker to confirm the push succeeds this time.

Step 5: Integrate with Neutron for automatic records

Designate’s real payoff is auto-registering instance DNS via Neutron. When enabled, creating a port or floating IP creates a matching A record. If those records aren’t appearing, the break is in the Neutron-Designate integration, not Designate itself — confirm dns_domain is set on the network and that Neutron’s [designate] section has working credentials. A missing dns_domain is the usual reason ports don’t get records.

Where AI helps

Designate spans its own services (api, worker, mdns, producer), the DNS backend (BIND/PowerDNS), and Neutron. The logs are scattered and the symptom — “DNS doesn’t resolve” — is maximally vague. I’ll paste the zone status, the worker/mdns log tails, and the dig AXFR result into a model and ask it to pinpoint where the chain broke: API, worker-to-backend, mdns AXFR, or pool config. It’s good at catching the port mismatch and the un-reloaded pool config that I’d otherwise spend an hour on.

Keep a saved Designate triage prompt, and pair it with our other OpenStack guides — especially the Neutron one, since half of Designate’s failures are really networking. The model reads the chain; you run the dig and designate-manage commands yourself.

Generated commands and configs are assistive, not authoritative. Always verify against your own deployment before running anything in production.