|
@@ -4528,19 +4528,21 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
As mentioned earlier, DHCPv4 can be configured to generate requests to the
|
|
|
DHCP-DDNS server to update DNS entries. These requests are known as
|
|
|
NameChangeRequests or NCRs. Each NCR contains the following information:
|
|
|
- <para>
|
|
|
- 1. Whether it is a request to add(update) or remove DNS entries
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. Whether the change requests forward DNS updates (As), reverse
|
|
|
- DNS updates (PTRs), or both.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. The FQDN, lease address, and DHCID
|
|
|
- </para>
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ Whether it is a request to add (update) or remove DNS entries
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ Whether the change requests forward DNS updates (A records), reverse
|
|
|
+ DNS updates (PTR records), or both.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ The FQDN, lease address, and DHCID
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
The paramaters for controlling the generation of NCRs for submission to D2
|
|
|
are contained in the "dhcp-ddns" section of the DHCPv4 server
|
|
|
- configuration. The default values for this secion appears as follows:
|
|
|
+ configuration. The default values for this section appears as follows:
|
|
|
<screen>
|
|
|
> <userinput>config show Dhcp4/dhcp-ddns</userinput>
|
|
|
Dhcp4/dhcp-ddns/enable-updates true boolean
|
|
@@ -4558,7 +4560,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
<para>
|
|
|
The "enable-updates" parameter determines whether or not DHCPv4 will
|
|
|
generate NCRs. By default, this value is false hence DDNS updates are
|
|
|
- disabled. To enable DDNS updates set this value to true as follows:
|
|
|
+ disabled. To enable DDNS updates set this value to true:
|
|
|
</para>
|
|
|
<screen>
|
|
|
> <userinput>config set Dhcp4/dhcp-ddns/enable-updates true</userinput>
|
|
@@ -4566,17 +4568,16 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
</screen>
|
|
|
<section id="dhcpv4-d2-io-config">
|
|
|
<title>DHCP-DDNS Server Connectivty</title>
|
|
|
- In order for NCRs to reach D2, DHCPv4 must be able to communicate with it.
|
|
|
- The following parameters are used to establish connectivty between DHCPv4
|
|
|
- and D2.
|
|
|
<para>
|
|
|
- The parameters, "server-ip" and "server-port", specify the address of the
|
|
|
- D2 server. By default, D2 is assumed to running on the same machine as
|
|
|
- DHCPv4, and the default values for these two parameters should be
|
|
|
- sufficient. However, if D2 has been configured 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:
|
|
|
+ In order for NCRs to reach the D2 server, DHCPv4 must be able
|
|
|
+ to communicate with it and so the relevant parameters must be set
|
|
|
+ appropriately. The parameters, "server-ip" and "server-port", specify
|
|
|
+ the address of the D2 server. By default, D2 is assumed to running
|
|
|
+ on the same machine as DHCPv4, and the default values for these two
|
|
|
+ parameters should be sufficient. However, if D2 has been configured
|
|
|
+ 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>
|
|
@@ -4594,7 +4595,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
</para>
|
|
|
</section>
|
|
|
<section id="dhcpv4-d2-rules-config">
|
|
|
- <title>When does DHCPv4 generates DDNS request</title>
|
|
|
+ <title>When does the DHCPv4 server generate DDNS requests?</title>
|
|
|
DHCPv4 follows the behavior prescribed for DHCP servers in RFC 4702.
|
|
|
It is important to keep in mind that DHCPv4 provides the initial decision
|
|
|
making of when and what to update and forwards that information to D2 in
|
|
@@ -4607,31 +4608,32 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
</para>
|
|
|
<para>
|
|
|
In general, DHCPv4 will generate DDNS udpate requests when:
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 1. A new lease is granted in response to a DHCP REQUEST
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. An existing lease is renewed but the FQDN associated with it has
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ A new lease is granted in response to a DHCP REQUEST
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ An existing lease is renewed but the FQDN associated with it has
|
|
|
changed.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. An existing lease is released in response to a DHCP RELEASE
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- In the second case, lease renewal, to DDNS requests will be issued: one
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ An existing lease is released in response to a DHCP RELEASE
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ In the second case, lease renewal, two DDNS requests will be issued: one
|
|
|
request to remove entries for the previous FQDN and a second request to
|
|
|
- add entries for th new FQDN. In the last case, a lease release, a
|
|
|
+ add entries for the new FQDN. In the last case, a lease release, a
|
|
|
single DDNS request to remove its entries will be made. The decision
|
|
|
- making involved when granting a new lease, the first case, is more
|
|
|
+ making involved when granting a new lease (the first case) is more
|
|
|
involved and is discussed next.
|
|
|
</para>
|
|
|
<para>
|
|
|
- DHCPv4 will generate a DDNS update request if the DHCP REQUEST contains
|
|
|
- either the FQDN option (code 81) or the Host Name option (code 12). If
|
|
|
- both are present, the server will use the FQDN option. By default the
|
|
|
- DHCPv4 server will respect the FQDN N and S flags specified by
|
|
|
- the client as shown in the following table:
|
|
|
+ When a new lease is granted, the DHCPv4 server will generate a DDNS
|
|
|
+ update request if the DHCP REQUEST contains either the FQDN option
|
|
|
+ (code 81) or the Host Name option (code 12). If both are present,
|
|
|
+ the server will use the FQDN option. By default the DHCPv4 server
|
|
|
+ will respect the FQDN N and S flags specified by the client as shown
|
|
|
+ in the following table:
|
|
|
</para>
|
|
|
<table id="fqdn-flag-table">
|
|
|
<title>Default FQDN Flag Behavior</title>
|
|
@@ -4681,6 +4683,11 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
respectively.
|
|
|
</para>
|
|
|
<para>
|
|
|
+ (Note that the flag combination N=1, S=1 is prohibited according to
|
|
|
+ RFC 4702. If such a combination is received from the client, the packet
|
|
|
+ will be dropped by the DHCPv4 server.)
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
To override client delegation, issue the following commands:
|
|
|
</para>
|
|
|
<screen>
|
|
@@ -4718,35 +4725,39 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
the client in the DHCP REQUEST.
|
|
|
<para>
|
|
|
The rules for determining the FQDN option are as follows:
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 1. If configured to do so ignore the REQUEST contents and generate a
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ If configured to do, so ignore the REQUEST contents and generate a
|
|
|
FQDN using a configurable prefix and suffix.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. If the REQUEST contains the client FQDN option than the candidate
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ If the REQUEST contains the client FQDN option, the candidate
|
|
|
name is taken from there, otherwise it is taken from the Host Name option.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. If the candidate name is a fully qualified domain name then use
|
|
|
- it.
|
|
|
- 4. If the candidate name is a partial (i.e. unqualified) name then
|
|
|
+ The candiate name may then be modified:
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a fully qualified domain name, use it.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a partial (i.e. unqualified) name then
|
|
|
add a configurable suffix to the name and use the result as the FQDN.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 5. If the candidate name is a empty then generate a FQD using a
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a empty, generate a FQDN using a
|
|
|
configurable prefix and suffix.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- To instruct DHCPv4 to always generate a FQDN, set the parmeter,
|
|
|
- "replace-client-name", to true as follows:
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ To instruct DHCPv4 to always generate the FQDN for a client, set the
|
|
|
+ parameter "replace-client-name" to true as follows:
|
|
|
</para>
|
|
|
<screen>
|
|
|
> <userinput>config set Dhcp4/dhcp-ddns/replace-client-name true</userinput>
|
|
|
> <userinput>config commit</userinput>
|
|
|
</screen>
|
|
|
<para>
|
|
|
- The prefix used when generating a FQDN is specified by the
|
|
|
+ The prefix used in the generation of a FQDN is specified by the
|
|
|
"generated-prefix" parameter. The default value is "myhost". To alter
|
|
|
its value simply set it to the desired string:
|
|
|
</para>
|
|
@@ -6004,22 +6015,25 @@ should include options from the isc option space:
|
|
|
<section id="dhcp6-ddns-config">
|
|
|
<title>Configuring DHCPv6 for DDNS</title>
|
|
|
<para>
|
|
|
- As mentioned earlier, DHCPv6 can be configured to generate requests to the
|
|
|
- DHCP-DDNS server to update DNS entries. These requests are known as
|
|
|
- NameChangeRequests or NCRs. Each NCR contains the following information:
|
|
|
- <para>
|
|
|
- 1. Whether it is a request to add(update) or remove DNS entries
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. Whether the change requests forward DNS updates (AAAAs), reverse
|
|
|
- DNS updates (PTRs), or both.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. The FQDN, lease address, and DHCID
|
|
|
- </para>
|
|
|
- The paramaters for controlling the generation of NCRs for submission to D2
|
|
|
+ As mentioned earlier, DHCPv6 can be configured to generate requests to
|
|
|
+ the DHCP-DDNS server (referred to here as the "D2" server) to update
|
|
|
+ DNS entries. These requests are known as NameChangeRequests or NCRs.
|
|
|
+ Each NCR contains the following information:
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ Whether it is a request to add (update) or remove DNS entries
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ Whether the change requests forward DNS updates (AAAA records), reverse
|
|
|
+ DNS updates (PTR records), or both.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ The FQDN, lease address, and DHCID
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ The parameters controlling the generation of NCRs for submission to D2
|
|
|
are contained in the "dhcp-ddns" section of the DHCPv6 server
|
|
|
- configuration. The default values for this secion appears as follows:
|
|
|
+ configuration. The default values for this section appears as follows:
|
|
|
<screen>
|
|
|
> <userinput>config show Dhcp6/dhcp-ddns</userinput>
|
|
|
Dhcp6/dhcp-ddns/enable-updates true boolean
|
|
@@ -6095,21 +6109,21 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
</note>
|
|
|
<para>
|
|
|
In general, DHCPv6 will generate DDNS udpate requests when:
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 1. A new lease is granted in response to a DHCP REQUEST
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. An existing lease is renewed but the FQDN associated with it has
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ A new lease is granted in response to a DHCP REQUEST
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ An existing lease is renewed but the FQDN associated with it has
|
|
|
changed.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. An existing lease is released in response to a DHCP RELEASE
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- In the second case, lease renewal, to DDNS requests will be issued: one
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ An existing lease is released in response to a DHCP RELEASE
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ In the second case, lease renewal, two DDNS requests will be issued: one
|
|
|
request to remove entries for the previous FQDN and a second request to
|
|
|
- add entries for th new FQDN. In the last case, a lease release, a
|
|
|
+ add entries for the new FQDN. In the last case, a lease release, a
|
|
|
single DDNS request to remove its entries will be made. The decision
|
|
|
making involved when granting a new lease is more involved and is
|
|
|
discussed next.
|
|
@@ -6168,6 +6182,11 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
respectively.
|
|
|
</para>
|
|
|
<para>
|
|
|
+ (Note that the flag combination N=1, S=1 is prohibited according to
|
|
|
+ RFC 4702. If such a combination is received from the client, the packet
|
|
|
+ will be dropped by the DHCPv6 server.)
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
To override client delegation, issue the following commands:
|
|
|
</para>
|
|
|
<screen>
|
|
@@ -6198,29 +6217,31 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
the client in the DHCP REQUEST.
|
|
|
<para>
|
|
|
The rules for determining the FQDN option are as follows:
|
|
|
- </para>
|
|
|
- <para>
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
If configured to do so ignore the REQUEST contents and generate a
|
|
|
FQDN using a configurable prefix and suffix.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
Otherwise, using is the domain name value from the client FQDN option as
|
|
|
the candidate name:
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 1. If the candidate name is a fully qualified domain name then use it.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 2. If the candidate name is a partial (i.e. unqualified) name then
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a fully qualified domain name then use it.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a partial (i.e. unqualified) name then
|
|
|
add a configurable suffix to the name and use the result as the FQDN.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- 3. If the candidate name is a empty then generate a FQDN using a
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ If the candidate name is a empty then generate a FQDN using a
|
|
|
configurable prefix and suffix.
|
|
|
- </para>
|
|
|
- <para>
|
|
|
- To instruct DHCPv6 to always generate a FQDN, set the parmeter,
|
|
|
- "replace-client-name", to true as follows:
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ To instruct DHCPv6 to always generate a FQDN, set the parameter
|
|
|
+ "replace-client-name" to true:
|
|
|
</para>
|
|
|
<screen>
|
|
|
> <userinput>config set Dhcp6/dhcp-ddns/replace-client-name true</userinput>
|
|
@@ -6229,7 +6250,7 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
<para>
|
|
|
The prefix used when generating a FQDN is specified by the
|
|
|
"generated-prefix" parameter. The default value is "myhost". To alter
|
|
|
- its value simply set it to the desired string:
|
|
|
+ its value, simply set it to the desired string:
|
|
|
</para>
|
|
|
<screen>
|
|
|
> <userinput>config set Dhcp6/dhcp-ddns/generated-prefix "another.host"</userinput>
|
|
@@ -6247,7 +6268,7 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
|
|
|
</screen>
|
|
|
</section>
|
|
|
<para>
|
|
|
- When qualifying a partial name, DHCPv6 will construct name of with the
|
|
|
+ When qualifying a partial name, DHCPv6 will construct a name of with the
|
|
|
format:
|
|
|
</para>
|
|
|
<para>
|
|
@@ -6473,41 +6494,41 @@ Dhcp6/renew-timer 1000 integer (default)
|
|
|
<chapter id="dhcp-ddns-server">
|
|
|
<title>The DHCP-DDNS Server</title>
|
|
|
<para>
|
|
|
- The DHCP-DDNS Server, known informally as D2, conducts the client side of
|
|
|
- the DDNS protocol (defined in RFC 2136) on behalf of other processes,
|
|
|
- primarily the DHCP servers, DHCPv4 and DHCPv6. The DHCP servers construct
|
|
|
+ The DHCP-DDNS Server (known informally as D2) conducts the client side of
|
|
|
+ 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 post these to D2. D2 will attempt to match
|
|
|
- each such request to the appropriate DNS server(s) and then carry out the
|
|
|
+ lease change events and then 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>
|
|
|
<para>
|
|
|
In order to match a request to appropriate DNS servers, D2 must have a
|
|
|
- catalog of servers from which to select. In fact, D2 has two such catalogs:
|
|
|
- one for forward DNS and one for Reverse DNS. These catalogs are referred
|
|
|
+ catalog of servers from which to select. In fact, D2 has two such catalogs,
|
|
|
+ one for forward DNS and one for reverse DNS; these catalogs are referred
|
|
|
to as DDNS Domain Lists. Each list consists of one or more named DDNS
|
|
|
- Domains. Further, each DDNS Domain has a list of of one ore more DNS
|
|
|
- servers which can update DNS data for that domain.
|
|
|
+ Domains. Further, each DDNS Domain has a list of of one or more DNS
|
|
|
+ servers that publish the DNS data for that domain.
|
|
|
</para>
|
|
|
<para>
|
|
|
- When conducting forward domain matching, D2 will use the FQDN in the
|
|
|
- request to compare against the name of each forward DDNS Domain. That
|
|
|
- domain whose name matches the longest portion of the FQDN is considered
|
|
|
- the best match. For example, if the FQDN is "myhost.sample.example.com.",
|
|
|
+ When conducting forward domain matching, D2 will compare the FQDN in
|
|
|
+ the request against the name of each forward DDNS Domain. The domain
|
|
|
+ whose name matches the longest portion of the FQDN is considered the
|
|
|
+ best match. For example, if the FQDN is "myhost.sample.example.com.",
|
|
|
and there are two forward domains in the catalog: "sample.example.com."
|
|
|
- and "example.com." then the former is the best match. Note that it is
|
|
|
- possible to not find a suitable match. Given the same two forward domains
|
|
|
- there would be no match for the FQDN, "bogus.net", and the request would be
|
|
|
- rejected. Finally, if there are no forward DDNS Domains defined, D2 will
|
|
|
- simply disregard the forward update portion of requests.
|
|
|
+ and "example.com.", the former is regarded as the best match. In some
|
|
|
+ cases, it may not be possible to find a suitable match. Given the same two
|
|
|
+ forward domains there would be no match for the FQDN, "bogus.net", so the
|
|
|
+ request would be rejected. Finally, if there are no forward DDNS Domains
|
|
|
+ defined, D2 will simply disregard the forward update portion of requests.
|
|
|
</para>
|
|
|
<para>
|
|
|
- When conducting reverse domain matching, D2 will construct a reverse
|
|
|
+ When conducting reverse domain matching, D2 constructs a reverse
|
|
|
FQDN from the lease address in the request and compare that against
|
|
|
the name of each reverse DDNS Domain. Again, the domain whose name matches
|
|
|
the longest portion of the FQDN is considered the best match. For instance,
|
|
|
if the lease address is "172.16.1.40" and there are two reverse domains in
|
|
|
- the catalog: "1.16.172.in-addr.arpa." and "16.172.in-addr.arpa"; then the
|
|
|
+ the catalog: "1.16.172.in-addr.arpa." and "16.172.in-addr.arpa", the
|
|
|
former is the best match. As with forward matching, it is possible to not
|
|
|
find a suitable match. Given the same two domains, there would be no
|
|
|
match for the lease address, "192.168.1.50", and the request would be
|
|
@@ -6661,16 +6682,14 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section.
|
|
|
<simpara>
|
|
|
<command>algorithm</command> —
|
|
|
specifies the which hashing algorithm should be used with this
|
|
|
- key. This value is not yet put to use, so it may contain any
|
|
|
- string value. Once implemented it will be limited to one of
|
|
|
- finite list of supported alogorithms.
|
|
|
+ key. This value is not currently used.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<simpara>
|
|
|
<command>secret</command> —
|
|
|
is used to specify the shared secret key code for this key. This
|
|
|
- value is not yet put to use so it may contain any string.
|
|
|
+ value is not currently used.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
@@ -6745,18 +6764,18 @@ DhcpDdns/forward_ddns/ddns_domains [] list (default)
|
|
|
<listitem>
|
|
|
<simpara>
|
|
|
<command>key_name</command> —
|
|
|
- If TSIG should be used with this domain's servers, then this
|
|
|
+ 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
|
|
|
used in DDNS converations with this domain's servers. Currently
|
|
|
- this value is not used as TSIG is not yet functional.
|
|
|
+ TSIG has not been implemented, so this value is ignored.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<simpara>
|
|
|
<command>dns_servers</command> —
|
|
|
a list of one or more DNS servers which can conduct the server
|
|
|
- side of the DDNS protocol for this domain. Currently the servers
|
|
|
+ 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
|
|
|
first server in this list and attempt to communicate with it.
|
|
@@ -6784,8 +6803,8 @@ DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers [] list (default)
|
|
|
</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. In
|
|
|
- order to make the domain useful, we must add at least one DNS server
|
|
|
- to it.
|
|
|
+ order to make the domain useful though, we must add at least one DNS
|
|
|
+ server to it.
|
|
|
</para>
|
|
|
|
|
|
<section id="add-forward-dns-servers">
|
|
@@ -6795,7 +6814,7 @@ DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers [] list (default)
|
|
|
Repeat them for as many servers as desired for a each domain.
|
|
|
</para>
|
|
|
<para>
|
|
|
- Forward DNS Server entries represents a actual DNS servers which
|
|
|
+ Forward DNS Server entries represent actual DNS servers which
|
|
|
support the server side of the DDNS protocol. Each Forward DNS Server
|
|
|
has the following parameters:
|
|
|
<itemizedlist>
|
|
@@ -6851,7 +6870,8 @@ DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
<title>Reverse DDNS</title>
|
|
|
<para>
|
|
|
The Reverse DDNS section is used to configure D2's reverse update
|
|
|
- behavior. Currently it contains a single parameter, the catalog of
|
|
|
+ behavior, and the concepts are the same as for the forward DDNS
|
|
|
+ section. Currently it contains a single parameter, the catalog of
|
|
|
reverse DDNS Domains:
|
|
|
<screen>
|
|
|
<userinput>> config show DhcpDdns/reverse_ddns/</userinput>
|
|
@@ -6867,7 +6887,8 @@ 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. You will still need one DDNS Domain per zone. Remember that
|
|
|
+ servers; even then, uou 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.
|
|
|
</para>
|
|
@@ -6879,18 +6900,15 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
|
|
|
<listitem>
|
|
|
<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.
|
|
|
- </simpara>
|
|
|
- <simpara>
|
|
|
- To support the subnet 172.16.1 the name should be. "1.16.172.in-addr.arpa.".
|
|
|
- </simpara>
|
|
|
- <simpara>
|
|
|
- To support an IPv6 subent of 2001:db8:1, the name should be "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
|
|
|
- </simpara>
|
|
|
- It must be unique within the catalog.
|
|
|
- <simpara>
|
|
|
+ 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
|
|
|
+ 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
|
|
|
+ "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
|
|
|
+ Whatever the name, it must be unique within the catalog.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
@@ -6900,7 +6918,7 @@ DhcpDdns/reverse_ddns/ddns_domains [] list (default)
|
|
|
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
|
|
|
used in DDNS converations with this domain's servers. Currently
|
|
|
- this value is not used as TSIG is not yet functional.
|
|
|
+ this value is not used as TSIG has not been implemented.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
@@ -6935,7 +6953,7 @@ 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. In
|
|
|
+ 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.
|
|
|
</para>
|
|
@@ -6954,8 +6972,8 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers [] list (default)
|
|
|
<listitem>
|
|
|
<simpara>
|
|
|
<command>hostname</command> —
|
|
|
- The resolvable host name of the DNS server. This value is not
|
|
|
- yet implemented.
|
|
|
+ The resolvable host name of the DNS server. This value is
|
|
|
+ currently ignored.
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
@@ -7045,7 +7063,7 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
</table>
|
|
|
</para>
|
|
|
<para>
|
|
|
- You will need to construct three forward DDNS Domains:
|
|
|
+ We need to construct three forward DDNS Domains:
|
|
|
<table>
|
|
|
<title>Forward DDNS Domains Needed</title>
|
|
|
<tgroup cols='3' align='left'>
|
|
@@ -7080,12 +7098,13 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
</table>
|
|
|
As discussed earlier, FQDN to domain matching is based on the longest
|
|
|
match. The FQDN, "myhost.four.example.com.", will match the first
|
|
|
- domain while "admin.example.com." will match the third domain. The
|
|
|
- FQDN, "other.example.net." , would fail to match any domain and would
|
|
|
+ domain ("four.example.com") while "admin.example.com." will match the
|
|
|
+ third domain ("example.com"). The
|
|
|
+ FQDN, "other.example.net." will fail to match any domain and would
|
|
|
be rejected.
|
|
|
</para>
|
|
|
<para>
|
|
|
- The following series of commands in bindctl will create our Forward
|
|
|
+ The following series of commands in bindctl will create the Forward
|
|
|
DDNS Domains.
|
|
|
<screen>
|
|
|
<userinput>
|
|
@@ -7111,7 +7130,7 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
</screen>
|
|
|
</para>
|
|
|
<para>
|
|
|
- Similarly, you will need to construct three reverse DDNS Domains:
|
|
|
+ Similarly, we need to construct the three reverse DDNS Domains:
|
|
|
<table>
|
|
|
<title>Reverse DDNS Domains Needed</title>
|
|
|
<tgroup cols='3' align='left'>
|
|
@@ -7166,7 +7185,7 @@ DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
> config set DhcpDdns/reverse_ddns/ddns_domains[1]/dns_servers[0]/ip_address "3001:1::50:"
|
|
|
>
|
|
|
> config add DhcpDdns/reverse_ddns/ddns_domains
|
|
|
-> config set DhcpDdns/reverse_ddns/ddns_domains[2]/name "0.192.in-addrs.arpa."
|
|
|
+> config set DhcpDdns/reverse_ddns/ddns_domains[2]/name "0.192.in-addr.arpa."
|
|
|
> config add DhcpDdns/reverse_ddns/ddns_domains[2]/dns_servers
|
|
|
> config set DhcpDdns/reverse_ddns/ddns_domains[2]/dns_servers[0]/ip_address "172.16.2.5"
|
|
|
>
|