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

future improvements and issues found in my reworks #485

Open
Luap99 opened this issue Jul 26, 2024 · 2 comments
Open

future improvements and issues found in my reworks #485

Luap99 opened this issue Jul 26, 2024 · 2 comments

Comments

@Luap99
Copy link
Member

Luap99 commented Jul 26, 2024

A list of problems or possible enhancements I found while reworking parts of aardvark-dns

  • resolv.conf is read only once and not refreshed (also there is no cache of known bad upstream servers so we always try the broken resolver making problems like DNS server fallback not working #482 much worse)
  • there is no caching of upstream dns requests
  • better error handling wrapping and message, the current message stutter a lot. We should convert everything to the new AardvarkError type and make sure the error message make sense
  • add handling of MX like docker does
  • check performance of the server and possible improvements currently we process only one tcp or udp message from the same network at the same time, i.e. if we parse a udp message we will not accept another tcp/udp message in parallel until we progressed the current message (do not include external forwarding). Maybe it is good that way, because it doesn't allow to flood the server with requests easily.
  • In general use better types that are passed around. There is a lot of random string parsing at many places that could have been just proper types.
@Luap99
Copy link
Member Author

Luap99 commented Jul 26, 2024

cc @mheon

Not sure if you care much about any of them.

@mheon
Copy link
Member

mheon commented Jul 26, 2024

I think the first bullet point is rather important, that is something we'll want to respect.

I think the rest are lower priority, save maybe performance? But we don't have data there to say that things aren't as fast as they need to be.

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

No branches or pull requests

2 participants