Make designate-mdns (mini dns service) to be region-aware in handling NOTIFYs and AXFRs

Registered by Emmanuel Ankutse

Production DNS deployments are typically multi-regional/DC where name servers in a given data center serve a defined region.
We need to ensure that DNS name servers in a given region only perform AXFR's from designate-mdns instances in that reqion and also receive NOTIFY's only from designate-mdns instances in that region.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Emmanuel Ankutse
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Tim Simmons

Related branches

Sprints

Whiteboard

Each designate-mdns instance needs to know which name servers to send NOTIFY's to and which name servers to accept zone transfers requests (AXFR's) from.
We want to ensure that we don't have each designate-mdns instance sending NOTIFY's to and receiving AXFR's from every name server in the deployment.

One possible approach to implementing this:
Configure each designate-mdns instance with a region label/tag (maybe by way of config file that mini dns reads upon start up) and the designate-mdns instance announces/registers itself as being labeled by that tag much like a nova-compute registers itself on startup as being part of a region. We also, through the servers api, tag each pool or individual server entity in a pool appropriately as well (possibly an attribute on the server). Each designate-mdns instance then interacts only with these sever entities or pools that match its tag. Also, from the server entities or pools, a designate-mdns instance can retrieve enough information to determine which DNS name servers (hosts) to interact with - send NOTIFYs to and accept AXFR requests from.

Additionally, although rare events, we also need to account for the addition of new DNS name servers to pools or removal of existing DNS name servers or the addition and removal of entire pools of servers.

See related discussion in http://eavesdrop.openstack.org/meetings/designate/2014/designate.2014-05-21-17.00.log.html

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.