wiki:April2013DhcpDdns

DHCP DNS

We are going through the requirements: DhcpDdnsRequirements. The first question is whether we should have separate modules for v4 and v6 updates. The consensus is no.

The next question is whether we want to merge v6 and v6 updates to come out together as a single update request. Stephen suggested that we should, Shawn pointed out that the problem will be with specifying prerequisites for the update, so the updates should be done separately. Stephen: optimizations is not that we should do at the first implementation.

Let's go over the DHCP4 that lost the ability to look up which zone to update. Shawn: it is ok to have a zone, especially to have TSIG keys. 4.1 code can walk through the DNSes starting from root to find out the right server to update.

This is a possible future requirement to do zone walking. At the short term, requirining people to specify the server address is ok.

Shawn: the spec is not really precise. It should be possible to specify the DNS server on a per domain name, not subnet base.

This should be one of the last features implemented.

Shawn: for completeness, the spec mentions that we need to have domain names and zones, we also new TSIG.

2.1.4 ("It SHOULD be possible to disable the use of a particular server without removing it from the database.") is not required in the first implementation.

Add 2.1.5 requiment: must be possible to specify a port.

Shawn: current doesn't have a queue as such.

Tomek: What happens in dhcp4, when there is a update chain in progress and someone shuts down the DHCP server? Shawn: server just dies. We record completed transactions in the lease file.

Shawn: DDNS will get name + address.

There are 3 cases we should cover: client sends fully qualified domain name, client sends hostname only, client sends empty option (which means a request to assign a hostname).

Stephen: there should be a way to have hooks that could override assigned option if needed.

Shawn: dhcp4 server will not generate the name by its own. You can generate it with miracles of Ted's language.

Fix the 2.2.2.5 - typo error.

2.2.2.5 and 2.2.1.10 should be updated to start generated name with "host" prefix.

It is not a string requirement for "the server MUST generate a partial name" to use IP address. It can be based on DUID or MAC (or something else).

2.3.1.2 - only DHCID is supported.

2.3 DNS paragraph - remove text about possible transition issues.

Who should make the decision to do the update or not? DHCP server needs the decision to send the response back to the DHCP client.

The consensus was to not make the decision just yet. Decision left open, pending more complete design.

Design review

the consensus is to make the decision whether to do the update or not is made on the DHCP server side. The primary reason: the dhcp-ddns communication can be one-way, rather than two way protocol communication.

The decision code will be implemented as a separate class just in case we want to move it to the DDNS module. This is only a relatively simple question: should we try to do the update or not? "Fire & forget" approach.

It is very likely that we'll use boost::interprocess routines for DHCP->DDNS module communication.

Marcin: we need to track lease expiration in the database.

We do not support lease expiration yet - we can't take any actions. This is required to for legal reasons and to trigger DDNS removal. We need nanny/housekeeper process.

This will work well with MySQL. What about SQLite or memfile? In these cases, two separate processes accessing the same database will give problems. (Table locking in the case of SQLite3, and the requirement for shared memory in the case of Memfile.)

Shawn: not to add update-optimization when we start.


Part 2 (Friday)

Marcin: let's get back to the topic of having 2 tables (one for leases and second for DDNS updates).

DHCP server will keep the FQDN information in the database. However, persistence of the DDNS queue is a priority 2 item: for the first implementation, it will be OK if the queue information is just held in memory.

Conflict detection (and reporting failures from DDNS back to DHCP is not interesting for now: we may reconsider when people will ask for it).

The class LeaseChange should be renamed NameChange

The state diagram is only concerned with updating a single name. There are several issues with it:

  • There are linked transactions within an update (e.g. try adding a name with pre-requisties, then unconditional addition etc.)
  • The server should not be changed within a transaction (if the first operation succeeds but the second fails).
  • There are multiple transactions (i.e. adding a name to the forwards zone, then a name to the reverse zone)

A "superstate" transition diagram is probably needed to address these.

Whiteboard photo from Friday's session:

Snapshot of white board from Dhcp-Ddns design review (Friday's session)

Last modified 5 years ago Last modified on Apr 25, 2013, 12:17:56 PM

Attachments (1)

Download all attachments as: .zip