Designate Securing Communication

asked 2019-08-26 06:22:33 -0500

Hi.

we are planning to extend our current OpenStack set-up with Designate DNSaaS. More precisely, we plan to have two customer facing DNS servers (running bind9) that shall be fed by Designate. I have evaluated Designate for 10 days now, but currently I am unsure if it is mature/secure enough to be deployed in a public, production environment.

My current understanding is as follows:

  • Designate needs to communicate with the bind9 servers via rndc in order to create/delete zones. There is no way to avoid this.
  • Changes in the zones will be propagated to the customer facing DNS serves using the DNS protocol (DNS Notify messages). The customer facing DNS servers will then retrieve updates from Designate's mDNS using again the DNS protocol (DNS Zone Transfers). This requires that mDNS is accessible through a public IP address.

I think, I could live with this approach, but ideally, I'd prefer to keep mDNS behind a firewall or in a private network. The documentation on DNS Server Pools [1] claims that Designate allows deployments with Stealth Masters. I could not find any approach to make this possible; at least not with bind9 backends. Any suggestion how this can be achieved is much appreciated.

If there is no way to run a Stealth Master set-up, I was wondering if there is any way to make Designate/mDNS use tsig to sign its own messages? I found out that by creating a POOL-scoped tsigkey and setting query_enforce_tsig = true mDNS will only accept signed messages (hence, mDNS can reject any queries/requests from unknown sources). I could, however, not find a way to make mDNS use signatures for its own messages (except for rndc communication). I think this is desirable as the slaves (i.e. the bind9 servers) should be empowered to validate that notify messages are really sent by the master (or other slaves). Is there any hidden/undocumented configuration option to make mDNS change to this behaviour?

Thanks for any suggestions, answers and criticism.

Thanks.

On a side-note: are there any benefits using "also-notify" statements instead of adding nameservers as target? For bind9 I don't see how also-notify could work as this would not create any zones and hence any notify would fail.

[1] https://docs.openstack.org/designate/latest/admin/pools.html (https://docs.openstack.org/designate/...)

edit retag flag offensive close merge delete