Add eio backend for ocaml-dns client

[bikallem]

This PR adds support for eio backend for ocaml-dns client. At the moment it only adds tcp tansport protocol support. I intend to add tls or DNS over TLS support in the future once eio support for ocaml-tls is done.

• Transport module
  • use Eio.Mutex around Queue calls ? (Not sure if it is needed yet)
• Integrate mirage-crypto-rng-eio (mirage-crypto-rng-eio: Eio backend of mirage-crypto-rng mirage-crypto#155)
• ohost executable exercising dns-client-eio package (https://github.com/bikallem/ocaml-dns/blob/eio/eio/client/ohost.ml)

This PR has a few unreleased packages dependencies:

• A new version of eio with the Mutex module (https://github.com/ocaml-multicore/eio/blob/main/lib_eio/eio.mli#L35)
• mirage-crypto-rng-eio (mirage-crypto-rng-eio: Eio backend of mirage-crypto-rng mirage-crypto#155)

At the moment eio doesn't support monotonic clock, so we still use mtime. It may be preferable to use monotonic clock support from eio once support for it lands in eio (ocaml-multicore/eio#229). However, that should be a future PR.

[talex5]

I experimented with some API changes here: https://github.com/bikallem/ocaml-dns/compare/eio...talex5:ocaml-dns:eio?expand=1

The main ones are:

1. Instead of providing a run function that just calls mirage-crypto, it's just as easy for the user call it themselves (and better if they're using crypto for other purposes).
2. There's no need to pass Client as a first-class module. We know what it is statically.
3. I moved create to create_from_env for people who want that, and added a more explicit create function so people can pass the inputs separately.

This changes the user code from:

  Eio_main.run @@ fun env -> 
  Eio.Switch.run @@ fun sw -> 
  Dns_client_eio.run env @@ fun (module Client) ->   
  let env = (env :> Dns_client_eio.env) in
  let c = Client.create (env, sw) in

to

  Eio_main.run @@ fun env -> 
  Mirage_crypto_rng_eio.run (module Mirage_crypto_rng.Fortuna) env @@ fun () ->
  Eio.Switch.run @@ fun sw -> 
  let c = Client.create_from_env ~sw env in

The needs to specify Fortuna explicitly seems a bit ugly to me, but if we don't want that then it should be fixed in mirage-crypto.

(Was the idea of the first class module to force users to initialise mirage-crypto before using the library? If so, we could probably fix this more easily by having Mirage_crypto_rng_eio.run return a token and passing that to create_from_env. Passing first-class modules around tends to get awkward.)

I'm not sure about passing resolv.conf as an Eio.Path. Possibly it should just be a function unit -> string. Also, Eio should provide some convenience types for paths (maybe Path.rw and Path.ro or something).

[bikallem]

I have rebased/updated the PR to address reviewer feedback.

(Was the idea of the first class module to force users to initialise mirage-crypto before using the library? If so, we could probably fix this more easily by having Mirage_crypto_rng_eio.run return a token and passing that to create_from_env. Passing first-class modules around tends to get awkward.)

Indeed, the idea of the API was to maintain the invariant that that consumers of the library to be able to use the module only when run under Mirage_crypto_rng_eio.run. The current API aims to maintain that invariant as well as be convenient such that one doesn't have to manually run (although they can if they so desire) the mirage crypto rng generator.

[bikallem]

Hmmm ... not sure why the ci is failing. Can anyone help?

[talex5]

It says:

lru.0.3.0: Requires ocaml >= 4.03.0 & < 5.0

[hannesm]

I'm not particularly a fan of passing first-class modules around, and don't think there's a good reason here.

I wonder what the "EIO" and "RANDOM" story is (if there's any):

• I have seen some work on mirage-crypto-rng-eio, so you can initialize and feed the Fortuna RNG;
• There has been as well some support for getrandom (but seeing the discussion of Fix getrandom(2) ocaml-multicore/eio#344 I'm not sure whether this can be safely used) -- this is exposed as "secure_random" by the "StdEnv" AFAICT (though I'm not sure what else is in this "StdEnv" and why);
• And OCaml in 5.0 has support for getentropy to feed its internal RNG (Random module).

So, what is the plan for EIO and RANDOM? How and who should decide where to take random numbers from? Is this all up to the user (and do they have a unified interface)? In DNS, we don't need cryptographically secure random, something that is not predictable is sufficient (it's used mainly for the ID anyways, to avoid spoofing of DNS packets (see https://en.wikipedia.org/wiki/DNS_spoofing if interested in details)).

[talex5]

I'm not particularly a fan of passing first-class modules around, and don't think there's a good reason here.

Indeed. I removed it in my branch (see #312 (review)).

(but seeing the discussion of ocaml-multicore/eio#344 I'm not sure whether this can be safely used)

The PR is just trying to make it harder to misuse the API. mirage-crypto-rng-eio already uses it correctly (I'm not aware of anyone using it incorrectly).

In DNS, we don't need cryptographically secure random, something that is not predictable is sufficient

I assume it's just copying the existing lwt code, which uses mirage-crypto-rng.lwt. Would be good to reduce the dependencies if it's not needed :-)

[hannesm]

Trying once more. In eio, do you have a user guide / approach to randomness?

I can see three different things going on here:

• the OCaml 5 runtime (Stdlib.Random -- which is a LXM: Better Splittable Pseudorandom Number
  Generators (and Almost as Fast); seeding is done via getentropy() if available)
• the eio providing a "secure_random" in "StdEnv", which calls out to getrandom()
• mirage-crypto-rng-eio calling out to rdrand/rdseed and getrandom/getentropy (periodic task) feeding a Fortuna RNG

Now, my questions are:

• is there a unified interface between these implementations?
• is there an eio-recommended usage of either of these?
• is the approach to have one syscall (getentropy/getrandom) each time some random is needed too expensive?

Maybe this PR here is the wrong context for these questions and considerations, but for me it is important to understand how "eio" should be used in order to avoid having to back out such changes.

[bikallem]

I have now removed the use of first class modules, the ohost.exe included in the PR don't seem to be working after latest rebase and commit, so I debugging through the issue.

EDIT: Updating the default nameservers to the same as unix client did the trick. It is working now.

[bikallem]

Needs mirleft/ocaml-tls#458 to operate correctly.

[hannesm]

So it seems we're a bit stuck on this PR:

• (a) there's some lack of a "random" story for eio (and it seems nobody is pushing that forward (no, it won't be me))
• (b) concurrent reads and writes on TLS (further discussed in tls-eio: decide on improvements needed mirleft/ocaml-tls#464, still without a solution)

How to move forward here? I unlikely have time before Q3 2023 to look into "eio", but I suspect you'd like to have "something merged" sooner. But I'm still overwhelmed by the complexity of eio and don't feel confident to grasp the semantics of what is happening where (and why concurrently etc.).

[bikallem]

@hannesm This PR is now ready. It doesn't have the TLS issue anymore.

(a) there's some lack of a "random" story for eio (and it seems nobody is pushing that forward (no, it won't be me))

The issue is separate from dns-client-eio and should be handled in the eio repo.

[dinosaure]

I take a long look about this PR and it seems that DNS request by another domain seems not an option with the current proposed design in this PR - at least, the use of "mutable" without protection makes me think there could be problems.

The reason I point to this specific usage is that it seems to me that the design of happy-eyeballs (the core package, not the happy-eyeballs-lwt) is to be a background task that maintains a "pool" of TCP/IP connections to nameservers and can resolve a DNS request from the user. It is therefore "legitimate" to think that one domain would take care of such a task in the background while the user application could interact with it from another domain to resolve domain-name.

[bikallem]

I take a long look about this PR and it seems that DNS request by another domain seems not an option with the current proposed design in this PR - at least, the use of "mutable" without protection makes me think there could be problems.

In current eio, IIUIC resource/connection/switch created in one domain can't be moved/used in another domain. Therefore, even if happy eyeballs is able to create connections, I am not sure if those connections can be used/shared in an ad-hoc manner by the domains. However, this does not preclude having multiple/parallel dns client requests via OCaml domains - which the current design offers/enables.