Why would I want to use DNSaaS (Designate) over a traditional bind/nsupdate setup?

asked 2014-01-03 12:40:11 -0600

wgjohnson gravatar image

updated 2014-01-03 12:56:13 -0600

I'm looking into setting up a DNS zone for use with OpenStack.

I'm not sure what benefits I would get from working with DNSaaS (Designate/pdns) over using bind and nsupdate.

At the expense of saying "we've always done it that way", I think it makes sense for me to work with the older DNS stack, because that's what me and my peers are more familiar with. Please convince me to take the red pill.

edit retag flag offensive close merge delete



In addition to jmcbride's answer, I found this video describing Designate/Moniker, and specifically asking "why would I use DNSaaS?" - http://www.openstack.org/summit/portland-2013/session-videos/presentation/dns-in-the-cloud-the-moniker-openstack-inspired-dns-project%3C/p%3E (http://www.openstack.org/summit/portland-2013/session-videos/presentation/dns-in-the-cloud-the-moniker-openstack-inspired-dns-project)

wgjohnson gravatar imagewgjohnson ( 2014-01-03 17:28:59 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2014-01-03 15:43:57 -0600

jmcbride gravatar image

Having recently gone through this evaluation process, I can tell you the following factors lead to us adopting Designate:

  1. A clean ReST API for managing zones and records
  2. A command line interface
  3. With incubation (TBD), tighter integration with other Openstack projects (e.g. Nova, Swift) will follow. For example, each new server provisioned via Nova can have an "A record" created automatically. Language bindings for common languages (php, java, ruby, python) will also likely follow.
  4. Designate supports multiple authoritative name servers; there is even work underway to support multiple backends with a single deployment. An operator could feasibly run both BIND and PowerDNS at the same time for different zones if they chose to. This is useful if you have a large number of zones to manage as well or if you want to prevent "lock-in" to a specific name server.
  5. Multi-tenancy allows you to host multiple projects/organizations and keep those organizations' resources secure.
  6. Designate administrators can limit the number of zones & records a tenant can provision
  7. A Debian package and Chef recipes are available for managing deployments
  8. The Designate community is growing and healthy:
    • HP (project founder), eNovance and Rackspace joined this year. Other yet to be named companies are ramping up their developers.
    • There have been 33 commits to master since November.
    • A Designate "mini summit" is planned in January
edit flag offensive delete link more


3. Do you know if this built-in currently? This is definitely one of the reasons I was drawn to it, but I can't tell if this is available in Grizzly.

wgjohnson gravatar imagewgjohnson ( 2014-01-03 16:52:57 -0600 )edit

4., 5. I now realize I had been short-sighted, as my tenants are part of one larger non-openstack project, so segmentation wasn't as important to me.

wgjohnson gravatar imagewgjohnson ( 2014-01-03 16:53:00 -0600 )edit

8. It sounds like it's not all there yet. I'm on Grizzly, with plans to re-evaluate later this year for Havana/Icehouse, and I'm looking for what I can do _right now_. Thanks for sharing all of that, it was very helpful!

wgjohnson gravatar imagewgjohnson ( 2014-01-03 16:54:40 -0600 )edit

A framework for 3 is in place - we have a demo sink service, that takes events from nova, and can action them. If you wanted to use it, you would just have to extend this service to ensure the FQDN is what you wanted.

grahamhayes gravatar imagegrahamhayes ( 2014-02-11 06:56:10 -0600 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools


Asked: 2014-01-03 12:40:11 -0600

Seen: 1,660 times

Last updated: Jan 03 '14