When using "allowed_nets", egress-subnets for designate units should be added to allowed_nets in named.conf.options
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Designate-Bind Charm |
Fix Released
|
High
|
James Page |
Bug Description
It was identified recently that if the list of allowed_nets on designate-bind charm is too restrictive, the mdns updates from designate succeed in updating the zones on the bind servers, but the designate service cannot validate that the zone is now available on the bind servers, hence the zone creation goes into ERROR state.
Recreate:
deploy cloud with designate-bind with allowed_nets = 10.0.0.0/8, but cloud built on 192.168.0.0/24 network. (or vice versa) and you'll find designate-mdns.log will show something like:
2018-12-03 20:51:29.064 1739089 INFO designate.
2018-12-03 20:51:29.067 1739089 INFO designate.
You'll also find that you can't "nslookup -q=soa <zone> <dns-backend-ip>" on the units, you'll get a REFUSED.
If you then set allowed_nets = '', then dns zone updates work, and designate can fulfill zone requests properly end-to-end.
I suggest that allowed_nets, if being set, needs to auto-include the dns-backend binding/space network, such that the allowed_nets only needs to be maintained for corporate/vm users, and not for the internal designate service itself.
Changed in charm-designate-bind: | |
status: | New → Triaged |
importance: | Undecided → High |
summary: |
- When using "allowed_nets", dns-backend binding network should be added - to allowed_nets in named.conf.options + When using "allowed_nets", egress-subnets for designate units should be + added to allowed_nets in named.conf.options |
Changed in charm-designate-bind: | |
status: | Fix Committed → Fix Released |
This also becomes a problem if you set allowed_ recursion_ nets with allowed_nets blank and without including the dns-backend space network in the allowed_ recursion_ nets.