Skip to content
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

Open
klaus-nicat opened this issue Jul 17, 2023 · 7 comments
Open

ALIAS Resolver in UDP mode: rework source port selection #13039

klaus-nicat opened this issue Jul 17, 2023 · 7 comments
Labels

Comments

@klaus-nicat
Copy link
Contributor

  • Program: Authoritative
  • Issue type: Bug report

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:

# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768    60999

Environment

  • Operating system: Ubuntu 22.04
  • Software version: 4.8.0
  • Software source: compiled myself
@Habbie Habbie added the auth label Jul 17, 2023
@Habbie Habbie added this to the auth-4.9.0 milestone Jul 17, 2023
@Habbie
Copy link
Member

Habbie commented Jul 17, 2023

Alternative outcome: we move the UDP path to stubDoResolve too.

@klaus-nicat
Copy link
Contributor Author

A very fast workaround/fix until a clean solution:

local.sin4.sin_port = htons(32768+dns_random(28000));

@zeha
Copy link
Collaborator

zeha commented Aug 27, 2024

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 :)

@Habbie
Copy link
Member

Habbie commented Aug 27, 2024

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.

@klaus-nicat
Copy link
Contributor Author

I think, as #14591 solves my problem, we can close this one. And maybe add a new issue for #14594

@Habbie
Copy link
Member

Habbie commented Nov 26, 2024

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.

@zeha
Copy link
Collaborator

zeha commented Nov 26, 2024

I thought we already had a separate issue, but I also can't find it at the moment. 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants