On Wed, Oct 29, 2008 at 05:18:43PM -0700, [EMAIL PROTECTED] wrote: > Hi, > > I have a slave PowerDNS server which uses a pipe and gmysql backend. Two of > the zones on the master have out of zone-data that PowerDNS (rightfully) > does not like. Whenever PowerDNS tries to AXFR those domains, it also > launches a co-process, which then hangs. > > I tried this with the sample perl script here: > http://doc.powerdns.com/backends-detail.html#PIPEBACKEND to make sure it > wasn't my co-process. > > My syslog looks like this: > > Oct 29 15:47:32 c1ns2 pdns[16140]: 2 slave domains need checking > Oct 29 15:47:32 c1ns2 pdns[16140]: Domain xxx is stale, master serial 46, > our serial 0 > Oct 29 15:47:32 c1ns2 pdns[16140]: Domain yyy is stale, master serial 128, > our serial 0 > Oct 29 15:47:32 c1ns2 pdns[16140]: Backend launched with banner: > OK#011Sample backend firing up > Oct 29 15:47:32 c1ns2 pdns[16140]: gmysql Connection succesful > Oct 29 15:47:32 c1ns2 pdns[16140]: AXFR started for 'xxx', transaction > started > Oct 29 15:47:32 c1ns2 pdns[16140]: Remote 10.9.10.1 sneaked in out-of-zone > data 'ns1.example.com' during AXFR of zone 'xxx' > Oct 29 15:47:32 c1ns2 pdns[16140]: Backend launched with banner: > OK#011Sample backend firing up > Oct 29 15:47:32 c1ns2 pdns[16140]: gmysql Connection succesful > Oct 29 15:47:32 c1ns2 pdns[16140]: AXFR started for 'yyy', transaction > started > Oct 29 15:47:32 c1ns2 pdns[16140]: Remote 10.9.10.1 sneaked in out-of-zone > data 'ns1.example.com' during AXFR of zone 'yyy' > > After that I have two defunct co-processes that I need to restart PowerDNS > to get rid of. Eventually it will run out of file descriptors and give > another error. > > Obviously I should fix my zones, but this is bad behavior of PowerDNS as > well.
As you have found out, PowerDNS trusts its backend data completely and expects it to be correct. You need to fix your zones and put mechanisms in place to prevent the entry of bad data at all -- speaking as someone who had their instance brought to its I/O knees by attempted zone transfers of bad data. I would like nicer behavior, but assuming good data allows for streamlined processing and much higher performance than assuming bad data. In fact, by that reasoning PDNS should stop serving zones once incorrect data is found. I think the current behavior is better than not serving the data at all. My two cents. Ken _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
