[kea-dev] Reverse DNS update

Wed Jun 1 14:36:25 UTC 2016

On 5/31/16 7:08 AM, tach yon wrote:
>
> ----------------------------------------
>> 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
>  		 	   		  
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

Hello Lewis:

If you're still having issues, please send us the log files (they're
text and should compress considerably).

Thanks

Thomas