-
Notifications
You must be signed in to change notification settings - Fork 917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ALIAS Resolver in UDP mode: rework source port selection #13039
Comments
Alternative outcome: we move the UDP path to stubDoResolve too. |
A very fast workaround/fix until a clean solution:
|
I did the simple thing and made the port range configurable. Moving the UDP path into |
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. |
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. 🤷 |
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
The text was updated successfully, but these errors were encountered: