It would be great if this crate allowed picking the IP protocol version to resolve: IPv4/IPv6/Any.
On the dual-stack system, the hyper's happy eyeball protocol kicks in, and the resulting addresses are unpredictable.

Most people will be using public_ip::addr (or one of the address family specific subvariants), which will always take the first enabled resolver, falling back to other enabled resolvers until it finds one that can complete the request.

To me, it would make more sense to shuffle the list of providers, so that the load is balanced among the different providers here.

I'd be willing to implement this, but I'd like to wait for feedback here if this is wanted and whether you have any strong opinions on how this should be implemented.

I use the resolver the basic way.
The resolver works in principal.
However the resolver fails to return an IP-address (i.e. returns None) on a different environment.

Is there a way to view what went wrong?

Environment 1: Windows 10 Pro
Environment 2: WSL2 (Ubuntu 18.04

when attempting to include public_ip = "0.2" in Cargo.toml

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::all`
  --> <Home>/.cargo/registry/src/github.com-1ecc6299db9ec823/public-ip-0.2.1/src/lib.rs:24:5
   |
24 |     rustdoc::all,
   |     ^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0710`.
error: could not compile `public-ip`

ref: https://doc.rust-lang.org/rustdoc/lints.html

More info on icanhazip.com over at https://major.io/2021/06/06/a-new-future-for-icanhazip/, it's operated by cloudflare and running on workers, so maybe it's an alternative to the http endpoints mentioned in #20?

I am hoping you can add Cloudflare as a backend DNS.

e.g. via endpoints:
ipv4: https://1.1.1.1/cdn-cgi/trace
ipv6: https://[2606:4700:4700::1111]/cdn-cgi/trace

or the raw DNS query:
ipv4: dig +short -4 txt ch whoami.cloudflare @1.1.1.1
ipv6: dig +short -6 txt ch whoami.cloudflare @2606:4700:4700::1111

Right now, when querying for a specific address family, this generates a stream of results that query any resolvers, and will potentially query an incompatible resolver, just to throw away the result because the result is incompatible. This potentially delays the result and causes unnecessary load on the backend providers side.

I'd be willing to implement this, but I'd like to wait for feedback here if this is wanted and whether you have any strong opinions on how this should be implemented.

They support querying v4 and v6 via HTTP(S), DNS, SSH, telnet(s), and STUN.

They also have a second service operated in a different datacenter, with tnedi.me.

Details on how they provide their service is available under https://api.ident.me/

I'm trying to use this library in a project using the bevy game engine. Upon running I see this error:

thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', /home/matthew/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-system-resolver-0.5.0/src/system.rs:43:9

The line I'm trying to run is:

 let public_ip = block_on(public_ip::addr()).unwrap();

This happens on all combinations of features I have tried.