Commit 44d1f2b6 authored by Marcin Siodelski's avatar Marcin Siodelski
Browse files

[3035] Updated DHCPv4 Developer's Guide with respect to DNS updates.

Also, fixed a few typos in the DHCPv6 Developer's Guide.
parent 9dc963b3
......@@ -53,6 +53,7 @@
* - @subpage dhcpv4Session
* - @subpage dhcpv4ConfigParser
* - @subpage dhcpv4ConfigInherit
* - @subpage dhcpv4DDNSIntegration
* - @subpage dhcpv4Other
* - @subpage dhcp6
* - @subpage dhcpv6Session
......
// 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.
......
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment