As discussed on IRC; we upgraded straight from pdns 2 to pdns 3 but without changing our pipe transport's SRV record responses. This caused the following warning:
2011-08-25T04:34:58+01:00 xxx pdns: [PIPEBackend] coprocess returned incomplete MX/SRV line in data section for query for ...
2011-08-25T00:42:16+01:00 xxx pdns: Database module reported condition which prevented lookup (Format error communicating with coprocess in data section of MX/SRV record) sending out servfail
and from then after many responses from the nameserver were returning random/invalid data. It looks like the pdns reading of the responses may have been running 1 behind the question that was asked. I'm sure that very rarely most complex pipe backends may return incorrect data that needs dropping so this seems like quite a serious bug to me
This is a direct result of the changeset 2100. Given the documentation in pdnsbackend.hh:72 it seems to me that this changeset was wrong to be applied?
looks like you mean dnsbackend.hh. You may have a point there :)
I suspect the reason you applied it was to produce a nice SERVFAIL error when an AhuException was thrown from a backend (without changeset 2100 it doesn't return anything, which causes the client to time out) ?
Fixed in commit 2734, thanks.
this doesn't produce a servfail, and will leave client timeout.