Request: UNIX socket for HTTP API

[FGasper]

It would simplify our integration with PowerDNS if the HTTP API were available via a unix/local socket rather than TCP. TCP entails firewall configuration and additional overhead, whereas a unix/local socket is much simpler.

On Linux, ideally this would also support abstract-namespace sockets (cf. man 7 unix) in order to avoid the race conditions inherent with filesystem-based sockets.

[james-stevens]

I don't work for OX, so this is just my personal opinion.

1. I basically agree

Adding unix-socket support should be relatively trivial, and the cost of running the calls up & down the TCP stack is a little unnecessary.

A unix socket is opened differently (but only slightly) from a TCP socket, but from then onwards the API is identical, on Linux anyway, so all the existing code should just work. This is my experience.

However, I would think your use case, of most API calls originating on the same host, is probably relatively niche.

2. Your firewall issue

You can mostly resolve your firewall issue by only listening on one of the 127.0.0.0/8 addresses. This is what we do.

webserver=yes
webserver-address=127.1.0.1
webserver-allow-from=127.0.0.0/8
webserver-password=Some-Key
api=yes
api-key=Other-Key

Linux is really very good about safeguarding localhost traffic on the lo interface only, and even if it wasn't, you may well have firewall rules to safeguard it anyway (we do), say like this

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -d 127.0.0.0/8 -j DROP

Our experience is that the DROP lines are never triggered, showing either nobody bothers to try that kind of attack on us, or Linux has already dropped the packets - I suspect the latter.

3. Abstract Namespace

I've never come across that before - thanks :) - I always thought using a file as a socket was unnecessary and, if the server didn't remove it at termination, you were left with an annoying problem.

[GongT]

I need this too, I'm using pdns inside docker.
If pdns support listen unix socket, then I can simply share the socket between containers.
It's super easy to setup, and will cause less bug.

Now I must set pdns as a dependency of the "controller" container, and restart both when I just want to restart pdns.

[SRv6d]

+1

[Ramalama2]

This would be amazing.

I need the socket because of: -> Don't want to run pdns-auth inside docker, because i don't want the docker Publish Proxy for pdns-auth ---> The Docker UDP Proxy is still a bit broken, i'll get a lot Truncated UDP Replyes behind Docker UDP Proxy, while native not! This is a nogo for pdns-auth inside Docker and publish port 53/udp. -> Need to run pdns-admin inside Docker Container, because of the easy updates!

With TCP API, this situation would require to open the API Port on the physical NIC, listening only on 127.0.0.1:8081 would leed to no access for pdns-admin inside docker. With listening on 0.0.0.0:8081, i would need to configure a firewall.

With Socket, i could simply passthrough as a Docker Volume to pdns-admin.

Same issue happens with dnsdist or recursor, putting them inside docker and publishing the UDP Ports, leads to Truncated messages. Same issue happens with pihole (dnsmasq) inside Docker Container with publishing ports. The truncated UDP Messages doesn't happen always, but on bigger udp replyes for sure.

Cheers :-)

[Sharaf5]

Any update on using sockets ?