Open klaus-nicat opened 1 year ago
Alternative outcome: we move the UDP path to stubDoResolve too.
A very fast workaround/fix until a clean solution:
local.sin4.sin_port = htons(32768+dns_random(28000));
Alternative outcome: we move the UDP path to stubDoResolve too.
I did the simple thing and made the port range configurable.
Moving the UDP path into stubDoResolve
would imply having a thread pool, I guess? If I misunderstood, please explain what you had in mind there :)
Moving the UDP path into
stubDoResolve
would imply having a thread pool, I guess? If I misunderstood, please explain what you had in mind there :)
It's already in a thread pool - the one holding database connections, which are not free. So a separate thread pool might be cool, but also is not easy.
However, meanwhile people solve this with LUA (which also runs in the thread holding a db connection) and they appear to be happy. So just calling stubDoResolve from the packet handler might just be fine. It would also simplify a few things, including DNSSEC.
I think, as #14591 solves my problem, we can close this one. And maybe add a new issue for #14594
And maybe add a new issue for #14594
we don't need a new issue if there's already an open PR (but it's allowed, if you want to). If the PR ends up closed, having an issue makes sense of course.
I thought we already had a separate issue, but I also can't find it at the moment. :shrug:
Short description
When PowerDNS resolves ALIAS targets in UDP mode, it uses https://github.com/PowerDNS/pdns/blob/master/pdns/dnsproxy.cc#L67 which chooses a random port and uses this for the PDNS lifetime. This works around the typical Linux ephmeral port selection and hence may cause conflicts with other local services running on high ports.
One solution would be to just let the OS select the ephmeral port, ie:
Environment