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

Happy Eyeballs v2 would need separate address reports #6

Open
pemensik opened this issue Jun 10, 2023 · 1 comment
Open

Happy Eyeballs v2 would need separate address reports #6

pemensik opened this issue Jun 10, 2023 · 1 comment

Comments

@pemensik
Copy link
Contributor

I know this project is not exactly alive, but I will drop few ideas here anyway. I hope I will eventually find time to implement some improvements.

Found there is Happy eyeballs version 2 RFC:
https://www.rfc-editor.org/rfc/rfc8305#section-3

That suggests the application would get addresses as soon as it were received. Not waiting for finish of both separate A and AAAA queries to finish, but instead start connecting right after first family response were received. Current getaddrinfo() does not allow that and I doubt it is fixable without significant API change.

I had a short presentation on Fosdem 2023 on related topic: https://fosdem.org/2023/schedule/event/dns_why_resolving_two_names_in_a_gui_program_is_hard/

Because the same problem is both with dns and mdns, I think it would make sense to implement non-final address event in getaddrinfo() successor. Of course these need to be asynchronous callbacks.

If AF_UNSPEC were used and it caused two separate queries, the API should allow to report partial address results when it arrives. It should report final version when both queries receive answer or the other one will timeout. Indicated by some bit that this is final response.

@pemensik
Copy link
Contributor Author

I think https://github.com/NLnetLabs/connectbyname already tries to solve that. The problem I have with that implementations is it depends on getdns, which drags in unbound-libs on Fedora. Which depends on openssl. I think implementation with very minimal dependencies should offer basic asynchronous name resolution and eventual TLS channel setup should be built on top, not fixed to single crypto library.

Also that implementation ignores /etc/hosts, mdns or other alternative plugins for name resolution. It is just DNS only, which I think is not good general purpose replacement.

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

1 participant