|
|
@@ -0,0 +1,811 @@
|
|
|
+<?xml version="1.0" encoding="UTF-8"?>
|
|
|
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
|
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
|
|
|
+<!ENTITY mdash "—" >
|
|
|
+]>
|
|
|
+
|
|
|
+ <chapter id="dhcp-ddns-server">
|
|
|
+ <title>The DHCP-DDNS Server</title>
|
|
|
+ <para>
|
|
|
+ The DHCP-DDNS Server (b10-dhcp-ddns, known informally as D2) conducts the client side of
|
|
|
+ the DDNS protocol (defined in RFC 2136) on behalf of the DHCPv4 and DHCPv6
|
|
|
+ servers (b10-dhcp4 and b10-dhcp6 respectively). The DHCP servers construct
|
|
|
+ DDNS update requests, known as NameChangeRequests (NCRs), based upon DHCP
|
|
|
+ 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>
|
|
|
+ <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
|
|
|
+ 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 or more DNS
|
|
|
+ servers that publish the DNS data for that domain.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ 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.", 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 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", 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
|
|
|
+ rejected. Finally, if there are no reverse DDNS Domains defined, D2 will
|
|
|
+ simply disregard the reverse update portion of requests.
|
|
|
+ </para>
|
|
|
+ <section id="dhcp-ddns-server-start-stop">
|
|
|
+ <title>Starting and Stopping the DHCP-DDNS Server</title>
|
|
|
+ <para>
|
|
|
+ <command>b10-dhcp-ddns</command> is the BIND 10 DHCP-DDNS server and,
|
|
|
+ like other parts of BIND 10, is configured through the
|
|
|
+ <command>bindctl</command> program.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ After starting BIND 10 and entering bindctl, the first step in
|
|
|
+ configuring the server is to add it to the list of running BIND 10
|
|
|
+ services.
|
|
|
+<screen>
|
|
|
+> <userinput>config add Init/components b10-dhcp-ddns</userinput>
|
|
|
+> <userinput>config set Init/components/b10-dhcp-ddns/kind dispensable</userinput>
|
|
|
+> <userinput>config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ To remove <command>b10-dhcp-ddns</command> from the set of running services,
|
|
|
+ the <command>b10-dhcp-ddns</command> is removed from list of Init components:
|
|
|
+<screen>
|
|
|
+> <userinput>config remove Init/components b10-dhcp-ddns</userinput>
|
|
|
+> <userinput>config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Note that the server was only removed from the list, so it will not be
|
|
|
+ automatically restarted, but the server itself is still running. Hence it
|
|
|
+ is usually desired to stop it:
|
|
|
+ </para>
|
|
|
+<screen>
|
|
|
+> <userinput>DhcpDdns shutdown</userinput>
|
|
|
+</screen>
|
|
|
+ <para>
|
|
|
+ Upon start up the module will load its configuration and begin listening
|
|
|
+ for NCRs based on that configuration.
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+ <section id="d2-configuration">
|
|
|
+ <title>Configuring the DHCP-DDNS Server</title>
|
|
|
+ <para>
|
|
|
+ Once the server is started, it can be configured. To view the
|
|
|
+ current configuration, use the following command in <command>bindctl</command>:
|
|
|
+ <screen>
|
|
|
+> <userinput>config show DhcpDdns</userinput></screen>
|
|
|
+ When starting b10-dhcp-ddns module for the first time, the default
|
|
|
+ configuration will be available. It will look similar to this:
|
|
|
+<screen>
|
|
|
+> <userinput>config show DhcpDdns</userinput>
|
|
|
+DhcpDdns/ip_address "127.0.0.1" string (default)
|
|
|
+DhcpDdns/port 53001 integer (default)
|
|
|
+DhcpDdns/dns_server_timeout 100 integer (default)
|
|
|
+DhcpDdns/ncr_protocol "UDP" string (default)
|
|
|
+DhcpDdns/ncr_format "JSON" string (default)
|
|
|
+DhcpDdns/tsig_keys [] list (default)
|
|
|
+DhcpDdns/forward_ddns/ddns_domains [] list (default)
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains [] list (default)
|
|
|
+</screen>
|
|
|
+ <para>
|
|
|
+ (While displayed, the parameter "interface" is not implemented, and
|
|
|
+ will be removed in the near future.)
|
|
|
+ </para>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The configuration can be divided as follows, each of which is described
|
|
|
+ in its own section:
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>Global Server Parameters</command> —
|
|
|
+ values which control connectivity and global server behavior
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>TSIG Key Info</command> —
|
|
|
+ defines the TSIG keys used for secure traffic with DNS servers
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>Forward DDNS</command> —
|
|
|
+ defines the catalog of Forward DDNS Domains
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>Reverse DDNS</command> —
|
|
|
+ defines the catalog of Forward DDNS Domains
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ <section id="d2-server-parameter-config">
|
|
|
+ <title>Global Server Parameters</title>
|
|
|
+ <orderedlist>
|
|
|
+ <listitem><para>
|
|
|
+ ip_address - IP address on which D2 listens for requests. The default is
|
|
|
+ the local loopback interface at address 127.0.0.1. You may specify
|
|
|
+ either an IPv4 or IPv6 address.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ port - Port on which D2 listens for requests. The default value
|
|
|
+ is 53001.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ ncr_format - Socket protocol to use when sending requests to D2.
|
|
|
+ Currently only UDP is supported. TCP may be available in an upcoming
|
|
|
+ release.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ ncr_protocol - Packet format to use when sending requests to D2.
|
|
|
+ Currently only JSON format is supported. Other formats may be available
|
|
|
+ in future releases.
|
|
|
+ </para></listitem>
|
|
|
+ <listitem><para>
|
|
|
+ dns_server_timeout - The maximum amount of time in milliseconds, that
|
|
|
+ D2 will wait for a response from a DNS server to a single DNS update
|
|
|
+ message.
|
|
|
+ </para></listitem>
|
|
|
+ </orderedlist>
|
|
|
+ <para>
|
|
|
+ D2 must listen for change requests on a known address and port. By
|
|
|
+ default it listens at 127.0.0.1 on port 53001. The following example
|
|
|
+ illustrates how to change D2's global parameters so it will listen
|
|
|
+ at 192.168.1.10 port 900:
|
|
|
+<screen>
|
|
|
+> <userinput>config set DhcpDdns/ip_address "192.168.1.10"</userinput>
|
|
|
+> <userinput>config set DhcpDdns/port 900</userinput>
|
|
|
+> <userinput>config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ <warning>
|
|
|
+ <simpara>
|
|
|
+ When the DHCP-DDNS server is configured to listen at an address
|
|
|
+ other than the loopback address (127.0.0.1 or ::1), it is possible
|
|
|
+ for a malicious attacker to send bogus NameChangeRequests to it
|
|
|
+ and change entries in the DNS. For this reason, addresses other
|
|
|
+ than the IPv4 or IPv6 loopback addresses should only be used
|
|
|
+ for testing purposes. A future version of Kea will implement
|
|
|
+ authentication to guard against such attacks.
|
|
|
+ </simpara>
|
|
|
+ </warning>
|
|
|
+<note>
|
|
|
+<simpara>
|
|
|
+If the ip_address and port are changed, it will be necessary to change the
|
|
|
+corresponding values in the DHCP servers' "dhcp-ddns" configuration section.
|
|
|
+</simpara>
|
|
|
+</note>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="d2-tsig-key-list-config">
|
|
|
+ <title>TSIG Key List</title>
|
|
|
+ <para>
|
|
|
+ A DDNS protocol exchange can be conducted with or without TSIG
|
|
|
+ (defined in <ulink url="http://tools.ietf/org/html/rfc2845">RFC
|
|
|
+ 2845</ulink>). This configuration section allows the administrator
|
|
|
+ to define the set of TSIG keys that may be used in such
|
|
|
+ exchanges.</para>
|
|
|
+
|
|
|
+ <para>To use TSIG when updating entries in a DNS Domain,
|
|
|
+ a key must be defined in the TSIG Key List and referenced by
|
|
|
+ name in that domain's configuration entry. When D2 matches a
|
|
|
+ change request to a domain, it checks whether the domain has
|
|
|
+ a TSIG key associated with it. If so, D2 will use that key to
|
|
|
+ sign DNS update messages sent to and verify repsonses received
|
|
|
+ from the domain's DNS server(s). For each TSIG key required by
|
|
|
+ the DNS servers that D2 will be working with there must be a
|
|
|
+ corresponding TSIG key in the TSIG Key list.</para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ As one might gather from the name, the tsig_key section of the
|
|
|
+ D2 configuration lists the TSIG keys. Each entry describes a
|
|
|
+ TSIG key used by one or more DNS servers to authenticate requests
|
|
|
+ and sign responses. Every entry in the list has three parameters:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>name</command> —
|
|
|
+ a unique text label used to identify this key within the
|
|
|
+ list. This value is used to specify which key (if any) should be
|
|
|
+ used when updating a specific domain. So long as it is unique its
|
|
|
+ content is arbitrary, although for clarity and ease of maintenance
|
|
|
+ it is recommended that it match the name used on the DNS server(s).
|
|
|
+ It cannot be blank.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>algorithm</command> —
|
|
|
+ specifies which hashing algorithm should be used with this
|
|
|
+ key. This value must specify the same algorithm used for the
|
|
|
+ key on the DNS server(s). The supported algorithms are listed below:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-MD5</command>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-SHA1</command>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-SHA224</command>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-SHA256</command>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-SHA384</command>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <command>HMAC-SHA512</command>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ This value is not case sensitive.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>secret</command> —
|
|
|
+ is used to specify the shared secret key code for this key. This value is
|
|
|
+ case sensitive and must exactly match the value specified on the DNS server(s).
|
|
|
+ It is a base64-encoded text value.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ As an example, suppose that a domain D2 will be updating is
|
|
|
+ maintained by a BIND9 DNS server which requires dynamic updates
|
|
|
+ to be secured with TSIG. Suppose further that the entry for
|
|
|
+ the TSIG key in BIND9's named.conf file looks like this:
|
|
|
+<screen>
|
|
|
+ :
|
|
|
+ key "key.four.example.com." {
|
|
|
+ algorithm hmac-sha224;
|
|
|
+ secret "bZEG7Ow8OgAUPfLWV3aAUQ==";
|
|
|
+ };
|
|
|
+ :
|
|
|
+</screen>
|
|
|
+ By default, the TSIG Key list is empty:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/tsig_keys</userinput>
|
|
|
+DhcpDdns/tsig_keys [] list (default)
|
|
|
+</screen>
|
|
|
+ We must first create a new key in the list:
|
|
|
+<screen>
|
|
|
+<userinput>> config add DhcpDdns/tsig_keys</userinput>
|
|
|
+</screen>
|
|
|
+ Displaying the new element, reveals:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/tsig_keys[0]</userinput>
|
|
|
+DhcpDdns/tsig_keys[0]/name "" string (default)
|
|
|
+DhcpDdns/tsig_keys[0]/algorithm "HMAC-MD5" string (modified)
|
|
|
+DhcpDdns/tsig_keys[0]/secret "" string (default)
|
|
|
+</screen>
|
|
|
+ Now set all three values to match BIND9's key:
|
|
|
+<screen>
|
|
|
+<userinput>> config set DhcpDdns/tsig_keys[0]/name "key.four.example.com"</userinput>
|
|
|
+<userinput>> config set DhcpDdns/tsig_keys[0]/algorithm "HMAC-SHA224"</userinput>
|
|
|
+<userinput>> config set DhcpDdns/tsig_keys[0]/secret "bZEG7Ow8OgAUPfLWV3aAUQ=="</userinput>
|
|
|
+<userinput>> config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ These steps would be repeated for each TSIG key needed. Note that the same TSIG key
|
|
|
+ can be used with more than one domain.
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="d2-forward-ddns-config">
|
|
|
+ <title>Forward DDNS</title>
|
|
|
+ <para>
|
|
|
+ The Forward DDNS section is used to configure D2's forward update
|
|
|
+ behavior. Currently it contains a single parameter, the catalog of
|
|
|
+ forward DDNS Domains:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/forward_ddns/</userinput>
|
|
|
+DhcpDdns/forward_ddns/ddns_domains [] list (default)
|
|
|
+</screen>
|
|
|
+ By default, this list is empty, which will cause the server to ignore
|
|
|
+ the forward update portions of requests.
|
|
|
+ </para>
|
|
|
+ <section id="add-forward-ddns-domain">
|
|
|
+ <title>Adding Forward DDNS Domains</title>
|
|
|
+ <para>
|
|
|
+ A forward DDNS Domain maps a forward DNS zone to a set of DNS servers
|
|
|
+ which maintain the forward DNS data for that zone. You will need one
|
|
|
+ forward 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
|
|
|
+ matching a request to the appropriate server(s) is done by zone and
|
|
|
+ a DDNS Domain only defines a single zone.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The section describes how to add Forward DDNS Domains. Repeat these
|
|
|
+ steps for each Forward DDNS Domain desired. Each Forward DDNS Domain
|
|
|
+ has the following parameters:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>name</command> —
|
|
|
+ The fully qualified domain name (or zone) that this DDNS Domain
|
|
|
+ can update. This is value used to compare against the request
|
|
|
+ FQDN during forward matching. It must be unique within the
|
|
|
+ catalog.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <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 the value is blank (the default), TSIG will not be
|
|
|
+ used in DDNS conversations with this domain's servers. Currently
|
|
|
+ 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. 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.
|
|
|
+ If that attempt fails, it will move to next one in the list and
|
|
|
+ so on until the it achieves success or the list is exhausted.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ To create a new forward DDNS Domain, one must first add a new domain
|
|
|
+ element:
|
|
|
+<screen>
|
|
|
+<userinput>> config add DhcpDdns/forward_ddns/ddns_domains</userinput>
|
|
|
+</screen>
|
|
|
+ Displaying the DDNS Domain reveals this:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/forward_ddns/ddns_domains[0]</userinput>
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/name "" string (default)
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/key_name "" string (default)
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers [] list (default)
|
|
|
+</screen>
|
|
|
+ To set the domain's name to "other.example.com":
|
|
|
+<screen>
|
|
|
+<userinput>> config set DhcpDdns/forward_ddns/ddns_domains[1]/name "other.example.com"</userinput>
|
|
|
+<userinput>> config commit</userinput>
|
|
|
+</screen>
|
|
|
+ It is permissible 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 though, we must add at least one DNS
|
|
|
+ server to it.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section id="add-forward-dns-servers">
|
|
|
+ <title>Adding Forward DNS Servers</title>
|
|
|
+ <para>
|
|
|
+ The section describes how to add DNS servers to a Forward DDNS Domain.
|
|
|
+ Repeat them for as many servers as desired for a each domain.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ 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>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>hostname</command> —
|
|
|
+ The resolvable host name of the DNS server. This value is not
|
|
|
+ yet implemented.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <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>
|
|
|
+ <simpara>
|
|
|
+ <command>port</command> —
|
|
|
+ The port on which the server listens for DDNS requests. It
|
|
|
+ defaults to the standard DNS service port of 53.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ To create a new forward DNS Server, one must first add a new server
|
|
|
+ element to the domain:
|
|
|
+<screen>
|
|
|
+<userinput>> config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers</userinput>
|
|
|
+</screen>
|
|
|
+ Displaying the DNS Server element should appear as follows:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]</userinput>
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/hostname "" string (default)
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address "" string (default)
|
|
|
+DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
+</screen>
|
|
|
+ As stated earlier, "hostname" is not yet supported so, the parameter
|
|
|
+ "ip_address" must be set to the address of the DNS server. If for
|
|
|
+ example the service is running at "172.88.99.10", then set it as
|
|
|
+ follows:
|
|
|
+<screen>
|
|
|
+<userinput>> config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.88.99.10"</userinput>
|
|
|
+<userinput>> config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="d2-reverse-ddns-config">
|
|
|
+ <title>Reverse DDNS</title>
|
|
|
+ <para>
|
|
|
+ The Reverse DDNS section is used to configure D2's reverse update
|
|
|
+ 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>
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains [] list (default)
|
|
|
+</screen>
|
|
|
+ By default, this list is empty, which will cause the server to ignore
|
|
|
+ the reverse update portions of requests.
|
|
|
+ </para>
|
|
|
+ <section id="add-reverse-ddns-domain">
|
|
|
+ <title>Adding Reverse DDNS Domains</title>
|
|
|
+ <para>
|
|
|
+ A reverse DDNS Domain maps a reverse DNS zone to a set of DNS servers
|
|
|
+ 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, 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.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The section describes how to add Reverse DDNS Domains. Repeat these
|
|
|
+ steps for each Reverse DDNS Domain desired. Each Reverse DDNS Domain
|
|
|
+ has the following parameters:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>name</command> —
|
|
|
+ The fully qualified reverse zone that this DDNS Domain
|
|
|
+ can update. This is the value used during reverse matching
|
|
|
+ which will compare it with 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
|
|
|
+ "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>
|
|
|
+ <simpara>
|
|
|
+ <command>key_name</command> —
|
|
|
+ If TSIG should be used with this domain's servers, then this
|
|
|
+ value should be the name of that key from the TSIG Key List.
|
|
|
+ If the value is blank (the default), TSIG will not be
|
|
|
+ used in DDNS conversations with this domain's servers. Currently
|
|
|
+ this value is not used as TSIG has not been implemented.
|
|
|
+ </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
|
|
|
+ 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.
|
|
|
+ If that attempt fails, it will move to next one in the list and
|
|
|
+ so on until the it achieves success or the list is exhausted.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ To create a new reverse DDNS Domain, one must first add a new domain
|
|
|
+ element:
|
|
|
+<screen>
|
|
|
+<userinput>> config add DhcpDdns/reverse_ddns/ddns_domains</userinput>
|
|
|
+</screen>
|
|
|
+ Displaying the DDNS Domain reveals this:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/reverse_ddns/ddns_domains[0]</userinput>
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/name "" string (default)
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/key_name "" string (default)
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers [] list (default)
|
|
|
+</screen>
|
|
|
+ For domain supporting the subnet 2001:db8:1::, we would set the
|
|
|
+ domain's name as follows:
|
|
|
+<screen>
|
|
|
+<userinput>> config set DhcpDdns/reverse_ddns/ddns_domains[1]/name "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."</userinput>
|
|
|
+<userinput>> config commit</userinput>
|
|
|
+</screen>
|
|
|
+ It is permissible 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 though, we must add at least one DNS
|
|
|
+ server to it.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section id="add-reverse-dns-servers">
|
|
|
+ <title>Adding Reverse DNS Servers</title>
|
|
|
+ <para>
|
|
|
+ The section describes how to add DNS servers to a Reverse DDNS Domain.
|
|
|
+ Repeat them for as many servers as desired for a each domain.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Reverse DNS Server entries represents a actual DNS servers which
|
|
|
+ support the server side of the DDNS protocol. Each Reverse DNS Server
|
|
|
+ has the following parameters:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>hostname</command> —
|
|
|
+ The resolvable host name of the DNS server. This value is
|
|
|
+ currently ignored.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>ip_address</command> —
|
|
|
+ The IP address at which the server listens for DDNS requests.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ <command>port</command> —
|
|
|
+ The port on which the server listens for DDNS requests. It
|
|
|
+ defaults to the standard DNS service port of 53.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ To create a new reverse DNS Server, one must first add a new server
|
|
|
+ element to the domain:
|
|
|
+<screen>
|
|
|
+<userinput>> config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers</userinput>
|
|
|
+</screen>
|
|
|
+ Displaying the DNS Server element should appear as follows:
|
|
|
+<screen>
|
|
|
+<userinput>> config show DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]</userinput>
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/hostname "" string (default)
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address "" string (default)
|
|
|
+DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port 53 integer(default)
|
|
|
+</screen>
|
|
|
+ As stated earlier, "hostname" is not yet supported so, the parameter
|
|
|
+ "ip_address" must be set to the address of the DNS server. If for
|
|
|
+ example the service is running at "172.88.99.10", then set it as
|
|
|
+ follows:
|
|
|
+<screen>
|
|
|
+<userinput>> config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.88.99.10"</userinput>
|
|
|
+<userinput>> config commit</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="d2-exmaple-config">
|
|
|
+ <title>Example DHCP-DDNS Server Configuration</title>
|
|
|
+ <para>
|
|
|
+ This section provides an example DHCP-DDNS server configuration based
|
|
|
+ on a small example network. Let's suppose our example network has
|
|
|
+ three domains, each with their own subnet.
|
|
|
+
|
|
|
+ <table>
|
|
|
+ <title>Our example network</title>
|
|
|
+ <tgroup cols='4' align='left'>
|
|
|
+ <colspec colname='domain'/>
|
|
|
+ <colspec colname='subnet'/>
|
|
|
+ <colspec colname='fservers'/>
|
|
|
+ <colspec colname='rservers'/>
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>Domain</entry>
|
|
|
+ <entry>Subnet</entry>
|
|
|
+ <entry>Forward DNS Servers</entry>
|
|
|
+ <entry>Reverse DNS Servers</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>four.example.com</entry>
|
|
|
+ <entry>192.0.2.0/24</entry>
|
|
|
+ <entry>172.16.1.5, 172.16.2.5</entry>
|
|
|
+ <entry>172.16.1.5, 172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>six.example.com</entry>
|
|
|
+ <entry>2001:db8:1::/64</entry>
|
|
|
+ <entry>3001:1::50</entry>
|
|
|
+ <entry>3001:1::51</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>example.com</entry>
|
|
|
+ <entry>192.0.0.0/16</entry>
|
|
|
+ <entry>172.16.2.5</entry>
|
|
|
+ <entry>172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ We need to construct three forward DDNS Domains:
|
|
|
+ <table>
|
|
|
+ <title>Forward DDNS Domains Needed</title>
|
|
|
+ <tgroup cols='3' align='left'>
|
|
|
+ <colspec colname='num'/>
|
|
|
+ <colspec colname='name'/>
|
|
|
+ <colspec colname='servers'/>
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>#</entry>
|
|
|
+ <entry>DDNS Domain Name</entry>
|
|
|
+ <entry>DNS Servers</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>1.</entry>
|
|
|
+ <entry>four.example.com.</entry>
|
|
|
+ <entry>172.16.1.5, 172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>2.</entry>
|
|
|
+ <entry>six.example.com.</entry>
|
|
|
+ <entry>3001:1::50</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>3.</entry>
|
|
|
+ <entry>example.com.</entry>
|
|
|
+ <entry>172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </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 ("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 the Forward
|
|
|
+ DDNS Domains.
|
|
|
+<screen>
|
|
|
+<userinput>
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[0]/name "four.example.com."
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.16.1.5"
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[1]/ip_address "172.16.2.5"
|
|
|
+>
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[1]/name "six.example.com."
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains[1]/dns_servers
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[1]/dns_servers[0]/ip_address "3001:1::50:"
|
|
|
+>
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[2]/name "example.com."
|
|
|
+> config add DhcpDdns/forward_ddns/ddns_domains[2]/dns_servers
|
|
|
+> config set DhcpDdns/forward_ddns/ddns_domains[2]/dns_servers[0]/ip_address "172.16.2.5"
|
|
|
+>
|
|
|
+> config commit
|
|
|
+</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Similarly, we need to construct the three reverse DDNS Domains:
|
|
|
+ <table>
|
|
|
+ <title>Reverse DDNS Domains Needed</title>
|
|
|
+ <tgroup cols='3' align='left'>
|
|
|
+ <colspec colname='num'/>
|
|
|
+ <colspec colname='DDNS Domain name'/>
|
|
|
+ <colspec colname='DDNS Domain DNS Servers'/>
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>#</entry>
|
|
|
+ <entry>DDNS Domain Name</entry>
|
|
|
+ <entry>DNS Servers</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>1.</entry>
|
|
|
+ <entry>2.0.192.in-addr.arpa.</entry>
|
|
|
+ <entry>172.16.1.5, 172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>2.</entry>
|
|
|
+ <entry>1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa.</entry>
|
|
|
+ <entry>3001:1::50</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>3.</entry>
|
|
|
+ <entry>0.182.in-addr.arpa.</entry>
|
|
|
+ <entry>172.16.2.5</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+ An address of "192.0.2.150" will match the first domain,
|
|
|
+ "2001:db8:1::10" will match the second domain, and "192.0.50.77"
|
|
|
+ the third domain.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The following series of commands in bindctl will create our Reverse
|
|
|
+ DDNS Domains.
|
|
|
+<screen>
|
|
|
+<userinput>
|
|
|
+> config add DhcpDdns/reverse_ddns/ddns_domains
|
|
|
+> config set DhcpDdns/reverse_ddns/ddns_domains[0]/name "2.0.192.in-addr.arpa."
|
|
|
+> config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers
|
|
|
+> config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.16.1.5"
|
|
|
+> config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers
|
|
|
+> config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[1]/ip_address "172.16.2.5"
|
|
|
+>
|
|
|
+> config add DhcpDdns/reverse_ddns/ddns_domains
|
|
|
+> config set DhcpDdns/reverse_ddns/ddns_domains[1]/name "1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa."
|
|
|
+> config add DhcpDdns/reverse_ddns/ddns_domains[1]/dns_servers
|
|
|
+> 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-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"
|
|
|
+>
|
|
|
+> config commit
|
|
|
+</userinput>
|
|
|
+</screen>
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+ </section>
|
|
|
+ <section>
|
|
|
+ <title>DHCP-DDNS Server Limitations</title>
|
|
|
+ <para>The following are the current limitations of the DHCP-DDNS Server.</para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ Requests received from the DHCP servers are placed in a
|
|
|
+ queue until they are processed. Currently all queued requests
|
|
|
+ are lost when the server shuts down.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ TSIG Authentication (<ulink
|
|
|
+ url="http://tools.ietf.org/html/rfc2845">RFC 2845</ulink>)
|
|
|
+ is not supported yet.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </section>
|
|
|
+ </chapter>
|
Tomek Mrugalski