DHCP-DDNS prelim design

[Stephen Morris]

On 12/04/13 08:38, Tomek Mrugalski wrote:
> On 12.04.2013 02:19, Thomas Markwalder wrote:
>> Ok, the design is on the Wiki:
>> 
>> http://bind10.isc.org/wiki/DhcpDdnsDesign

I'm posting this to the bind10-dhcp list so anyone following bind 10
DHCP development can also make observations.

One immediate comment: in the description on the wiki page, if you
prefix CamelCase names (i.e. all class names) with an exclamation
mark, you avoid creating hyperlinks.


> My comments: While we're focusing on servers for the foreseeable 
> future, the same module will eventually be used by DHCP client, 
> once we implement it in BIND10. There's a case where only the 
> client can do updates - mobile client visiting foreign network and 
> updating AAAA.
> 
> DdnsServerMgr - I think this modules should be named DdnsClient. 
> This piece of software is a DDNS protocol client, not server. It 
> talks to a server, but it is a client.

I think it needs to be refined further.  I see DdnsClient as being a
general DDNS client, able to dynamically update any server with any
resource record(s).  (This probably belongs in libdns++, although we
should consult with the BIND 10 DNS team about that.)

Above that is a layer that handles the logic to perform an update -
creation of the DHCID record, creation of the A/AAAA/PTR records, and
performing the set of queries. It will need to be asynchronous to
handle multiple updates to one or more servers at the same time.

> 
> I think UpdateMgr should interact with QueueMgr. Otherwise how 
> would it know what update do next?
> 
> Memfile and MySQL - I assume these are the backends we have now. 
> They'll be extended to hold extra info about DDNS stuff, right? I 
> was thinking that it doesn't make much sense to have different 
> backends just for DDNS (like b10-dhcp{4,6} uses MySQL, but 
> b10-dhcp-ddns uses memfile).  On the other hand, we allow
> different configuration for dhcp4 and dhcp6. What if dhcp4 uses
> MySQL and dhcp6 uses (to be implemented one day) Postgres? How will
> ddns module work with both?

I see two options for this:

a) Have a separate DDNS module for each server.  That would take care
of the need to handle multiple databases, and might even simplify some
of the code.  However, it would lose the possibility of optimising
some of the updates (such as sending A and AAAA updates in the same
packet).

b) Do we actually need a separate database for A and AAAA records?
The only reason it's there is that the configuration for b10-dhcp4 and
b10-dhcp6 is handled separately and we haven't yet put in any common
configuration options.

> Do we really need that persistence in DDNS?

I was seeing persistence as important.  In particular, in particular,
in handling expiration of leases.

At the moment, the DHCP servers do not keep track of expiration.  When
a lease expires, nothing happens.  When choosing an address, if the
server encounters a lease record it will reuse the address if the
lease has expired.

We could choose to have the names remain in DNS until the address is
reused.  However, I don't think this is an elegant solution and it
also doesn't handle the case that has come up in the past, where names
were left in DNS when the range of addresses handled by a DHCP server
was changed.

Having persistence in the DDNS module solves this.  If information
were stored about the name's lifetime (whether directly or as a
pointer to the lease information), the DDNS module could periodically
scan the data and remove the names associated with expired leases.

I also see persistence as being required in the case of a large number
of leases issued at the same time.  DDNS updates could be slow
depending on long the server takes to respond, I see there could be
cases when a backlog builds up.  If the system is shutdown or crashes
before the backlog is emptied, a number of updates could be lost.


> I'm thinking about the following scenario:

> 1. Server runs. A client gets an address and FQDN, so AAAA update 
> is needed. 2. Before AAAA update is started the server is
> shutdown. 3. Week passes. The client, its lease is long gone. 4.
> Server is started again. 5. Server starts old transactions it had
> in its queue.
> 
> We should consider an alternative approach a): - skip the update 
> queue - immediately start whatever lease update is requested
> 
> Alternative b): - skip the lease queue - keep the update queue,
> but do not keep it across restarts - when starting up, inspect 
> memfile/mysql backend to find out which leases require updates.

If the lifetime information is associated with the DDNS request, the
code can simply ignore requests to add or update information where the
expiration date has passed.


> This would simplify the design a lot. My limited understanding 
> suggests that alternative a) is what is happening in isc-dhcp4.
> 
> The extra bonus of approach a) would be that we can implement ddns
>  module very quickly - as a wrapper around nsupdate command line 
> tool. Sure, it will have pathetic performance, but we can have it 
> in a month. It would possibly be useful to shake out the 
> interaction between b10-dhcp{4,6}-b10 and b10-dhcp-ddns modules.

Implementing the update module as nsupdate - if we can do that quickly
- will allow testing of the overall package earlier and is a good
idea.  The finished product will need a proper DDNS component though.


> Your comment about hook for selecting DNS server is an excellent 
> point. Do we want hooks to cover DNS module? Selecting DDNS server 
> is just one thing. Another possible hook are: - proceed with update
> or drop it - modify the update before sending - select/override
> TSIG keys
> 
> The major question here is whether we want to have DDNS hooks in 
> the same library as DHCP hooks. If we want to make it as a single 
> hook library, the major problem here would be concurrency. This is 
> not a deal breaker, but it would complicate hooks library 
> implementation a lot.

Would it?  Although the code could be in the same library, the DHCP
and DDNS components will be running in separate processes.

However, the proposed design of the hooks mechanism is that the hooks
libraries are configurable.  Following this for DDNS would mean
separate configuration, and it would be up to the user if the
libraries were the same or different.



> Comment about State Diagram. I think it will be more complicated 
> than that. When doing PTR update, you need to find out what the 
> reverse zone to update. Dibbler went the easy way and just
> requires the sysadmin to specify zone length in its config file.
> isc-dhcp4 is smarter and it first send a query and finds out which
> zone the to-be-updated PTR record belongs to. After that it does
> the update.

I think we should go the Dibbler way here.


> I don't know - perhaps the state diagram can stay as it is now and 
> the case I mentioned will be modelled as two instances of state 
> diagram.
> 
> HaveSever => HaveServer

Also DdnsTransacation => DdnsTransaction


> Is the design prepared for DHCID? We don't want it implemented in 
> the first version, but the design should be ready for it (or at 
> least should be easily extensible to cover it).

We want DHCID in the final version but I agree with Tomek, for the
first iteration let's just worry about the A, AAAA and PTR records.


Stephen