[kea-dev] Reverse DNS update

Tue May 31 11:08:56 UTC 2016

----------------------------------------
> From: tachyon at live.co.uk
> To: tmark at isc.org; kea-dev at lists.isc.org
> Subject: RE: [kea-dev] Reverse DNS update
> Date: Fri, 27 May 2016 08:55:49 +0100
>
> ________________________________
>> To: kea-dev at lists.isc.org
>> From: tmark at isc.org
>> Date: Thu, 26 May 2016 09:27:54 -0400
>> Subject: Re: [kea-dev] Reverse DNS update
>>
>> On 5/26/16 6:22 AM, tach yon wrote:
>> Hi,
>>
>> I've set up Kea 1.0.0 to serve DHCP requests and store lease
>> information in a PgSQL database. There's also a separate bind 9.10
>> server that I'm trying to push dynamic DNS updates to, but
>> unfortunately this isn't working. I'm trying to find out why, but I've
>> come across something I don't quite understand.
>>
>> This suggests to me that the entry has been successfully added to the
>> database with the fqdn_rev boolean marked as true:
>>
>>
>> address | hwaddr | client_id | valid_lifetime |
>> expire | subnet_id | fqdn_fwd | fqdn_rev | hostname
>> | state
>> -----------+----------------+------------------+----------------+------------------------+-----------+----------+----------+---------------------------+-------
>> 168566422 | \x0050569d0f1f | \x010050569d0f1f | 4000 |
>> 2016-05-26 11:04:35+01 | 1 | f | t |
>> windhcp.example.net. | 0
>>
>>
>> Showing fqdn_rev marked as true seems strange because in kea.conf I
>> have it set to update forward DNS, not reverse DNS.
>>
>> "DhcpDdns": {
>> "tsig-keys": [
>> {
>> "name": "dynkey",
>> "algorithm": "HMAC-MD5",
>> "secret": "xxx"
>> },
>> ],
>> "forward-ddns": {
>> "ddns-domains": [
>> {
>> "name": "dynamic.example.net.",
>> "key-name": "dynkey",
>> "dns-servers": [ { "ip-address": "10.12.30.7" } ]
>> },
>> ]
>> },
>> "reverse-ddns": {
>> "ddns-domains": [ ]
>> }
>> },
>>
>>
>> I also see this in the ddns log:
>>
>> 2016-05-26 09:57:55.347 DEBUG [kea-dhcp-ddns.dhcp-to-d2/94515]
>> DHCP_DDNS_REV_REQUEST_IGNORED Request ID
>> : Reverse updates are disabled, the reverse portion of request will be
>> ignored: Type: 0 (CHG_ADD)
>> Forward Change: no
>> Reverse Change: no
>> FQDN: [windhcp.dynamic.example.net.]
>> IP Address: [10.12.30.150]
>> Lease Expires On: 20160526100435
>> Lease Length: 4000
>>
>> 2016-05-26 09:57:55.348 DEBUG [kea-dhcp-ddns.dhcp-to-d2/94515]
>> DHCP_DDNS_REQUEST_DROPPED Request ID
>> : Request contains no enabled update requests and will be dropped:
>> Type: 0 (CHG_ADD)
>> Forward Change: no
>> Reverse Change: no
>> FQDN: [windhcp.dynamic.example.net.]
>> IP Address: [10.12.30.150]
>> Lease Expires On: 20160526100435
>> Lease Length: 4000
>>
>>
>> This feels like it's trying to update a reverse request despite having
>> configured it to create forward entries, unless I configured it wrong
>> :\
>>
>> If someone could please help make sense of this it would be very much
>> appreciated. Thank you in advance for your time and consideration.
>>
>> Kind regards,
>> Lewis
>>
>>
>>
>> _______________________________________________
>> kea-dev mailing list
>> kea-dev at lists.isc.org<mailto:kea-dev at lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/kea-dev
>>
>> Hello Lewis:
>>
>> The log entries you show indicate that kea-dhcp-ddns (aka D2) did not
>> find any updates that it should or could do and therefore dropped the
>> request. If it had actually attempted any updates you would have seen
>> several more entries detailing their progress (e.g.
>> DHCP_DDNS_STARTING_TRANSACTION, DHCP_DDNS_UPDATE_REQUEST_SENT,
>> DHCP_DDNS_UPDATE_RESPONSE_RECEIVED).
>>
>> The hostname shown in your database does not map to the configured
>> Forward DDNS domain you have defined. Your host, "windhcp", is in
>> "example.net.". If you peruse your log file you should see an entry for
>> DHCP_DDNS_NO_FWD_MATCH_ERROR. So either your host name needs to be
>> "windhcp.dynamic.example.net." or your forward domain needs to be
>> "example.net."
>>
>> I do not understand why the reverse flag is true. Either there is
>> simply a bug somewhere and it should not be true or at some point you
>> had reverse updates enabled for this same client and IP address and the
>> entry was made. You could look for the reverse entry with:
>>
>> dig @10.12.30.7 -x10.12.30.150
>>
>> If you have the original log file, that would be extremely helpful. It
>> would also be helpful to see the "dhcp-ddns" section for "Dhcp4".
>>
>> We also have all of our log messages explained in kea-messages.html.
>> Which should be installed next to our admin guide in
>> <prefix>/share/doc/kea. We have a link to it here
>>
>> http://kea.isc.org/docs/kea-messages.html#DHCP
>>
>> (This link appears to be a little stale, and for some reason the D2
>> messages are lumped under module "DHCP")
>>
>>
>> Thanks,
>>
>> Thomas Markwalder
>>
>> ISC Software Engineering
>
>
> Hi Thomas,
>
> Thank you for your help with this.
>
> Perhaps I
> have misunderstood; I thought Kea was supposed to take only the machine
> name part of the server's hostname (i.e. windhcp) and then combine that
> with the suffix specified in the configuration (i.e.
> dynamic.example.net), essentially overriding whatever FQDN the server
> believes it should have and ensuring it gets the correct FQDN as
> specified by Kea's configuration?
>
> Here's the defined subnet including the "dhcp-ddns" section:
>
>   "subnet4": [
>       {"subnet": "10.12.30.0/24",
>            "pools": [ { "pool": "10.12.30.150 - 10.12.30.175" } ],
>            "option-data": [ {
>                 "name": "routers",
>                 "code": 3,
>                 "space": "dhcp4",
>                 "csv-format": true,
>                 "data": "10.12.30.1"
>             } ]
>       }
>   ],
>   "dhcp-ddns": {
>     "enable-updates": true,
>     "qualifying-suffix": "dynamic.example.net."
>   }
> },
>
>
> If
> the logs would be helpful I can certainly send them over, but they are
> quite large. Is there something in particular you're looking for that I
> can narrow it down to? Or should I just copy out and send the most
> recent DHCP request / DDNS update attempt cycle in full?
>
> I tried running 'dig @10.12.30.7 -x 10.12.30.150' but the server had no answer.
>
> kea-messages.html
> looks informative, I will go through it and run some more tests this
> morning to try and figure out what's going on.
>
> Kind regards,
> Lewis
>

If anyone has suggestions for different configurations or diagnostic tests I can perform to try figure out what's wrong, please do let me know.

With thanks,
Lewis