maas-devel team mailing list archive

[Raphaël Badin <raphael.badin@xxxxxxxxxxxxx>]

Hi List (and Rob),

= Context =

As part of the cobbler-removal work, we are currently working on adding 
DNS support inside MAAS.  At this stage, we are aiming at feature parity 
with Cobbler.  DNS support means that the MAAS server will be able to 
add MAAS specific zones and options into the system's BIND 
configuration. A client could use that DNS server to resolve (forward 
and reverse) hostnames and IPs corresponding to nodes managed by MAAS.

Each nodegroup (a nodegroup is a set of nodes on a network with its own 
DHCP server and its own celery-based worker) corresponds to a DNS zone. 
 In each nodegroup, when new IP addresses are assigned, the MAAS' 
worker parses the DHCP lease file and posts the lease information 
(IP<->hostname mapping) back to the central MAAS server.  The central 
server then writes zone files, updates BIND's configuration if 
necessary, and gets BIND to reload the changed zones.

= Forward zone files =

For forward zone files, there is no problem: each nodegroup corresponds 
to a zone file (the zone is named after the nodegroup name).  The 
central DNS server is authoritative for all of the nodegroup's zones.

= Reverse zone files =

The problem arises when writing reverse zone files for non-octet 
boundary subnets (i.e. subnets other than class A,B or C networks).  The 
problem is that BIND (DNS in general?) expects authority to be delegated 
at /8, /16 or /24 network boundaries, not at, say, a /20 boundary.

We could either:

a) regroup the subnets by only writing reverse config files 
corresponding to /8, /16 or /24 networks

b) use the RFC2317 trick (see http://www.indelible.org/ink/classless/ 
for an example). That would not buy us much because this would still 
mean that we would have to write additional reverse config files to 
delegate to the reverse zone files.

This choice is problematic because:
- the DNS server will be authoritative for more than what's strictly 
necessary.
- it breaks the nice correspondence: one nodegroup <-> (one forward 
zone, one reverse zone).  That correspondence gave us a pretty 
straightforward way to hook up DNS config file changes with modification 
made to the DHCP lease information.  Also, it allowed us to reload zone 
files selectively (i.e. only when that zone and that zone only is modified).

= Possible solutions =

1. We could implement either a) or b) but the code will be more complex 
as we would need to add an additional step to regroup non-octet boundary 
subnets into octet boundary subnets.

2. We could write the reverse configuration as one big file but that 
would mean that all the subnets managed should be within the range of a 
giant subnet for which MAAS should be authoritative for.

3. Another solution, much more simple (and that we've got already 
working), would be to force the DHCP configuration of the nodegroups to 
only allow /8, /16 or /24 networks.  That way, each nodegroup would 
correspond to one forward zone and one reverse zone.

I must say that, I'm very much in favour of solution 3 but, the matter 
being rather complex, I'm keen on hearing comments on the solution I 
suggest or alternate solutions that you think should be considered.