From: Francis Dupont Date: Sat, 11 Mar 2017 00:31:58 +0000 (+0100) Subject: [master] Began -t support for D2/CA X-Git-Tag: trac5152_base~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=23319d1c41f4c021d45290e92f978ddd838a70b5;p=thirdparty%2Fkea.git [master] Began -t support for D2/CA --- diff --git a/doc/guide/ddns.xml b/doc/guide/ddns.xml index 1479feddb1..c32d244409 100644 --- a/doc/guide/ddns.xml +++ b/doc/guide/ddns.xml @@ -97,9 +97,14 @@ - -W - prints out Kea configuration report - and exits. - + -t file + specifies the configuration file to be tested. Kea-dhcp-ddns + will attempt to load it, and will conduct sanity checks. + Note that certain checks are possible only while running + the actual server. The actual status is reported with exit + code (0 = configuration looks ok, 1 = error encountered). + Kea will print out log messages to standard output and error + to standard error when testing configuration. @@ -152,9 +157,9 @@ strings path/kea-dhcp-ddns | sed -n 's/;;;; //p'
Configuring the DHCP-DDNS Server - Before starting kea-dhcp-ddns module for the - first time, a configuration file needs to be created. The following default - configuration is a template that can be customised to your requirements. + Before starting kea-dhcp-ddns module for the + first time, a configuration file needs to be created. The following default + configuration is a template that can be customised to your requirements. "DhcpDdns": { "ip-address": "127.0.0.1", @@ -164,10 +169,10 @@ strings path/kea-dhcp-ddns | sed -n 's/;;;; //p' "ncr-format": "JSON", "tsig-keys": [ ], "forward-ddns": { - "ddns-domains": [ ] + "ddns-domains": [ ] }, "reverse-ddns": { - "ddns-domains": [ ] + "ddns-domains": [ ] } } @@ -176,30 +181,30 @@ strings path/kea-dhcp-ddns | sed -n 's/;;;; //p' The configuration can be divided as follows, each of which is described in its own section: - - - + + + Global Server Parameters - values which control connectivity and global server behavior - - - - - TSIG Key Info - defines the TSIG keys used for secure traffic with DNS servers - - - - - Forward DDNS - defines the catalog of Forward DDNS Domains - - - - - Reverse DDNS - defines the catalog of Forward DDNS Domains - - - + + + + + TSIG Key Info - defines the TSIG keys used for secure traffic with DNS servers + + + + + Forward DDNS - defines the catalog of Forward DDNS Domains + + + + + Reverse DDNS - defines the catalog of Forward DDNS Domains + + +
- Global Server Parameters + Global Server Parameters @@ -231,11 +236,11 @@ strings path/kea-dhcp-ddns | sed -n 's/;;;; //p' - - 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: + + 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: "DhcpDdns": { "ip-address": "192.168.1.10", @@ -243,19 +248,19 @@ strings path/kea-dhcp-ddns | sed -n 's/;;;; //p' ... } } - - - - It is possible for a malicious attacker to send bogus - NameChangeRequests to the DHCP-DDNS server. Addresses - other than the IPv4 or IPv6 loopback addresses (127.0.0.1 - or ::1) should only be used for testing purposes, but - note that local users may still communicate with the - DHCP-DDNS server. A future version of Kea will implement - authentication to guard against such attacks. - + + + + It is possible for a malicious attacker to send bogus + NameChangeRequests to the DHCP-DDNS server. Addresses + other than the IPv4 or IPv6 loopback addresses (127.0.0.1 + or ::1) should only be used for testing purposes, but + note that local users may still communicate with the + DHCP-DDNS server. A future version of Kea will implement + authentication to guard against such attacks. + - + If the ip-address and port are changed, it will be necessary to change the @@ -265,96 +270,96 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section.
- TSIG Key List - - A DDNS protocol exchange can be conducted with or without TSIG - (defined in RFC - 2845). This configuration section allows the administrator - to define the set of TSIG keys that may be used in such - exchanges. - - 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 responses 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. - - - 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: - - - - name - - 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. - - - - - algorithm - - 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: - - - HMAC-MD5 - - - HMAC-SHA1 - - - HMAC-SHA224 - - - HMAC-SHA256 - - - HMAC-SHA384 - - - HMAC-SHA512 - - - This value is not case sensitive. - - - - - digest-bits - - is used to specify the minimum truncated length in bits. - The default value 0 means truncation is forbidden, non-zero - values must be an integral number of octets, be greater - than 80 and the half of the full length. Note in BIND9 - this parameter is appended after a dash to the algorithm - name. - - - - - secret - - 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. - - - - - - 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: + TSIG Key List + + A DDNS protocol exchange can be conducted with or without TSIG + (defined in RFC + 2845). This configuration section allows the administrator + to define the set of TSIG keys that may be used in such + exchanges. + + 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 responses 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. + + + 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: + + + + name - + 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. + + + + + algorithm - + 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: + + + HMAC-MD5 + + + HMAC-SHA1 + + + HMAC-SHA224 + + + HMAC-SHA256 + + + HMAC-SHA384 + + + HMAC-SHA512 + + + This value is not case sensitive. + + + + + digest-bits - + is used to specify the minimum truncated length in bits. + The default value 0 means truncation is forbidden, non-zero + values must be an integral number of octets, be greater + than 80 and the half of the full length. Note in BIND9 + this parameter is appended after a dash to the algorithm + name. + + + + + secret - + 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. + + + + + + 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: : key "key.four.example.com." { @@ -363,7 +368,7 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section. }; : - By default, the TSIG Key list is empty: + By default, the TSIG Key list is empty: "DhcpDdns": { "tsig-keys": [ ], @@ -371,333 +376,333 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section. } - We must extend the list with a new key: + We must extend the list with a new key: "DhcpDdns": { "tsig-keys": [ { - "name": "key.four.example.com.", - "algorithm": "HMAC-SHA224", - "secret": "bZEG7Ow8OgAUPfLWV3aAUQ==" - } + "name": "key.four.example.com.", + "algorithm": "HMAC-SHA224", + "secret": "bZEG7Ow8OgAUPfLWV3aAUQ==" + } ], ... } - + - These steps would be repeated for each TSIG key needed. Note that - the same TSIG key can be used with more than one domain. + These steps would be repeated for each TSIG key needed. Note that + the same TSIG key can be used with more than one domain.
- +
- Forward DDNS - - 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, which is a list of structures. + Forward DDNS + + 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, which is a list of structures. "DhcpDdns": { "forward-ddns": { - "ddns-domains": [ ] + "ddns-domains": [ ] }, ... } - By default, this list is empty, which will cause the server to ignore - the forward update portions of requests. - -
- Adding Forward DDNS Domains - - A forward DDNS Domain maps a forward DNS zone to a set of - DNS servers which maintain the forward DNS data (i.e. name to - address mapping) 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. - - - This 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: - - - - name - - 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. - - - - - key-name - - 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. - - - - - dns-servers - - 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. - - - - To create a new forward DDNS Domain, one must add a new domain - element and set its parameters: + By default, this list is empty, which will cause the server to ignore + the forward update portions of requests. + +
+ Adding Forward DDNS Domains + + A forward DDNS Domain maps a forward DNS zone to a set of + DNS servers which maintain the forward DNS data (i.e. name to + address mapping) 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. + + + This 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: + + + + name - + 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. + + + + + key-name - + 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. + + + + + dns-servers - + 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. + + + + To create a new forward DDNS Domain, one must add a new domain + element and set its parameters: "DhcpDdns": { "forward-ddns": { - "ddns-domains": [ - { - "name": "other.example.com.", - "key-name": "", - "dns-servers": [ - ] - } - ] + "ddns-domains": [ + { + "name": "other.example.com.", + "key-name": "", + "dns-servers": [ + ] + } + ] } } - 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. - - -
- Adding Forward DNS Servers - - This section describes how to add DNS servers to a Forward DDNS Domain. - Repeat them for as many servers as desired for a each domain. - - - 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: - - - - hostname - - The resolvable host name of the DNS server. This value is not - yet implemented. - - - - - ip-address - - The IP address at which the server listens for DDNS requests. - This may be either an IPv4 or an IPv6 address. - - - - - port - - The port on which the server listens for DDNS requests. It - defaults to the standard DNS service port of 53. - - - - To create a new forward DNS Server, one must add a new server - element to the domain and fill in its parameters. If for - example the service is running at "172.88.99.10", then set it as - follows: + 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. + + +
+ Adding Forward DNS Servers + + This section describes how to add DNS servers to a Forward DDNS Domain. + Repeat them for as many servers as desired for a each domain. + + + 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: + + + + hostname - + The resolvable host name of the DNS server. This value is not + yet implemented. + + + + + ip-address - + The IP address at which the server listens for DDNS requests. + This may be either an IPv4 or an IPv6 address. + + + + + port - + The port on which the server listens for DDNS requests. It + defaults to the standard DNS service port of 53. + + + + To create a new forward DNS Server, one must add a new server + element to the domain and fill in its parameters. If for + example the service is running at "172.88.99.10", then set it as + follows: "DhcpDdns": { "forward-ddns": { - "ddns-domains": [ - { - "name": "other.example.com.", - "key-name": "", - "dns-servers": [ - { - "hostname": "", - "ip-address": "172.88.99.10", - "port": 53 - } - ] - } - ] + "ddns-domains": [ + { + "name": "other.example.com.", + "key-name": "", + "dns-servers": [ + { + "hostname": "", + "ip-address": "172.88.99.10", + "port": 53 + } + ] + } + ] } } - + - As stated earlier, "hostname" is not yet supported so, the parameter - "ip-address" must be set to the address of the DNS server. + As stated earlier, "hostname" is not yet supported so, the parameter + "ip-address" must be set to the address of the DNS server. -
+
- Reverse DDNS - - 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, which is a list of structures. + Reverse DDNS + + 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, which is a list of structures. "DhcpDdns": { "reverse-ddns": { - "ddns-domains": [ ] + "ddns-domains": [ ] } ... } - By default, this list is empty, which will cause the server to ignore - the reverse update portions of requests. - -
- Adding Reverse DDNS Domains - - A reverse DDNS Domain maps a reverse DNS zone to a set of DNS - servers which maintain the reverse DNS data (address to name - mapping) 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. - - - This 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: - - - - name - - 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 subnet 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. - - - - - key-name - - 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. - - - - - dns-servers - - 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. - - - - To create a new reverse DDNS Domain, one must add a new domain element - and set its parameters. For example, to support subnet 2001:db8:1::, - the following configuration could be used: + By default, this list is empty, which will cause the server to ignore + the reverse update portions of requests. + +
+ Adding Reverse DDNS Domains + + A reverse DDNS Domain maps a reverse DNS zone to a set of DNS + servers which maintain the reverse DNS data (address to name + mapping) 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. + + + This 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: + + + + name - + 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 subnet 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. + + + + + key-name - + 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. + + + + + dns-servers - + 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. + + + + To create a new reverse DDNS Domain, one must add a new domain element + and set its parameters. For example, to support subnet 2001:db8:1::, + the following configuration could be used: "DhcpDdns": { "reverse-ddns": { - "ddns-domains": [ - { - "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", - "key-name": "", - "dns-servers": [ - ] - } - ] + "ddns-domains": [ + { + "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", + "key-name": "", + "dns-servers": [ + ] + } + ] } } - 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. - - -
- Adding Reverse DNS Servers - - This section describes how to add DNS servers to a Reverse DDNS Domain. - Repeat them for as many servers as desired for each domain. - - - 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: - - - - hostname - - The resolvable host name of the DNS server. This value is - currently ignored. - - - - - ip-address - - The IP address at which the server listens for DDNS requests. - - - - - port - - The port on which the server listens for DDNS requests. It - defaults to the standard DNS service port of 53. - - - - To create a new reverse DNS Server, one must first add a new server - element to the domain and fill in its parameters. If for - example the service is running at "172.88.99.10", then set it as - follows: + 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. + + +
+ Adding Reverse DNS Servers + + This section describes how to add DNS servers to a Reverse DDNS Domain. + Repeat them for as many servers as desired for each domain. + + + 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: + + + + hostname - + The resolvable host name of the DNS server. This value is + currently ignored. + + + + + ip-address - + The IP address at which the server listens for DDNS requests. + + + + + port - + The port on which the server listens for DDNS requests. It + defaults to the standard DNS service port of 53. + + + + To create a new reverse DNS Server, one must first add a new server + element to the domain and fill in its parameters. If for + example the service is running at "172.88.99.10", then set it as + follows: "DhcpDdns": { "reverse-ddns": { - "ddns-domains": [ - { - "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", - "key-name": "", - "dns-servers": [ - { - "hostname": "", - "ip-address": "172.88.99.10", - "port": 53 - } - ] - } - ] + "ddns-domains": [ + { + "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", + "key-name": "", + "dns-servers": [ + { + "hostname": "", + "ip-address": "172.88.99.10", + "port": 53 + } + ] + } + ] } } @@ -710,219 +715,219 @@ corresponding values in the DHCP servers' "dhcp-ddns" configuration section. -
+
- Example DHCP-DDNS Server Configuration - - 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. - - - Our example network - - - - - - - - Domain - Subnet - Forward DNS Servers - Reverse DNS Servers - - - - - four.example.com - 192.0.2.0/24 - 172.16.1.5, 172.16.2.5 - 172.16.1.5, 172.16.2.5 - - - six.example.com - 2001:db8:1::/64 - 3001:1::50 - 3001:1::51 - - - example.com - 192.0.0.0/16 - 172.16.2.5 - 172.16.2.5 - - - -
- - - We need to construct three forward DDNS Domains: - - Forward DDNS Domains Needed - - - - - - - # - DDNS Domain Name - DNS Servers - - - - - 1. - four.example.com. - 172.16.1.5, 172.16.2.5 - - - 2. - six.example.com. - 3001:1::50 - - - 3. - example.com. - 172.16.2.5 - - - -
- 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. - - - The following example configuration specified the Forward DDNS Domains. + Example DHCP-DDNS Server Configuration + + 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. + + + Our example network + + + + + + + + Domain + Subnet + Forward DNS Servers + Reverse DNS Servers + + + + + four.example.com + 192.0.2.0/24 + 172.16.1.5, 172.16.2.5 + 172.16.1.5, 172.16.2.5 + + + six.example.com + 2001:db8:1::/64 + 3001:1::50 + 3001:1::51 + + + example.com + 192.0.0.0/16 + 172.16.2.5 + 172.16.2.5 + + + +
+ + + We need to construct three forward DDNS Domains: + + Forward DDNS Domains Needed + + + + + + + # + DDNS Domain Name + DNS Servers + + + + + 1. + four.example.com. + 172.16.1.5, 172.16.2.5 + + + 2. + six.example.com. + 3001:1::50 + + + 3. + example.com. + 172.16.2.5 + + + +
+ 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. + + + The following example configuration specified the Forward DDNS Domains. "DhcpDdns": { "forward-ddns": { - "ddns-domains": [ - { - "name": "four.example.com.", - "key-name": "", - "dns-servers": [ - { "ip-address": "172.16.1.5" }, - { "ip-address": "172.16.2.5" } - ] - }, - { - "name": "six.example.com.", - "key-name": "", - "dns-servers": [ - { "ip-address": "2001:db8::1" } - ] - }, - { - "name": "example.com.", - "key-name": "", - "dns-servers": [ - { "ip-address": "172.16.2.5" } - ] - }, - - ] + "ddns-domains": [ + { + "name": "four.example.com.", + "key-name": "", + "dns-servers": [ + { "ip-address": "172.16.1.5" }, + { "ip-address": "172.16.2.5" } + ] + }, + { + "name": "six.example.com.", + "key-name": "", + "dns-servers": [ + { "ip-address": "2001:db8::1" } + ] + }, + { + "name": "example.com.", + "key-name": "", + "dns-servers": [ + { "ip-address": "172.16.2.5" } + ] + }, + + ] } } - - - Similarly, we need to construct the three reverse DDNS Domains: - - Reverse DDNS Domains Needed - - - - - - - # - DDNS Domain Name - DNS Servers - - - - - 1. - 2.0.192.in-addr.arpa. - 172.16.1.5, 172.16.2.5 - - - 2. - 1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa. - 3001:1::50 - - - 3. - 0.182.in-addr.arpa. - 172.16.2.5 - - - -
- 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. - - - These Reverse DDNS Domains are specified as follows: + + + Similarly, we need to construct the three reverse DDNS Domains: + + Reverse DDNS Domains Needed + + + + + + + # + DDNS Domain Name + DNS Servers + + + + + 1. + 2.0.192.in-addr.arpa. + 172.16.1.5, 172.16.2.5 + + + 2. + 1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa. + 3001:1::50 + + + 3. + 0.182.in-addr.arpa. + 172.16.2.5 + + + +
+ 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. + + + These Reverse DDNS Domains are specified as follows: "DhcpDdns": { "reverse-ddns": { - "ddns-domains": [ - { - "name": "2.0.192.in-addr.arpa.", - "key-name": "", - "dns-servers": [ - { "ip-address": "172.16.1.5" }, - { "ip-address": "172.16.2.5" } - ] - } - { - "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", - "key-name": "", - "dns-servers": [ - { "ip-address": "2001:db8::1" } - ] - } - { - "name": "0.192.in-addr.arpa.", - "key-name": "", - "dns-servers": [ - { "ip-address": "172.16.2.5" } - ] - } - ] + "ddns-domains": [ + { + "name": "2.0.192.in-addr.arpa.", + "key-name": "", + "dns-servers": [ + { "ip-address": "172.16.1.5" }, + { "ip-address": "172.16.2.5" } + ] + } + { + "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.", + "key-name": "", + "dns-servers": [ + { "ip-address": "2001:db8::1" } + ] + } + { + "name": "0.192.in-addr.arpa.", + "key-name": "", + "dns-servers": [ + { "ip-address": "172.16.2.5" } + ] + } + ] } } - -
+ +
DHCP-DDNS Server Limitations The following are the current limitations of the DHCP-DDNS Server. - - - 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. - - + + + 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. + +
diff --git a/src/bin/agent/kea-ctrl-agent.xml b/src/bin/agent/kea-ctrl-agent.xml index 492a6e693f..6fff18e0f9 100644 --- a/src/bin/agent/kea-ctrl-agent.xml +++ b/src/bin/agent/kea-ctrl-agent.xml @@ -52,7 +52,8 @@ - + + @@ -115,6 +116,16 @@ + + + + Check the syntax of the configuration file and report the + first error if any. Note that not all parameters are + completely checked, in particular, service and client + sockets are not opened, and hook libraries are not loaded. + + + diff --git a/src/bin/d2/kea-dhcp-ddns.xml b/src/bin/d2/kea-dhcp-ddns.xml index 9974227256..4eaa2d70b4 100644 --- a/src/bin/d2/kea-dhcp-ddns.xml +++ b/src/bin/d2/kea-dhcp-ddns.xml @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + + @@ -105,21 +105,21 @@ - - + - Configuration file including the configuration for DHCP-DDNS server. - It may also contain configuration entries for other Kea services. + Check the syntax of the configuration file and report the + first error if any. Note that not all parameters are + completely checked, in particular, service socket is + not opened. diff --git a/src/bin/d2/main.cc b/src/bin/d2/main.cc index a1299bdc41..7a077fdb60 100644 --- a/src/bin/d2/main.cc +++ b/src/bin/d2/main.cc @@ -1,4 +1,4 @@ -// Copyright (C) 2013-2016 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2013-2017 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this diff --git a/src/lib/process/d_controller.cc b/src/lib/process/d_controller.cc index 2d63197351..80dd2ba2f1 100644 --- a/src/lib/process/d_controller.cc +++ b/src/lib/process/d_controller.cc @@ -150,12 +150,12 @@ void DControllerBase::parseArgs(int argc, char* argv[]) { // Iterate over the given command line options. If its a stock option - // ("s" or "v") handle it here. If its a valid custom option, then + // ("c" or "d") handle it here. If its a valid custom option, then // invoke customOption. int ch; opterr = 0; optind = 1; - std::string opts("dvVWc:" + getCustomOpts()); + std::string opts("dvVWc:t:" + getCustomOpts()); while ((ch = getopt(argc, argv, opts.c_str())) != -1) { switch (ch) { case 'd': @@ -182,12 +182,17 @@ DControllerBase::parseArgs(int argc, char* argv[]) break; case 'c': + case 't': // config file name if (optarg == NULL) { isc_throw(InvalidUsage, "configuration file name missing"); } setConfigFile(optarg); + + if (ch == 't') { + check_only_ = true; + } break; case '?': { diff --git a/src/lib/process/d_controller.h b/src/lib/process/d_controller.h index 6ba258a25a..a86be3b0ec 100644 --- a/src/lib/process/d_controller.h +++ b/src/lib/process/d_controller.h @@ -34,7 +34,7 @@ public: /// Since command line argument parsing is done as part of /// DControllerBase::launch(), it uses this exception to propagate /// version information up to main(), when command line argument -/// -v or -V is given. +/// -v, -V or -W is given. class VersionMessage : public isc::Exception { public: VersionMessage(const char* file, size_t line, const char* what) : @@ -128,7 +128,7 @@ public: /// arguments. /// /// This function can be run in "test mode". It prevents initialization - /// of D2 module logger. This is used in unit tests which initialize logger + /// of module logger. This is used in unit tests which initialize logger /// in their main function. Such a logger uses environmental variables to /// control severity, verbosity etc. /// @@ -223,10 +223,10 @@ public: /// @return an Element that contains the results of command composed /// of an integer status value and a string explanation of the outcome. /// The status value is one of the following: - /// D2::COMMAND_SUCCESS - Command executed successfully - /// D2::COMMAND_ERROR - Command is valid but suffered an operational + /// COMMAND_SUCCESS - Command executed successfully + /// COMMAND_ERROR - Command is valid but suffered an operational /// failure. - /// D2::COMMAND_INVALID - Command is not recognized as valid be either + /// COMMAND_INVALID - Command is not recognized as valid be either /// the controller or the application process. virtual isc::data::ConstElementPtr executeCommand(const std::string& command, @@ -283,10 +283,10 @@ protected: /// @return an Element that contains the results of command composed /// of an integer status value and a string explanation of the outcome. /// The status value is one of the following: - /// D2::COMMAND_SUCCESS - Command executed successfully - /// D2::COMMAND_ERROR - Command is valid but suffered an operational + /// COMMAND_SUCCESS - Command executed successfully + /// COMMAND_ERROR - Command is valid but suffered an operational /// failure. - /// D2::COMMAND_INVALID - Command is not recognized as a valid custom + /// COMMAND_INVALID - Command is not recognized as a valid custom /// controller command. virtual isc::data::ConstElementPtr customControllerCommand( const std::string& command, isc::data::ConstElementPtr args); @@ -302,7 +302,7 @@ protected: /// @brief Virtual method which returns a string containing the option /// letters for any custom command line options supported by the derivation. - /// These are added to the stock options of "c" and "v" during command + /// These are added to the stock options of "c", "d", ..., during command /// line interpretation. /// /// @return returns a string containing the custom option letters. @@ -342,6 +342,20 @@ protected: verbose_ = value; } + /// @brief Supplies whether or not check only mode is enabled. + /// + /// @return returns true if check only is enabled. + bool isCheckOnly() const { + return (check_only_); + } + + /// @brief Method for enabling or disabling check only mode. + /// + /// @param value is the new value to assign the flag. + void setCheckOnly(bool value) { + check_only_ = value; + } + /// @brief Getter for fetching the controller's IOService /// /// @return returns a pointer reference to the IOService. @@ -385,14 +399,15 @@ protected: /// list of options with those returned by getCustomOpts(), and uses /// cstdlib's getopt to loop through the command line. /// It handles stock options directly, and passes any custom options into - /// the customOption method. Currently there are only two stock options - /// -c for specifying the configuration file, and -v for verbose logging. + /// the customOption method. Currently there are only some stock options + /// -c/t for specifying the configuration file, -d for verbose logging, + /// and -v/V/W for version reports. /// /// @param argc is the number of command line arguments supplied /// @param argv is the array of string (char *) command line arguments /// /// @throw InvalidUsage when there are usage errors. - /// @throw VersionMessage if the -v or -V arguments is given. + /// @throw VersionMessage if the -v, -V or -W arguments is given. void parseArgs(int argc, char* argv[]); @@ -536,6 +551,9 @@ private: /// @brief Indicates if the verbose logging mode is enabled. bool verbose_; + /// @brief Indicates if the check only mode is enabled. + bool check_only_; + /// @brief The absolute file name of the JSON spec file. std::string spec_file_name_;