Adventures of a Small Time OpenStack Sysadmin Chapter 015 - OpenStack Designate DNS Service

Adventures of a Small Time OpenStack Sysadmin relate the experience of converting a small VMware cluster into two small OpenStack clusters, and the adventures and friends I made along the way.

Adventures of a Small Time OpenStack Sysadmin Chapter 015 - OpenStack Designate DNS Service

My strategy in setting up Designate before setting up storage or compute services was to get something VERY simple working with the complete system from database to web UI.  Then, if I have any problems with something complicated like volume storage, I can rule out system-wide issues such as mysql not working or whatever "infrastructure-level" problems.  This strategy worked very well.

https://docs.openstack.org/designate/yoga/install/

https://docs.openstack.org/designate/yoga/install/install-ubuntu.html

The installation was almost flawless.  I had to restart the designate-api and designate-central one extra time before updating my DNS pools, not mentioned in the docs.  Odd, but not a big deal.

There was a minor problem discovered later on, where I manage Docker hosts remotely using Portainer, which has a default port number of 9001.  Which, on an OpenStack cluster, is the default port number of the Designate API.  So I reconfigured Portainer and its agent to connect only to the OpenStack hosts on port 19001 instead of 9001 and that worked great.

The good news about Kolla-Ansible is it puts the APIs on the virtual IP address so port 9001 should be open on the bare metal.  The bad news is Kolla-Ansible is not entirely compatible with bare metal Docker especially after installing Zun and friends.  See Plan 3.0 for how I host bare metal Docker hosts requiring hardware access / pass-thru.

Samba Internal DNS Resolver is not very smart, and unfortunately being an AD domain, all my hosts point to it for DNS resolution.  All the Internal Resolver can do is respond back with any configured A or PTR record if the request is in its domain, OR pass the request to its configured forwarders if its not in a configured domain.  Which, superficially, sounds like a good start to a DNS server, but as always the devil is in the details.  I set up my Designate to configure it's zones on my bind9 resolver "forwarders" which are downstream of my Samba Internal DNS Resolver.  Yes I know, not ideal DNS architecture to merge authoritative and resolution DNS on the same system but if you're careful, it'll work very well.  Anyway, my plan was to delegate NS records in Samba Active Directory such that subdomains of the domain set up in AD would be forwarded to the resolvers, which are also the Designate authoritative servers.  If the Samba Internal DNS resolver were as smart as a Bind DNS server, it would indeed work using that configuration.  But ... it is not, so it does not work, you can put a protocol analyzer on the network then feel unhappy, or just trust me, it does not work.  You can configure NS records in the AD side of Samba, but the built in Internal DNS resolver in Samba simply ignores those NS records.  Later on, sometime around Plan 2.0, I implemented the very common alternative of simply using multiple domains, cedar.mulhollon.com remained my Samba domain, and openstack.mulhollon.net became my OpenStack Designate domain, but that's a story for a much later blogpost.

Somehow the docs completely skip installation of the CLI client for Designate.  On Ubuntu installation of the client is a one liner:

# apt-get install python3-designateclient

https://docs.openstack.org/neutron/yoga/admin/config-dns-int.html

Integrating Designate with Neutron.

Although it makes sense and is obvious in retrospect, this link has a table describing which Neutron components support which Designate attribute, and it boils down to the only component pairs that can't be linked are dns_name and a network, which makes a certain amount of sense.  I was kind of hoping that if you link a hostname to a network that would hypothetically be a sensible way for a sysadmin to define a wildcard A record for a domain, but that's not how its done.

Note that I discovered later on, in my HEAT orchestration experiments around Plan 2.0 timeframe, that if you design a HEAT template with DNS attributes and try to apply it to a Neutron resource that does NOT have Designate installed and configured, the HEAT template will fail.  So that's kind of annoying.  I had hoped and expected that Neutron would support entering the unused data in the database and later on after configuring Designate it would process the backlog or at least start to work on new configurations, but that is not the case, unfortunately.  So if you're EVER going to use Designate in the future, you should probably set it up and integrate it with Neutron very early in your overall cluster installation process.

Another thing that does not work until AFTER Designate is integrated with Neutron is integrating Designate with your external dns service.

Its kind of buried in the fine print, but remember you need to restart neutron-server after integrating with Designate.  You don't have to power cycle and reboot everything, remember this is not Windows, just restart neutron-server service and it's all good.

https://docs.openstack.org/neutron/yoga/admin/config-dns-int-ext-serv.html

This link is probably the most important link on the page, you have to read and wrap your mind around all the use-cases in order to successfully use Designate with Neutron.

This link explains some interesting behavior you will probably run into which might otherwise be confusing.  For example, if you consider a Use-Case-1 situation, if you try to configure a Neutron Port with a dns_name that does not match a Nova Instance hostname, you will probably become frustrated.  AFAIK if you want to IPv4 IPv6 dual stack and only NAT the IPv4 then Use-Case-3a is your only practically viable option.  Of course my OpenStack experience as end-user and later as an admin cover quite a span of time, so its possible times have changed and I should probably closely re-read this link.

On the other hand if you're just doing "typical normal stuff" then Designate does reliably do pretty much exactly what you'd expect it to do, which is awesome.  It is nice to have this link to read when you're trying to implement something well off the beaten path.

https://opendev.org/openstack/designate-dashboard

There is no documentation about the Designate Horizon web UI plugin, however it was pretty easy to figure out what to do on the OpenStack Controller:

apt-get install python3-designate-dashboard

systemctl reload apache2.service

My overall experience with Designate is it's pretty cool and easy to use and reliable.  I have always been disappointed that virtualization services like VMware do not have a boxed, prepackaged DNS solution similar to Designate.  VMware does have a half dozen different orchestration and automation solutions and most of them could be manipulated into a custom solution to automatically set up DNS, of course.

My project notes are grouped by service.  Because of that, setting up designate-dashboard and linking with Neutron above is out of order; we install Horizon tomorrow and Neutron four days later.  There are some circular loops when setting up an OpenStack cluster, at least if you set it up by hand like Plan 1.0.

Stay tuned for the next chapter!