When using "allowed_nets", egress-subnets for designate units should be added to allowed_nets in named.conf.options

[Drew Freiberger]

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.mdns.notify [req-1a3e764e-d5b9-4268-87ca-529aff503661 - - - - -] Sending 'NOTIFY' for 'myzone.local.' to '<dns-backend-bind1-ip>:53'.
2018-12-03 20:51:29.067 1739089 INFO designate.mdns.notify [req-1a3e764e-d5b9-4268-87ca-529aff503661 - - - - -] myzone.local. not found on <dns-backend-bind1-ip>:53

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.

[Drew Freiberger (afreiberger)]

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.

[Drew Freiberger (afreiberger)]

Actually, it seems a bad practice to set the dns-backend network into allowed_recursion_nets, as it helps exhibit this bug: https://bugs.launchpad.net/charm-designate/+bug/1807464

[Peter Sabaini (peter-sabaini)]

Subscribing field-high as this is a recurring issue in the field

[Ryan Beisner (1chb1n)]

Please correct me if I am misunderstanding, but this is entirely workable with specific set of charm config to match the deployment topology, and the ask is basically an improvement request -- to make it easier/more automatic or less error-prone.

[James Page (james-page)]

I raised a review to include the CIDR for the dns-backend binding but that's not actually correct - allowed nets needs to include the IP addresses of the designate servers - there is no guarantee that they will be in the same CIDR as the local unit binding to whatever space is configured.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/742092
Committed: https://git.openstack.org/cgit/openstack/charm-designate-bind/commit/?id=57d034b7299375bba294dad194292cf5a3722dd6
Submitter: Zuul
Branch: master

commit 57d034b7299375bba294dad194292cf5a3722dd6
Author: James Page <email address hidden>
Date: Tue Jul 21 09:01:50 2020 +0100

    Allow access from remote designate units

    If allowed_nets is set ensure that the CIDR's for the remote
    units on the dns-backend relation are also included in the
    allow-query configuration stanza.

    This ensures that designate can validate that zone updates
    have been correctly transferred to all BIND servers.

    Closes-Bug: 1806485
    Depends-On: Icdb525c9886937597e35ab8126237a2850604832
    Change-Id: I02ebe63ad2775a00eb0f2d0a9ff2499319940833