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

[Ruben d'Arco]

Hi Martin,

Can you share all the logging and not cut out some parts?

I've tested this with a normal nsupdate command, as that's essentially what dhcpd is doing as well.
I'll try to set that up in the same way here, but that takes a bit of time.

Regards,
	Ruben


On Thu, Aug 28, 2014 at 10:01:18AM +0900, Martin Chandler wrote:
> 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