use dns-client >= 4.0.0 in mirage-conduit

[hannesm]

replaces the dns resolver implementation. while at it, I found some code which I could safely remove (I tested end-to-end with canopy). see robur-coop/udns#14 for changes needed in udns

[hannesm]

//cc @dinosaure @cfcs turns out most of resolver_mirage is not used (i tried cohttp-mirage, irmin-mirage and git-mirage as revdeps), and was safe to remove :D

[dinosaure]

Agree with this PR

[hannesm]

oh, and there's actually a resolver API at https://roburio.github.io/udns/doc/udns-mirage-client/Udns_mirage_client/Make/index.html FWIW

this PR requires a udns release. furthermore, it modifies the semantics. instead of requesting 8.8.8.8 via udp, 91.239.100.100 is requested via tcp. also, udns is slightly more picky about domain names..

[dinosaure]

I noticed these behaviors about tuyau where ocaml-uri is less paranoid but I prefer it (which mostly follow RFC) than before. My only concern is about the default resolver where 92.239.100.100 is a part of udns's internals and, from the patch, it's not clear that we use it now.

I don't know if it's possible to let end-user to specify a default resolver in udns and notice 92.239.100.100 statically here.

[hannesm]

@dinosaure in Mirage_impl_resolver we already support ~ns ~ns_port labeled optional arguments, which are threaded to Udns. since the udns client is the library that needs a nameserver, I'm ok with it having a hardcoded (well, actually better would be multiple) recursive resolver.

[hcarty]

What does 91.239.100.100 map to?

[hannesm]

@hcarty anycast.censurfridns.dk, see https://blog.uncensoreddns.org/

[hcarty]

@hannesm Thanks!

[hannesm]

I especially would like to know whether the module type S (and the Make functor), removed in this PR, is used by someone somewhere (I tried reverse dependencies of mirage-conduit -- namely cohttp-mirage, git-mirage, and irmin-mirage -- they all don't use it)!? (it was introduced 4 years ago in f16721c, but to me it looks like nobody is using the plain Make anymore, and nobody ever used S)!?

[avsm]

The only one i can think of that might be using it is https://github.com/moby/vpnkit, cc @djs55

[djs55]

I had a quick look -- there's no use of conduit in vpnkit. So feel free to delete module type S and Make with a clear conscience!

[hannesm]

thanks! I still have to release udns, but this is likely to happen very soon now :)

[avsm]

I am massively looking forward to switching away from the venerable ocaml-dns :-)

[hannesm]

@avsm yes, i hope https://github.com/roburio/udns/compare/next is my last rewrite before an initial release

[hannesm]

this PR has been revised to the revised API of dns-mirage-client (taking the random device as functor argument) -- also the ns and ns_port are now (mirage/mirage#996) parameters (configuration time and runtime) -- thus I think all the issues have been addressed, and this is good to go and being released once dns is released (tomorrow!)

since I've not much clue about conduit releases, is it viable to merge, tag, and release only mirage-conduit (with version 4.0.0)? or how is the tooling to release conduit* as y.z and mirage-conduit as a different version (since they started off differently)!?

[hannesm]

ok, this was a bit more involved than anticipated. I took the opportunity (since there's anyways a split universe between those who use dns-1.y and dns-4.y) to rename mirage-conduit to conduit-mirage here -- this allows us to reset the version numbers for conduit-mirage as well (and start e.g. at 1.5.1, where other conduit packages are at -- no more manual messing around for a release).

this in addition adds a travis job which compiles conduit-mirage. if this is acceptable, please say so (or merge and release directly -- conduit-mirage is not yet used by anyone). once this is in opam, I'm happy to adjust other packages (most of which, since the API / module have not changed, may even just need a depends: ("mirage-conduit" | "conduit-mirage"), i.e. work with either old or new package names! :)

as a side-effect this fixes #178 then!

[hannesm]

the main argument from #231 is not valid anymore, since the dominant naming is now YY-mirage (as can be seen on the dependencies onto mirage-conduit http://opam.ocaml.org/packages/mirage-conduit/) for YY in {git,cohttp,irmin,resp,h2,dns}.

[hannesm]

turns out, it is a bit more work than adjusting opam files, since the references in dune need to be adjusted as well -- I'm fine PRing these changes to the projects, pls let me know what you think about the rename. I can as well revert these commits from this PR, and we can rename another time.

[hannesm]

force-pushed the mirage-conduit changes only, the rename is over in https://github.com/hannesm/ocaml-conduit/tree/rename -- feel free to PR that branch here and merge if you feel like...