-
Notifications
You must be signed in to change notification settings - Fork 43
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
dns-client-mirage udp #322
Conversation
This adds support for either all udp or all tcp|tls resolvers. At a later stage, we can of course support mixed sets of resolvers (especially with the previous commit paving this path).
…e.connect This avoids the need to unmarshal the arguments for a Dns_stub.t instantiation, and makes the surface more uniform.
similar to qubes-mirage-firewall (thanks @palainp), at initialization time a single udp_port is reserved as last resort. In general, the UDP source port is randomized, and UDP.listen/unlisten are executed on that port (which is as well registered / unregistered). If the port allocation fails, the last_udp_port is used, which is always listened to.
@reynir if you could take a look at this, that'd be great :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little concerned that generate_udp_port
doesn't check that nothing is listening on the generated port. The interface of UDP.listen
always replaces an existing listener. An application that uses DNS and listens on UDP may eventually break because a dns lookup triggered generate_udp_port
to generate the application port. However, with the current interface I can't see how we can do better.
Co-authored-by: Reynir Björnsson <reynir@reynir.dk>
Co-authored-by: Reynir Björnsson <reynir@reynir.dk>
…gth was received (as reviewed by @reynir)
thanks for your review -- I addressed your comments :) |
the interface of UDP.S with listen and unlisten is not optimal, indeed -- and should be enhanced -- maybe as simple as providing a |
previously, the source port of the remote (usually 53) was checked against our source port (some random ephemeral), leading to no accepted reply. the mirage udp interface does not provide the destination port in the callback (report as mirage/mirage-tcpip#497).
…er, dns-mirage, dns-client, dns-cli and dns-certify (6.4.0) CHANGES: * dns-client: demote log level of response to debug (mirage/ocaml-dns#317 @hannesm) * dns-client: use DNS-over-TLS for uncensoreddns.org only (mirage/ocaml-dns#320 @hannesm) * API: dns-client: connect returns the protocol (UDP/TCP), allowing mixed UDP and TCP namerservers being used (mirage/ocaml-dns#322 @hannesm) * dns-client-mirage: allow hostname in authenticator, improve error message and documentation (mirage/ocaml-dns#319 mirage/ocaml-dns#322 @hannesm) * dns-client-mirage: support UDP nameservers as "udp:<IP>" in nameserver_of_string (mirage/ocaml-dns#322 @reynir @hannesm) * API: dns-client, dns-stub, dns-resolver: ?size is now ?cache_size (mirage/ocaml-dns#322 @hannesm, suggested by @reynir)
No description provided.