|
|
@@ -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>
|
|
|
> <userinput>config set Dhcp4/dhcp-ddns/server-ip "198.162.1.10"</userinput>
|
|
|
> <userinput>config set Dhcp4/dhcp-ddns/server-port 900</userinput>
|
|
|
> <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
|
|
|
> <userinput>config set Dhcp6/dhcp-ddns/server-port 900</userinput>
|
|
|
> <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>
|
|
|
> <userinput>config set DhcpDdns/ip_address "192.168.1.10"</userinput>
|
|
|
> <userinput>config set DhcpDdns/port 900</userinput>
|
|
|
> <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> —
|
|
|
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> —
|
|
|
- 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> —
|
|
|
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> —
|
|
|
- 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> —
|
|
|
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> —
|
|
|
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> —
|
|
|
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">
|
Thomas Markwalder