[Pdns-dev] edns-subnet-partial-processing

[Posner, Sebastian]

Hi, 

I'm currently working on a hopefully-quick-and-not-so-dirty pipebackend to feed powerdns from an openstack nova database.


Biggest challenge: Different tenants MUST NOT see any data from within other tenants' environments.

Tenants can (by nova-db means) be separated by their IP; I can handle & cache that processing in the backend, so no (performance) issue here (yet).


Now, there are two issues arising, each of which can be subsumed as "edns-subnet-partial-processing", hence the subject. The main problem is pdns not-yet-fully-edns-subnet-processing, the sideshow would be a feature to have pdns willingly only doing one-armed-edns-subnet-processing.



Main Problem: Even with edns-subnet-processing, responses are cached and re-used beyond the scope-bits' allowance:

Querying from host A, I see the backend being called, answering authoritative with scopebits=32.
Same query from host B, I do NOT see the backend being called again, but get the same response. 
So at this point, the backend isn't even given the chance to find out which tenant the IP belongs to, leading to any tenant being able to query any cached responses from any other tenant.

Very, very ugly.

Currently using:

root at crns:~# dpkg -l | grep pdns
ii  pdns-backend-pipe                3.0-1.1ubuntu1               pipe/coprocess backend for PowerDNS
ii  pdns-server                      3.0-1.1ubuntu1               extremely powerful and versatile nameserver
root at crns:~#

Is there a timeline when pdns will start respecting scope bits, or is it already active in current codebase and I only need to get the -static- packages?



Sideshow: 

Regarding potential "information privilege escalation" by edns-subnet as shown by Florian Streibelt at Denog5*), a configuration stanza as mentioned in the subject would be great, telling pdns to ignore/discard any edns-subnet information provided by the client whilse still working with edns towards its backends (and the recursor).



Kind regards,

Sebastian
*): http://www.denog.de/meetings/denog5/pdf/08_Streibelt_DNS_clientip.pdf
--
Sebastian Posner
Unix-Systemspezialist
Deutsche Telekom AG, Products & Innovation 
"Es hat einmal einer gesagt, das geht nicht. Dann kam einer, der wusste das nicht und hat es einfach gemacht"