... | ... | @@ -4,21 +4,13 @@ Note - this document could use markup work to make the TOC work. |
|
|
|
|
|
DHCP-driven DNS Updates (name changes) will be carried out by a new module. For ease of discussion (and typing) this module is code named "D2" (1 D for DHCP and another D for DDNS). It will be constructed as a Kea component. The document is structured as follows:
|
|
|
|
|
|
* [#point1 B10-D2 Components]
|
|
|
* [#point2 B10-D2 Classes]
|
|
|
* [#point3 DNS Update Request Initiation]
|
|
|
* [#point4 D2 Event Processing]
|
|
|
* [#point5 NameAddTransaction State Model]
|
|
|
* [#point6 NameRemoveTransaction State Model]
|
|
|
* [#point7 Miscellaneous]
|
|
|
* [#point8 Addendum: PersistenceMgr Design]
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
## B10-D2 Components [=#point1]
|
|
|
## kea-dhcp-ddns Components [=#point1]
|
|
|
|
|
|
The following diagram depicts the server and its components:
|
|
|
|
|
|
### B10-D2 Component Diagram
|
|
|
### kea-dhcp-ddns Component Diagram
|
|
|
|
|
|
![ddns_components.4.svg](/uploads/35049cef0cfaa1924e41213fb476bbc4/ddns_components.4.svg)
|
|
|
|
... | ... | @@ -30,26 +22,26 @@ DHCP-driven DNS Updates (name changes) will be carried out by a new module. For |
|
|
|
|
|
4. !PersistenceMgr - Provides persistent storage services to !QueueMgr for persisting the name change queue across restarts.
|
|
|
|
|
|
5. !CfgMgr - Responsible for interfacing with BIND10 configuration API; provides access to configuration information to the other components.
|
|
|
5. !CfgMgr - Responsible for interfacing with configuration API; provides access to configuration information to the other components.
|
|
|
|
|
|
6. NameChangeIPC - Subsystem which provides the ability to send and receive !NameChangeRequests via interprocess communication.
|
|
|
|
|
|
7. RDBMS - Subsystem which provides persistent storage of data. This may be MySQL, Memfile, or potentially some other RDBMS.
|
|
|
|
|
|
8. isc::asiolink - Bind10 library which provides IP socket IO.
|
|
|
8. isc::asiolink - Kea library which provides IP socket IO.
|
|
|
|
|
|
|
|
|
## B10-D2 Classes [=#point2]
|
|
|
## kea-dhcp-ddns Classes [=#point2]
|
|
|
|
|
|
The following diagram shows the classes which make up the components of the server:
|
|
|
|
|
|
### B10-D2 Class Diagram
|
|
|
### kea-dhcp-ddns Class Diagram
|
|
|
|
|
|
![overview_classes.5.svg](/uploads/61eec6635dcd6244e02b498b929ea817/overview_classes.5.svg)
|
|
|
|
|
|
D2Process is a singleton which provides startup and shutdown services and parenting all of the sub-component objects. D2Controller a wrapper class for D2Process that allows the process to function as a B10 component. This is pattern is similar to the approach used in B10-Dhcp4 and B10-Dhcp6 servers.
|
|
|
D2Process is a singleton which provides startup and shutdown services and parenting all of the sub-component objects. D2Controller a wrapper class for D2Process that allows the process to function as a Kea component. This is pattern is similar to the approach used in `kea-dhcp4` and `kea-dhcp6` servers.
|
|
|
|
|
|
D2CfgMgr is a singleton which provides support for the BIND10 configuration API and services for accessing configuration information. It will provide one or more services for matching DNS servers to name changes based on as a various criteria such as:
|
|
|
D2CfgMgr is a singleton which provides support for the Kea configuration API and services for accessing configuration information. It will provide one or more services for matching DNS servers to name changes based on as a various criteria such as:
|
|
|
1. Match by zone
|
|
|
2. Match by explicit list
|
|
|
3. Custom Matching "hook"?
|
... | ... | @@ -108,7 +100,7 @@ D2 is essentially asynchronous in nature and its design must account for this. T |
|
|
|
|
|
2. DNS message exchange events from DNS update exchanges with DNS servers. Each transaction may require multiple sends and receives. Each send and receive outcome amounts to an event. These events will be used to move each transaction through its state machine. At points in which the transaction must wait for IO, control should be yielded.
|
|
|
|
|
|
3. Control Events - Command (e.g. shutdown) and configuration events that emanate from BIND10.
|
|
|
3. Control Events - Command (e.g. shutdown) and configuration events that emanate from the API (typically Control Agent).
|
|
|
|
|
|
4. Completed Transactions - While not an event per se, D2 does need to monitor its list of transactions, for those that have completed.
|
|
|
|
... | ... | |