|
|
@@ -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.
|
|
|
|
|
|
+@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.
|
|
|
+
|
|
|
+@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.
|
|
|
+
|
|
|
+@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.
|
Marcin Siodelski