... | ... | @@ -6,7 +6,7 @@ DHCP-driven DNS Updates (name changes) will be carried out by a new module. For |
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
## kea-dhcp-ddns Components [=#point1]
|
|
|
## kea-dhcp-ddns Components
|
|
|
|
|
|
The following diagram depicts the server and its components:
|
|
|
|
... | ... | @@ -31,7 +31,7 @@ DHCP-driven DNS Updates (name changes) will be carried out by a new module. For |
|
|
8. isc::asiolink - Kea library which provides IP socket IO.
|
|
|
|
|
|
|
|
|
## kea-dhcp-ddns Classes [=#point2]
|
|
|
## kea-dhcp-ddns Classes
|
|
|
|
|
|
The following diagram shows the classes which make up the components of the server:
|
|
|
|
... | ... | @@ -70,9 +70,9 @@ The exact JSON layout is left as an implementation detail. It will be important |
|
|
|
|
|
!NameChangeTransaction is an abstract, state-driven class for conducting a single name change. Each transaction may conduct multiple DNS Update request-response exchanges with DNS Servers to effect the name change. Transactions will use a !DnsClient instance to carry out these exchanges. !DnsClient provide a wrapper around the existing isc::asiolink library to perform the required socket IO. The initial implementation will support UDP only. Each transaction instance use the DNS exchange events to move it forward through its state-model.
|
|
|
|
|
|
!NameAddTransaction is the derivation for adding (or updating) a mapping to DNS, while !NameRemoveTransaction is the derivation for removing a mapping from DNS. Which class is used for a given request is determined by the request's type, "add" or "remove". Note also that a given request is either a single IPv4 mapping or single IPv6 mapping. As such, when text below refers to an "address record" or "address RR" it implies an "A" record or "AAAA" record accordingly. The state model for an add is discussed [#point5 here] and the state model for removal is discussed [#point6 here].
|
|
|
!NameAddTransaction is the derivation for adding (or updating) a mapping to DNS, while !NameRemoveTransaction is the derivation for removing a mapping from DNS. Which class is used for a given request is determined by the request's type, "add" or "remove". Note also that a given request is either a single IPv4 mapping or single IPv6 mapping. As such, when text below refers to an "address record" or "address RR" it implies an "A" record or "AAAA" record accordingly. The state model for an add is discussed [here](#nameaddtransaction-state-model) and the state model for removal is discussed [here](#nameremovetransaction-state-model).
|
|
|
|
|
|
## DNS Update Request Initiation [=#point3]
|
|
|
## DNS Update Request Initiation
|
|
|
|
|
|
D2 is effectively a DDNS client which undertakes DNS updates on behalf of others, primarily the DHCP servers. This design places the burden of determining when a lease change warrants an update of DNS information on the DHCP servers. This decision was based on a number of factors:
|
|
|
|
... | ... | @@ -89,7 +89,7 @@ D2 is effectively a DDNS client which undertakes DNS updates on behalf of others |
|
|
While the initial decision making is upstream from D2 that is not say D2 will blindly attempt every request. It will be capable of processing some requests while discarding or delaying others. DNS servers might not be available or requests may be obsolete based on other pending requests. Stated more succinctly, the DHCP servers will include only as much of the decision process required to send respond back to the client, any other decision making will be left to D2.
|
|
|
|
|
|
|
|
|
## D2 Event Processing [=#point4]
|
|
|
## D2 Event Processing
|
|
|
|
|
|
D2 is essentially asynchronous in nature and its design must account for this. The following list summarizes the asynchronous events that must be handled:
|
|
|
|
... | ... | @@ -196,7 +196,7 @@ Again, to ensure we periodically sweep, an Interval timer will be used to genera |
|
|
The only real difference between the two event loops is in the type of transaction instantiated, and this could be readily addressed with configuration parameter value. The multi-threaded implementation will be treated as a possible future-enhancement.
|
|
|
|
|
|
|
|
|
## !NameAddTransaction State Model [=#point5]
|
|
|
## !NameAddTransaction State Model
|
|
|
|
|
|
!NameAddTransaction implements a state machine for adding (or updating) a DNS mapping. This state machine is based upon the processing logic described in RFC 4703, Sections 5.3 and 5.4. In short, it will first attempt to update the forward DNS mapping (if Forward Change Flag is true), and then the reverse DNS mapping (if Reverse Change Flag is true). The state diagram for !NameAddTransaction is shown below:
|
|
|
|
... | ... | @@ -265,7 +265,7 @@ Record success accordingly. Transitions to final state upon destruction. |
|
|
#### !ProcessAddFailed
|
|
|
Record failure accordingly. Depending on failure conditions, it is possible we may institute some form of retry. Transitions to final state upon destruction.
|
|
|
|
|
|
## !NameRemoveTransaction State Model [=#point6]
|
|
|
## !NameRemoveTransaction State Model
|
|
|
|
|
|
!NameRemoveTransaction implements a state machine for removing a DNS mapping. This state machine is based upon the processing logic described in RFC 4703, Sections 5.5. In short, it will first attempt to remove the forward DNS mapping (if Forward Change Flag is true), and then remove the reverse DNS mapping (if Reverse Change Flag is true). The state diagram for !NameRemoveTransaction is shown below:
|
|
|
|
... | ... | @@ -328,11 +328,11 @@ Record success accordingly. Transitions to final state upon destruction. |
|
|
#### !ProcessRemoveFailed
|
|
|
Record failure accordingly. Depending on failure conditions, it is possible we may institute some form of retry. Transitions to final state upon destruction.
|
|
|
|
|
|
## Miscellaneous [=#point7]
|
|
|
## Miscellaneous
|
|
|
|
|
|
1. DNS Server responses with an invalid TSIG key will be logged and discarded by !DnsClient when waiting for responses. It should continue to wait for a valid response until it reaches a prescribed timeout value. This is to guard against spoofed responses.
|
|
|
|
|
|
## Addendum: !PersistenceMgr Design [=#point8]
|
|
|
## Addendum: !PersistenceMgr Design
|
|
|
|
|
|
### Introduction
|
|
|
|
... | ... | |