[Kea-users] DDNS not triggered with DHCP6

Thomas Markwalder tmark at isc.org
Mon Nov 7 14:09:08 UTC 2016


On 11/7/16 6:59 AM, Thomas Markwalder wrote:
> On 11/6/16 4:57 PM, Leander Janssen wrote:
>>  
>> I've configured both DHCPv6 and DDNS. DHCPv6 leases are working properly, but DDNS is not triggered.
>>
>> I'm wondering if this is configuration related or some other issue?
>>
>> DHCP4 in combination with DDNS is working fine.
>>
>> The version of kea is 1.0.0
>>
>> I'm using the following configuration.
>>
>> DHCP6:  
>>
>> "dhcp-ddns": {  
>>  "enable-updates": true,
>>  "override-client-update": true,
>>  "override-no-update": true,
>>  "generated-prefix": "host",
>>  "qualifying-suffix": "home.vforge.net."
>> },
>>
>> DDNS:  
>>
>> "forward-ddns": {  
>>  "ddns-domains": [
>>   {
>>    "name": "home.vforge.net.",
>>    "key-name": "dhcp-update",
>>    "dns-servers": [
>>     { "ip-address": "192.168.10.53" },
>>     { "ip-address": "2001:610:64f:10::100:53" }
>>    ]
>>   }
>> ]
>> },
>> "reverse-ddns": {
>>  "ddns-domains": [
>>  {
>>   "name": "10.168.192.in-addr.arpa.",
>>   "key-name": "dhcp-update",
>>   "dns-servers": [ { "ip-address": "192.168.10.53" } ]
>>  },
>>  {
>>   "name": "0.1.0.0.f.4.6.0.0.1.6.0.1.0.0.2.ip6.arpa.",
>>   "key-name": "dhcp-update",
>>   "dns-servers": [ { "ip-address": "2001:610:64f:10::100:53" } ]
>>  }
>>  ]
>> }
>>
>>
>> The debug log of DHCP6 shows the following entries when a client requests an IP address:  
>>
>> 2016-11-06 22:35:51.309 DEBUG [kea-dhcp6.packets/7998] DHCP6_BUFFER_RECEIVED received buffer from fe80::3e15:c2ff:fee0:332e:546 to ff02::1:2:0 over interface eth0  
>> 2016-11-06 22:35:51.309 DEBUG [kea-dhcp6.options/7998] DHCP6_BUFFER_UNPACK parsing buffer received from fe80::3e15:c2ff:fee0:332e to ff02::1:2 over interface eth0
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.packets/7998] DHCP6_PACKET_RECEIVED duid=[00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e], tid=0x8f584e: CONFIRM (type 4) received from fe80::3e15:c2ff:fee0:332e to ff02::1:2 on interface eth0
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.packets/7998] DHCP6_QUERY_DATA duid=[00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e], tid=0x8f584e, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3e15:c2ff:fee0:332e]:546
>> msgtype=4, transid=0x8f584e
>> type=00001, len=00014: 00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> type=00003(IA_NA), len=00040: iaid=0, t1=0, t2=0,
>> options:
>> type=00005(IAADDR), len=00024: address=2001:610:64f:10:200::28, preferred-lft=0, valid-lft=0
>> type=00006, len=00004: 23(uint16) 24(uint16)
>> type=00008, len=00002: 0 (uint16)
>>
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.dhcpsrv/7998] DHCPSRV_CFGMGR_SUBNET6_IFACE selected subnet 2001:610:64f:10::/64 for packet received over interface eth0  
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.packets/7998] DHCP6_SUBNET_SELECTED duid=[00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e], tid=0x8f584e: the subnet with ID 1 was selected for client assignments
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.packets/7998] DHCP6_SUBNET_DATA duid=[00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e], tid=0x8f584e: the selected subnet details: 2001:610:64f:10::/64
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID get one host with IPv6 reservation for subnet id 1, HWADDR hwtype=1 3c:15:c2:e0:33:2e, DUID 00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ALL_HWADDR_DUID get all hosts with reservations for HWADDR hwtype=1 3c:15:c2:e0:33:2e and DUID 00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=3c:15:c2:e0:33:2e
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=3c:15:c2:e0:33:2e, found 0 host(s)
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: duid=00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier duid=00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e, found 0 host(s)
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.hosts/7998] HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_NULL host not found using subnet id 1, HW address hwtype=1 3c:15:c2:e0:33:2e and DUID 00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.options/7998] DHCP6_ADD_GLOBAL_STATUS_CODE duid=[00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e], tid=0x8f584e: adding Status Code to DHCPv6 packet: Success(0) "All addresses are on-link"
>> 2016-11-06 22:35:51.310 DEBUG [kea-dhcp6.packets/7998] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3e15:c2ff:fee0:332e]:546
>> msgtype=7, transid=0x8f584e
>> type=00001, len=00014: 00:01:00:01:1b:4d:82:bd:3c:15:c2:e0:33:2e
>> type=00002, len=00014: 00:01:00:01:1f:af:b0:6b:00:50:56:85:f1:08
>> type=00013, len=00027: Success(0) "All addresses are on-link"
>> type=00023, len=00032: 2001:610:64f:10::100:0 2001:4860:4860::8888
>> type=00024, len=00017: "home.vforge.net." (fqdn)
>>
>> 2016-11-06 22:35:51.311 DEBUG [kea-dhcp6.packets/7998] DHCP6_BUFFER_WAIT waiting for next DHCPv6 packet with timeout 1000 ms  
>> 2016-11-06 22:35:52.061 DEBUG [kea-dhcp6.dhcpsrv/7998] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.alloc-engine/7998] ALLOC_ENGINE_V6_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.dhcpsrv/7998] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.alloc-engine/7998] ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.036 ms
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.alloc-engine/7998] ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.dhcpsrv/7998] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.packets/7998] DHCP6_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is 1000)
>> 2016-11-06 22:35:52.062 DEBUG [kea-dhcp6.packets/7998] DHCP6_BUFFER_WAIT waiting for next DHCPv6 packet with timeout 1000 ms
>>
>> Startup log of DHCP6:
>>
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.054 INFO  [kea-dhcp6.dhcp6/7998] DHCP6_STARTING Kea DHCPv6 server version 1.0.0 starting
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.058 INFO  [kea-dhcp6.dhcpsrv/7998] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.059 INFO  [kea-dhcp6.dhcp6/7998] DHCP6_CONFIG_NEW_SUBNET a new subnet has been added to configuration: 2001:610:64f:10::/64 with params t1=1000, t2=2000, preferred-lifetime=3000, valid-lifetime=4000, rapid-commit is disabled
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.060 INFO  [kea-dhcp6.dhcp6/7998] DHCP6_CONFIG_NEW_SUBNET a new subnet has been added to configuration: 2001:610:64f:99::/64 with params t1=1000, t2=2000, preferred-lifetime=3000, valid-lifetime=4000, rapid-commit is disabled
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.060 INFO  [kea-dhcp6.dhcpsrv/7998] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=1800 name=/var/lib/kea/kea-leases6.csv persist=true type=memfile universe=6
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.060 INFO  [kea-dhcp6.dhcpsrv/7998] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.061 INFO  [kea-dhcp6.dhcpsrv/7998] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 1800 sec
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.061 INFO  [kea-dhcp6.dhcp6/7998] DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: added IPv6 subnets: 2; DDNS: enabled
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.061 INFO  [kea-dhcp6.dhcp6/7998] DHCP6_USING_SERVERID server is using server-id 00:01:00:01:1f:af:b0:6b:00:50:56:85:f1:08 and stores in the file /var/lib/kea/kea-dhcp6-serverid
>> Nov  6 22:35:42 heimdall kea-dhcp6[7998]: 2016-11-06 22:35:42.061 INFO  [kea-dhcp6.dhcpsrv/7998] DHCPSRV_DHCP_DDNS_SENDER_STARTED NameChangeRequest sender has been started: enable_updates: yes, server_ip: 127.0.0.1, server_port: 53001, sender_ip: 0.0.0.0, sender_port: 0, max_queue_size: 1024, ncr_protocol: 0, ncr_format: 0, always_include_fqdn: no, override_no_update: yes, override_client_update: yes, replace_client_name: no, generated_prefix: [host], qualifying_suffix: [home.vforge.net.]
>>
>> --  
>> Kind Regards,
>>
>> Leander Janssen
>>
>>
>> _______________________________________________
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>
> Hello Leander:
>
> From examining the logs, my first guess would be that your DHCPv6
> client is not including the FQDN option it the it's request.  The
> default behavior is not to do DDNS updates unless the client sends the
> FQDN option in the REQUEST. You can alter the rules through the use of
> the "replace-client-name" parameter as described in the Kea Admin guide:
>
>
>         8.2.19.3. kea-dhcp6 Name Generation for DDNS Update Requests
>
> Each NameChangeRequest must of course include the fully qualified
> domain name whose DNS entries are to be affected. kea-dhcp6 can be
> configured to supply a portion or all of that name based upon what it
> receives from the client.
>
> The default rules for constructing the FQDN that will be used for DNS
> entries are:
>
> 1.
>
>     If the REQUEST contains the client FQDN option, the candidate name
>     is taken from there.
>
> 2.
>
>     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.
>
> 3.
>
>     If the candidate name provided is empty, generate an FQDN using a
>     configurable prefix and suffix.
>
> 4.
>
>     If the client provided neither option, then no DNS action will be
>     taken.
>
> These rules can amended by setting the *replace-client-name* parameter
> which provides the following modes of behavior:
>
>  *
>
>     *never* - Use the name the client sent. If the client sent no
>     name, do not generate one. This is the default mode.
>
>  *
>
>     *always* - Replace the name the client sent. If the client sent no
>     name, generate one for the client.
>
>  *
>
>     *when-present* - Replace the name the client sent. If the client
>     sent no name, do not generate one.
>
>  *
>
>     *when-not-present* - Use the name the client sent. If the client
>     sent no name, generate one for the client.
>
>
>
> You would need to set it to either "always" or "when-not-present".   I
> would start there.  If you still have issues let us know.
>
>
> Thanks
>
>
> Thomas Markwalder
>
> ISC Software Engineering
>
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

Hello Leander:


I just realized that you will need to upgrade to Kea 1.1.0 in order to
use "replace-client-name" as described above.  We extended that
parameter in 1.1.0 to address situations where clients do not send
FQDNs.  Prior to 1.1.0, this parameter was boolean.  Sorry for any
confusion.


Thomas Markwalder

ISC Software Engineering

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161107/3fa08f12/attachment.htm>


More information about the Kea-users mailing list