mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-30 21:45:37 +00:00
Code Issues Releases Wiki Activity

[3282] Addressed review comments.

Browse Source 
Added discussion of reverse DNS udpates to tables 17.4 and 18.4.
Fixed other minor typos.
This commit is contained in:
Thomas Markwalder
2014-03-13 11:00:49 -04:00
parent 6ae5373961
commit 48859222b7
1 changed files with 56 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

97
doc/guide/bind10-guide.xml
View File

@@ -4578,12 +4578,14 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
to listen on a different address or port, these values must altered
accordingly. For example, if D2 has been configured to listen on
198.162.1.10 port 900, the following commands would be required:
</para>
<screen>
&gt; <userinput>config set Dhcp4/dhcp-ddns/server-ip "198.162.1.10"</userinput>
&gt; <userinput>config set Dhcp4/dhcp-ddns/server-port 900</userinput>
&gt; <userinput>config commit</userinput>
</screen>
D2 can be configured to listen over IPv4 or IPv6, therefore server-ip
may be either an IPv4 or IPv6 address.
</para>
<para>
The socket protocol that DHCPv4 should use to communicate with D2 is
specified with the "ncr-protocol" parameter. Currently only UDP is
@@ -4653,20 +4655,22 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<tbody>
<row>
<entry>0-0</entry>
<entry>Client wants to perform forward DNS updates</entry>
<entry>Server does not generate request</entry>
<entry>
Client wants to do forward updates, server should do reverse updates
</entry>
<entry>Server generates reverse-only request</entry>
<entry>1-0-0</entry>
</row>
<row>
<entry>0-1</entry>
<entry>Client wants the server to perform forward DNS updates</entry>
<entry>Server generates request</entry>
<entry>Server should do both forward and reverse updates</entry>
<entry>Server generates request to update both directions</entry>
<entry>0-1-0</entry>
</row>
<row>
<entry>1-0</entry>
<entry>Client wants no DNS updates done</entry>
<entry>Server does not generate request</entry>
<entry>Client wants no updates done</entry>
<entry>Server does not generate a request</entry>
<entry>1-0-0</entry>
</row>
</tbody>
@@ -4675,12 +4679,14 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<para>
The first row in the table above represents "client delegation". Here
the DHCP client states that it intends to do the forward DNS updates and
therefore the server should not attempt them. The parameter,
"override-client-update", can be used to instruct the server to override
client delegation requests. When this parameter is true, DHCPv4 will
generate DDNS udpate request to D2 even if the client requests delegation.
The N-S-O flags in the server's response to the client will be 0-1-1
respectively.
the server should do the reverese updates. By default, DHCPv4 will honor
the client's wishes and generate a DDNS request to D2 to update only
reverse DNS data. The parameter, "override-client-update", can be used
to instruct the server to override client delegation requests. When
this parameter is true, DHCPv4 will disregard requests for client
delegation and generate a DDNS request to update both forward and
reverse DNS data. In this case, the N-S-O flags in the server's
response to the client will be 0-1-1 respectively.
</para>
<para>
(Note that the flag combination N=1, S=1 is prohibited according to
@@ -6076,6 +6082,8 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
&gt; <userinput>config set Dhcp6/dhcp-ddns/server-port 900</userinput>
&gt; <userinput>config commit</userinput>
</screen>
D2 can be configured to listen over IPv4 or IPv6, therefore server-ip
may be either an IPv4 or IPv6 address.
<para>
The socket protocol that DHCPv6 should use to communicate with D2 is
specified with the "ncr-protocol" parameter. Currently only UDP is
@@ -6152,20 +6160,22 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
<tbody>
<row>
<entry>0-0</entry>
<entry>Client wants to perform forward DNS updates</entry>
<entry>Server does not generate request</entry>
<entry>
Client wants to do forward updates, server should do reverse updates
</entry>
<entry>Server generates reverse-only request</entry>
<entry>1-0-0</entry>
</row>
<row>
<entry>0-1</entry>
<entry>Client wants the server to perform forward DNS updates</entry>
<entry>Server generates request</entry>
<entry>Server should do both forward and reverse updates</entry>
<entry>Server generates request to update both directions</entry>
<entry>0-1-0</entry>
</row>
<row>
<entry>1-0</entry>
<entry>Client wants no DNS updates done</entry>
<entry>Server does not generate request</entry>
<entry>Client wants no updates done</entry>
<entry>Server does not generate a request</entry>
<entry>1-0-0</entry>
</row>
</tbody>
@@ -6174,12 +6184,14 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
<para>
The first row in the table above represents "client delegation". Here
the DHCP client states that it intends to do the forward DNS updates and
therefore the server should not attempt them. The parameter,
"override-client-update", can be used to instruct the server to override
client delegation requests. When this parameter is true, DHCPv6 will
generate DDNS udpate request to D2 even if the client requests delegation.
The N-S-O flags in the server's response to the client will be 0-1-1
respectively.
the server should do the reverese updates. By default, DHCPv6 will honor
the client's wishes and generate a DDNS request to D2 to update only
reverse DNS data. The parameter, "override-client-update", can be used
to instruct the server to override client delegation requests. When
this parameter is true, DHCPv6 will disregard requests for client
delegation and generate a DDNS request to update both forward and
reverse DNS data. In this case, the N-S-O flags in the server's
response to the client will be 0-1-1 respectively.
</para>
<para>
(Note that the flag combination N=1, S=1 is prohibited according to
@@ -6268,7 +6280,7 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
</screen>
</section>
<para>
When qualifying a partial name, DHCPv6 will construct a name of with the
When qualifying a partial name, DHCPv6 will construct a name with the
format:
</para>
<para>
@@ -6498,7 +6510,7 @@ Dhcp6/renew-timer 1000 integer (default)
the DDNS protocol (defined in RFC 2136) on behalf of the DHCPv4 and DHCPv6
servers. The DHCP servers construct
DDNS update requests, known as NameChangeRequests (NCRs), based upon DHCP
lease change events and then these to D2. D2 attempts to match
lease change events and then post these to D2. D2 attempts to match
each such request to the appropriate DNS server(s) and carry out the
necessary conversation with those servers to update the DNS data.
</para>
@@ -6634,12 +6646,14 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
governed by the parameters, "ip-address" and "port". Either value
may be changed using config set/commit. For example to change the
server to listen at 192.168.1.10 port 900:
</para>
<screen>
&gt; <userinput>config set DhcpDdns/ip_address "192.168.1.10"</userinput>
&gt; <userinput>config set DhcpDdns/port 900</userinput>
&gt; <userinput>config commit</userinput>
</screen>
The server may be configured to listen over IPv4 or IPv6, therefore
ip-address may an IPv4 or IPv6 address.
</para>
<note>
<simpara>
If the ip_address and port are changed, it will be necessary to change the
@@ -6674,14 +6688,14 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section.
<command>name</command> &mdash;
is a unique text label used to idenfity the this key within the
list. It is this value that is used to specify which key (if any)
should be used with a specific DNS server. So long it is unique,
its content is arbitrary. It cannot be blank.
should be used with a specific DNS server. So long as it is
unique, its content is arbitrary. It cannot be blank.
</simpara>
</listitem>
<listitem>
<simpara>
<command>algorithm</command> &mdash;
specifies the which hashing algorithm should be used with this
specifies which hashing algorithm should be used with this
key. This value is not currently used.
</simpara>
</listitem>
@@ -6766,7 +6780,7 @@ DhcpDdns/forward_ddns/ddns_domains [] list (default)
<command>key_name</command> &mdash;
If TSIG is used with this domain's servers, this
value should be the name of the key from within the TSIG Key List
to use. If it the value is blank (the default), TSIG will not be
to use. If the value is blank (the default), TSIG will not be
used in DDNS converations with this domain's servers. Currently
TSIG has not been implemented, so this value is ignored.
</simpara>
@@ -6774,7 +6788,7 @@ DhcpDdns/forward_ddns/ddns_domains [] list (default)
<listitem>
<simpara>
<command>dns_servers</command> &mdash;
a list of one or more DNS servers which can conduct the server
A list of one or more DNS servers which can conduct the server
side of the DDNS protocol for this domain. The servers
are used in a first to last preference. In other words, when D2
begins to process a request for this domain it will pick the
@@ -6829,6 +6843,7 @@ DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers [] list (default)
<simpara>
<command>ip_address</command> &mdash;
The IP address at which the server listens for DDNS requests.
This may be either an IPv4 or an IPv6 address.
</simpara>
</listitem>
<listitem>
@@ -6887,7 +6902,7 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
which maintain the reverse DNS data for that zone. You will need one
reverse DDNS Domain for each zone you wish to service. It may very
well be that some or all of your zones are maintained by the same
servers; even then, uou will still need one DDNS Domain entry for each
servers; even then, you will still need one DDNS Domain entry for each
zone. Remember that
matching a request to the appropriate server(s) is done by zone and
a DDNS Domain only defines a single zone.
@@ -6901,9 +6916,9 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
<simpara>
<command>name</command> &mdash;
The fully qualified reverse zone that this DDNS Domain
can update. This is the value used to compare against the
request the reversed version of the lease address during
reverse matching. The zone name should follow the appropriate
can update. This is the value used during reverse matching
which will compare it a reversed version of the request's lease
address. The zone name should follow the appropriate
standards: for example, to to support the IPv4 subnet 172.16.1,
the name should be. "1.16.172.in-addr.arpa.". Similarly,
to support an IPv6 subent of 2001:db8:1, the name should be
@@ -6916,7 +6931,7 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
<command>key_name</command> &mdash;
If TSIG should be used with this domain's servers, then this
value should be the name of the key from within the TSIG Key List
to use. If it the value is blank (the default), TSIG will not be
to use. If the value is blank (the default), TSIG will not be
used in DDNS converations with this domain's servers. Currently
this value is not used as TSIG has not been implemented.
</simpara>
@@ -6953,9 +6968,9 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers [] list (default)
<userinput>> config commit</userinput>
</screen>
It is permissable to add a domain without any servers. If that domain
should be matched to a request, however, the request will fail. However, in
order to make the domain useful, we must add at least one DNS server
to it.
should be matched to a request, however, the request will fail. In
order to make the domain useful though, we must add at least one DNS
server to it.
</para>
<section id="add-reverse-dns-servers">