Using the version of pdns_server on Debian Jessie, which is apparently 3.4.1, I get the following problem. Given this query:
$ dig @localhost -p 10053 skybo.at -t SOA
With a python bottle.py backend liberally pilfered and bodged from http://jpmens.net/2015/11/03/powerdns-with-the-remote-back-end-and-dnssec/, I capture this with tcpdump:
GET /dns/lookup/skybo.at/SOA HTTP/1.1
Accept: application/json
Connection: close
Host: 127.0.0.1
User-Agent: YaHTTP v1.0
X-Remotebackend-Local: 0.0.0.0
X-Remotebackend-Real-Remote: 127.0.0.1/32
X-Remotebackend-Remote: 127.0.0.1
X-Remotebackend-Zone-Id: -1
HTTP/1.0 200 OK
Date: Sun, 08 Nov 2015 17:11:39 GMT
Server: WSGIServer/0.1 Python/2.7.9
Content-Length: 123
Content-Type: application/json
{"result": [{"content": "remote.local. jpm.remote. 1 1800 900 604800 60", "qtype": "SOA", "qname": "skybo.at", "ttl": 60}]}
This successfully returns the SOA record to dig.
With a Jetty server backend of my own devising, I get this:
GET /dns/lookup/skybo.at/SOA HTTP/1.1
Accept: application/json
Connection: close
Host: 127.0.0.1
User-Agent: YaHTTP v1.0
X-Remotebackend-Local: 0.0.0.0
X-Remotebackend-Real-Remote: 127.0.0.1/32
X-Remotebackend-Remote: 127.0.0.1
X-Remotebackend-Zone-Id: -1
HTTP/1.1 200 OK
Date: Sun, 08 Nov 2015 17:08:52 GMT
Content-Type: application/json
Connection: close
Server: Jetty(9.2.10.v20150310)
{"result": [{"content": "remote.local. jpm.remote. 1 1800 900 604800 60", "qtype": "SOA", "qname": "skybo.at", "ttl": 60}]}
This returns no results to dig. The only meaningful difference I
can see between the two is the HTTP version string in the response:
HTTP/1.0 for bottle.py, and HTTP/1.1 for Jetty. Is that actually
what's causing the problem here?