[Pdns-users] pipe backend + slave + bad zones = bug

[Kenneth Marshall]

On Wed, Oct 29, 2008 at 05:18:43PM -0700, crayon at leechbox.net 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