BIND 10 trac3035, updated. 42d8288e577b331401c4c785c8272a9a5a133c09 [3035] Remove outstanding NameChangeRequests from the queue when idle.
BIND 10 source code commits
bind10-changes at lists.isc.org
Tue Sep 10 06:28:15 UTC 2013
The branch, trac3035 has been updated
via 42d8288e577b331401c4c785c8272a9a5a133c09 (commit)
via ee550617afb58aa9ae58f1cee64fb75496d3cfba (commit)
via 44d1f2b6eda3eb818cfb0d15f618fbaf6d8a9bb7 (commit)
from 9dc963b3f128ec1ec68ac3b3e778b80718cef973 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 42d8288e577b331401c4c785c8272a9a5a133c09
Author: Marcin Siodelski <marcin at isc.org>
Date: Tue Sep 10 08:27:44 2013 +0200
[3035] Remove outstanding NameChangeRequests from the queue when idle.
commit ee550617afb58aa9ae58f1cee64fb75496d3cfba
Author: Marcin Siodelski <marcin at isc.org>
Date: Tue Sep 10 08:22:05 2013 +0200
[3035] Resolved doxygen errors caused by recent changes.
commit 44d1f2b6eda3eb818cfb0d15f618fbaf6d8a9bb7
Author: Marcin Siodelski <marcin at isc.org>
Date: Tue Sep 10 08:17:32 2013 +0200
[3035] Updated DHCPv4 Developer's Guide with respect to DNS updates.
Also, fixed a few typos in the DHCPv6 Developer's Guide.
-----------------------------------------------------------------------
Summary of changes:
doc/devel/mainpage.dox | 1 +
src/bin/dhcp4/dhcp4.dox | 73 ++++++++++++++++++++++++++++++++++++++++++-
src/bin/dhcp4/dhcp4_srv.cc | 12 +++++++
src/bin/dhcp4/dhcp4_srv.h | 14 ++++++++-
src/bin/dhcp6/dhcp6.dox | 12 +++----
src/bin/dhcp6/dhcp6_srv.cc | 4 +--
src/bin/dhcp6/dhcp6_srv.h | 2 +-
src/lib/dhcp_ddns/ncr_msg.h | 8 ++---
8 files changed, 111 insertions(+), 15 deletions(-)
-----------------------------------------------------------------------
diff --git a/doc/devel/mainpage.dox b/doc/devel/mainpage.dox
index 2b1ea8d..7101759 100644
--- a/doc/devel/mainpage.dox
+++ b/doc/devel/mainpage.dox
@@ -53,6 +53,7 @@
* - @subpage dhcpv4Session
* - @subpage dhcpv4ConfigParser
* - @subpage dhcpv4ConfigInherit
+ * - @subpage dhcpv4DDNSIntegration
* - @subpage dhcpv4Other
* - @subpage dhcp6
* - @subpage dhcpv6Session
diff --git a/src/bin/dhcp4/dhcp4.dox b/src/bin/dhcp4/dhcp4.dox
index bd490fb..930ac63 100644
--- a/src/bin/dhcp4/dhcp4.dox
+++ b/src/bin/dhcp4/dhcp4.dox
@@ -1,4 +1,4 @@
-// Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2012-2013 Internet Systems Consortium, Inc. ("ISC")
//
// Permission to use, copy, modify, and/or distribute this software for any
// purpose with or without fee is hereby granted, provided that the above
@@ -79,6 +79,77 @@ See \ref dhcpv6ConfigParser.
Configuration inheritance in DHCPv4 follows exactly the same logic as its DHCPv6
counterpart. See \ref dhcpv6ConfigInherit.
+ at section dhcpv4DDNSIntegration DHCPv4 Server Support for the Dynamic DNS Updates
+
+The DHCPv4 server supports processing of the DHCPv4 Client FQDN option (RFC4702)
+and the DHCPv4 Host Name option (RFC2132). Client may send one of these options
+to convey its fully qualified or partial name to the server. The server may use
+this name to perform DNS updates for the client. If server receives both options
+in the same message, the DHCPv4 Client FQDN %Option is processed and the Host
+Name option is ignored. If only Host Name Option is present in the client's
+message, it is used to update DNS.
+
+Server may be configured to use a different name to perform DNS update for the
+client. In this case the server will return one of the DHCPv4 Client FQDN or
+Host Name %Option in its response with the name which was selected for the
+client to indicate that this name will be used to perform DNS update.
+
+The b10-dhcp-ddns process is responsible for the actual communication with the
+DNS, i.e. to send DNS update messages. The b10-dhcp4 module is responsible for
+generating so called @ref isc::dhcp_ddns::NameChangeRequest and sending it to
+the b10-dhcp-ddns module. The @ref isc::dhcp_ddns::NameChangeRequest object
+represents changes to the DNS bindings, related to acquisition, renewal or
+release of the DHCP lease. The b10-dhcp4 module implements the simple FIFO queue
+of the NameChangeRequest objects. The module logic, which processes the incoming
+DHCPv4 Client FQDN and Host Name Options puts these requests into the FIFO queue.
+
+ at todo Currently the FIFO queue is not processed after the NameChangeRequests are
+generated and added to it. In the future implementation steps it is planned to
+create a code which will check if there are any outstanding requests in the queue
+and send them to the b10-dhcp-ddns module when server is idle waiting for DHCP
+messages.
+
+When client gets an address from the server, a DHCPv4 server may generate 0, 1
+or 2 NameChangeRequests during single message processing. Server generates no
+NameChangeRequests if it is not configured to update DNS or it rejects the DNS
+update for any other reason.
+
+Server may generate 1 NameChangeRequest in a case when client acquired a new
+lease or it releases an existing lease. In the former case, the NameChangeRequest
+type is CHG_ADD, which indicates that the b10-dhcp-ddns module should add a new
+DNS binding for the client, and it is assumed that there is no DNS binding for
+this client already. In the latter case, the NameChangeRequest type is CHG_REMOVE
+to indicate to the b10-dhcp-ddns module that an existing DNS binding should be
+removed from the DNS. The binding consists of the forward and reverse mapping.
+The server may only remove the mapping which it had added. Therefore, the lease
+database holds the information which updates (no update, reverse only update,
+forward only update or both reverse and forward update) have been performed when
+the lease was acquired or renewed. Server checks this information to make a
+decision which mapping it is supposed to remove when lease is released.
+
+Server may generate 2 NameChangeRequests in case a client is renewing a lease and
+it already has a DNS binding for that lease. The DHCPv4 server will check if
+there is an existing lease for the client which has sent a message and if DNS
+Updates had been performed for this lease. If the notion of client's FQDN changes,
+comparing to the information stored in the lease database, the DHCPv4 has to
+remove an existing binding from the DNS and then add a new binding according to
+the new FQDN information received from the client. If the client's FQDN
+information (including the client's name and type of update performed) doesn't
+change comparing to the NameChangeRequest is not generated.
+
+The DHCPv4 Client FQDN %Option comprises flags which communicate to the server
+what updates (if any) client expects the server to perform. Server may be
+configured to obey client's preference to do FQDN processing in a different way.
+If the server overrides client's preference it will communicate it by sending
+the DHCPv4 Client FQDN %Option in its responses to a client, with the appropriate
+flags set.
+
+ at todo Note, that current implementation doesn't allow configuration of the
+server's behaviour with respect to DNS Updates. This is planned for the future.
+The default behaviour is constituted by the set of constants defined in the
+(upper part of) dhcp4_srv.cc file. Once the configuration is implemented,
+these constants will be removed.
+
@section dhcpv4Other Other DHCPv4 topics
For hooks API support in DHCPv4, see @ref dhcpv4Hooks.
diff --git a/src/bin/dhcp4/dhcp4_srv.cc b/src/bin/dhcp4/dhcp4_srv.cc
index 3531bb0..7d23c3e 100644
--- a/src/bin/dhcp4/dhcp4_srv.cc
+++ b/src/bin/dhcp4/dhcp4_srv.cc
@@ -456,6 +456,9 @@ Dhcpv4Srv::run() {
LOG_ERROR(dhcp4_logger, DHCP4_PACKET_SEND_FAIL)
.arg(e.what());
}
+
+ // Send NameChangeRequests to the b10-dhcp_ddns module.
+ sendNameChangeRequests();
}
return (true);
@@ -965,6 +968,15 @@ queueNameChangeRequest(const isc::dhcp_ddns::NameChangeType chg_type,
name_change_reqs_.push(ncr);
}
+void
+Dhcpv4Srv::sendNameChangeRequests() {
+ while (!name_change_reqs_.empty()) {
+ // @todo Once next NameChangeRequest is picked from the queue
+ // we should send it to the b10-dhcp_ddns module. Currently we
+ // just drop it.
+ name_change_reqs_.pop();
+ }
+}
void
Dhcpv4Srv::assignLease(const Pkt4Ptr& question, Pkt4Ptr& answer) {
diff --git a/src/bin/dhcp4/dhcp4_srv.h b/src/bin/dhcp4/dhcp4_srv.h
index ea77b39..b878619 100644
--- a/src/bin/dhcp4/dhcp4_srv.h
+++ b/src/bin/dhcp4/dhcp4_srv.h
@@ -341,10 +341,22 @@ protected:
/// is exception free.
///
/// @param chg_type A type of the NameChangeRequest (ADD or REMOVE).
- /// @param ncr An isc::dhcp_ddns::NameChangeRequest object being added.
+ /// @param lease A lease for which the NameChangeRequest is created and
+ /// queued.
void queueNameChangeRequest(const isc::dhcp_ddns::NameChangeType chg_type,
const Lease4Ptr& lease);
+ /// @brief Sends all outstanding NameChangeRequests to b10-dhcp-ddns module.
+ ///
+ /// The purpose of this function is to pick all outstanding
+ /// NameChangeRequests from the FIFO queue and send them to b10-dhcp-ddns
+ /// module.
+ ///
+ /// @todo Currently this function simply removes all requests from the
+ /// queue but doesn't send them anywhere. In the future, the
+ /// NameChangeSender will be used to deliver requests to the other module.
+ void sendNameChangeRequests();
+
/// @brief Attempts to renew received addresses
///
/// Attempts to renew existing lease. This typically includes finding a lease that
diff --git a/src/bin/dhcp6/dhcp6.dox b/src/bin/dhcp6/dhcp6.dox
index 4cdea53..9281fbc 100644
--- a/src/bin/dhcp6/dhcp6.dox
+++ b/src/bin/dhcp6/dhcp6.dox
@@ -116,19 +116,19 @@ into the FIFO queue.
@todo Currently the FIFO queue is not processed after the NameChangeRequests are
generated and added to it. In the future implementation steps it is planned to create
a code which will check if there are any outstanding requests in the queue and
-send them to the bind10-dhcp-ddns module when server is idle waiting for DHCP messages.
+send them to the b10-dhcp-ddns module when server is idle waiting for DHCP messages.
In the simplest case, when client gets one address from the server, a DHCPv6 server
may generate 0, 1 or 2 NameChangeRequests during single message processing.
Server generates no NameChangeRequests if it is not configured to update DNS
or it rejects the DNS update for any other reason.
-Server may generate 1 NameChangeRequests in a situation when a client acquires a
+Server may generate 1 NameChangeRequest in a situation when a client acquires a
new lease or it releases an existing lease. In the former case, the NameChangeRequest
-type is CHG_ADD, which indicates that the bind10-dhcp-ddns module should add a new DNS
+type is CHG_ADD, which indicates that the b10-dhcp-ddns module should add a new DNS
binding for the client, and it is assumed that there is no DNS binding for this
client already. In the latter case, the NameChangeRequest type is CHG_REMOVE to
-indicate to the bind10-dhcp-ddns module that the existing DNS binding should be removed
+indicate to the b10-dhcp-ddns module that the existing DNS binding should be removed
from the DNS. The binding consists of the forward and reverse mapping.
A server may only remove the mapping which it had added. Therefore, the lease database
holds an information which updates (no update, reverse only update, forward only update,
@@ -140,7 +140,7 @@ Server may generate 2 NameChangeRequests in case the client is renewing a lease
it already has a DNS binding for that lease. Note, that renewal may be triggered
as a result of sending a RENEW message as well as the REQUEST message. In both cases
DHCPv6 server will check if there is an existing lease for the client which has sent
-a message, and if there is it will check in the lease database if the DNS Updates had
+a message, and it will check in the lease database if the DNS Updates had
been performed for this client. If the notion of client's FQDN changes comparing to
the information stored in the lease database, the DHCPv6 has to remove an existing
binding from the DNS and then add a new binding according to the new FQDN information
@@ -154,7 +154,7 @@ message being processed. That is 0, 1, 2 for the individual IA_NA. Generation of
the distinct NameChangeRequests for each IADDR is not supported yet.
The DHCPv6 Client FQDN Option comprises "NOS" flags which communicate to the
-server what updates (if any), client expects the server to perform. Server
+server what updates (if any) client expects the server to perform. Server
may be configured to obey client's preference or do FQDN processing in a
different way. If the server overrides client's preference it will communicate it
by sending the DHCPv6 Client FQDN Option in its responses to a client, with
diff --git a/src/bin/dhcp6/dhcp6_srv.cc b/src/bin/dhcp6/dhcp6_srv.cc
index 41e2cee..d32a514 100644
--- a/src/bin/dhcp6/dhcp6_srv.cc
+++ b/src/bin/dhcp6/dhcp6_srv.cc
@@ -458,7 +458,7 @@ bool Dhcpv6Srv::run() {
.arg(e.what());
}
- // Send NameChangeRequests to the b10-dhcp_ddns module.
+ // Send NameChangeRequests to the b10-dhcp-ddns module.
sendNameChangeRequests();
}
}
@@ -1138,7 +1138,7 @@ void
Dhcpv6Srv::sendNameChangeRequests() {
while (!name_change_reqs_.empty()) {
// @todo Once next NameChangeRequest is picked from the queue
- // we should send it to the bind10-dhcp_ddns module. Currently we
+ // we should send it to the b10-dhcp_ddns module. Currently we
// just drop it.
name_change_reqs_.pop();
}
diff --git a/src/bin/dhcp6/dhcp6_srv.h b/src/bin/dhcp6/dhcp6_srv.h
index f9e5dc5..55cdef1 100644
--- a/src/bin/dhcp6/dhcp6_srv.h
+++ b/src/bin/dhcp6/dhcp6_srv.h
@@ -378,7 +378,7 @@ protected:
/// @brief Sends all outstanding NameChangeRequests to bind10-d2 module.
///
/// The purpose of this function is to pick all outstanding
- /// NameChangeRequests from the FIFO queue and send them to bind10-dhcp-ddns
+ /// NameChangeRequests from the FIFO queue and send them to b10-dhcp-ddns
/// module.
///
/// @todo Currently this function simply removes all requests from the
diff --git a/src/lib/dhcp_ddns/ncr_msg.h b/src/lib/dhcp_ddns/ncr_msg.h
index a35d212..f27407f 100644
--- a/src/lib/dhcp_ddns/ncr_msg.h
+++ b/src/lib/dhcp_ddns/ncr_msg.h
@@ -91,8 +91,8 @@ public:
/// @brief Constructor, creates an instance of the @c D2Dhcid from the
/// HW address.
///
- /// @param A pointer to the object encapsulating HW address.
- /// @param A on-wire canonical representation of the FQDN.
+ /// @param hwaddr A pointer to the object encapsulating HW address.
+ /// @param wire_fqdn A on-wire canonical representation of the FQDN.
D2Dhcid(const isc::dhcp::HWAddrPtr& hwaddr,
const std::vector<uint8_t>& wire_fqdn);
@@ -147,8 +147,8 @@ public:
/// @brief Sets the DHCID value based on the HW address and FQDN.
///
- /// @param A pointer to the object encapsulating HW address.
- /// @param A on-wire canonical representation of the FQDN.
+ /// @param hwaddr A pointer to the object encapsulating HW address.
+ /// @param wire_fqdn A on-wire canonical representation of the FQDN.
void fromHWAddr(const isc::dhcp::HWAddrPtr& hwaddr,
const std::vector<uint8_t>& wire_fqdn);
More information about the bind10-changes
mailing list