[Pdns-users] 3.4-rc1 with ddns, tsig and bind's allow-update-forwarding

[Martin Chandler]

Hi Ruben,

Thank you very much for all your help.

I tried your branch, and while the dynamic records get inserted, for 
some reason dhcpd still logs a tsig verify failure at the end of the 
transaction.
Perhaps as a result, when DHCPRELEASE is sent, the records are not deleted.

Here is the log:
Aug 28 09:36:50 ddnstest1 dhcpd: DHCPDISCOVER from 52:54:00:41:5f:23 via 
eth1
Aug 28 09:36:51 ddnstest1 dhcpd: DHCPOFFER on 172.16.100.34 to 
52:54:00:41:5f:23 (client-ubuntu) via eth1
Aug 28 09:36:51 ddnstest1 named[1034]: client 127.0.0.1#30418/key 
ddns_update: signer "ddns_update" approved
Aug 28 09:36:51 ddnstest1 named[1034]: client 127.0.0.1#30418/key 
ddns_update: forwarding update for zone 'example.com/IN'
Aug 28 09:36:51 ddnstest1 pdns[10041]: TCP Remote 127.0.0.1 wants 
'example.com|SOA', do = 0, bufsize = 512: packetcache MISS
Aug 28 09:36:51 ddnstest1 pdns[10041]: Query: select algorithm, secret 
from tsigkeys where name=E'ddns_update'
Aug 28 09:36:51 ddnstest1 pdns[10041]: UPDATE (19329) from 127.0.0.1 for 
example.com: Processing started.
:
lots of query logs for inserting the records
:
Aug 28 09:36:51 ddnstest1 pdns[10041]: UPDATE (19329) from 127.0.0.1 for 
example.com: Update completed, 3 changed records committed.
Aug 28 09:36:51 ddnstest1 named[1034]: zone example.com/IN: forwarded 
dynamic update: master 127.0.0.1#54 returned: NOERROR
Aug 28 09:36:51 ddnstest1 dhcpd: DHCPREQUEST for 172.16.100.34 
(172.16.100.5) from 52:54:00:41:5f:23 (client-ubuntu) via eth1
Aug 28 09:36:51 ddnstest1 dhcpd: DHCPACK on 172.16.100.34 to 
52:54:00:41:5f:23 (client-ubuntu) via eth1
Aug 28 09:36:51 ddnstest1 dhcpd: Unable to add forward map from 
client-ubuntu.example.com to 172.16.100.34: tsig verify failure

:
Aug 28 09:37:58 ddnstest1 dhcpd: DHCPRELEASE of 172.16.100.34 from 
52:54:00:41:5f:23 (client-ubuntu) via eth1 (found)

no further logs, and the dynamic records are not deleted.

One other small issue:
I notice that to increase the serial number in the SOA, PDNS is deleting 
and then inserting a new SOA record with the updated serial.
In a separate installation I have a schema that holds additional 
information in the records table, and that information would be lost.
Is there a reason for delete/insert instead of update?

Regards,
Martin


(2014年08月27日 22:20), Ruben d'Arco wrote:
> Hi Martin,
>
> I've (with some help) fixed the bug.
> I currently have the code here https://github.com/cyclops1982/pdns/tree/tsigforward
> Could you build and try that version and see if it works for you?
>
> Regards,
> 	Ruben
>
>
> On Tue, Aug 26, 2014 at 09:36:57AM +0200, Ruben d'Arco wrote:
>> Hi Martin,
>>
>> No worries. PDNS is not my work, just hobby so i have to squeeze it in between all kinds of stuff :-)
>>
>> I am able to reproduce the issue locally now, which is already wonderful as that gives me options to debug it further.
>>
>> When a update message is forwarded, the message ID is rewritten (as per rfc2136). I think PDNS validates the message with that new ID, and it might need to do it with the old ID. I still need to figure out what is correct here. The old ID is in the message somewhere together with the TSIG record. I need to try and implement a fix like that to validate if this really is the case.
>>
>> So, we're moving forward and i hope i can give you a patched PDNS later this week.
>>
>> Regards,
>> 	Ruben
>>
>>
>> On Tue, Aug 26, 2014 at 03:57:31PM +0900, Martin Chandler wrote:
>>> Hi Ruben,
>>>
>>> Sorry to keep bothering you on this, but I notice that dhcpd sends
>>> the original update request via UDP, but bind forwards the request
>>> via TCP.
>>>
>>> Could it be that there is some difference in the way PDNS is
>>> handling TCP packets over UDP packets, and somehow mis-reading the
>>> data that BIND is sending?
>>>
>>> That would possible explain why setting the dhcp server to talk
>>> straight to PDNS works, because it would be sending the expected UDP
>>> packet, but forwarding over TCP fails.
>>>
>>> btw, I also tried setting up a CentOS 6.5 server:
>>> BIND 9.8.2
>>> DHCPD 4.1.1
>>> PDNS 3.4-rc1
>>>
>>> but get the same results (i.e. unsuccessful).
>>>
>>> Thanks,
>>> Martin
>>
>> _______________________________________________
>> Pdns-users mailing list
>> Pdns-users at mailman.powerdns.com
>> http://mailman.powerdns.com/mailman/listinfo/pdns-users