# [DNS name resolution](https://github.com/libp2p/specs/blob/master/addressing/README.md#ip-and-name-resolution)
[`Transport`] for libp2p.
This crate provides the type [`GenDnsConfig`] with its instantiations
[`DnsConfig`] and `TokioDnsConfig` for use with `async-std` and `tokio`,
respectively.
A [`GenDnsConfig`] is an address-rewriting [`Transport`] wrapper around
an inner `Transport`. The composed transport behaves like the inner
transport, except that [`Transport::dial`] resolves `/dns/...`, `/dns4/...`,
`/dns6/...` and `/dnsaddr/...` components of the given `Multiaddr` through
a DNS, replacing them with the resolved protocols (typically TCP/IP).
The `async-std` feature and hence the `DnsConfig` are
enabled by default. Tokio users can furthermore opt-in
to the `tokio-dns-over-rustls` and `tokio-dns-over-https-rustls`
features. For more information about these features, please
refer to the documentation of [trust-dns-resolver].
On Unix systems, if no custom configuration is given, [trust-dns-resolver]
will try to parse the `/etc/resolv.conf` file. This approach comes with a
few caveats to be aware of:
1) This fails (panics even!) if `/etc/resolv.conf` does not exist. This is
the case on all versions of Android.
2) DNS configuration is only evaluated during startup. Runtime changes are
thus ignored.
3) DNS resolution is obviously done in process and consequently not using
any system APIs (like libc's `gethostbyname`). Again this is
problematic on platforms like Android, where there's a lot of
complexity hidden behind the system APIs.
If the implementation requires different characteristics, one should
consider providing their own implementation of [`GenDnsConfig`] or use
platform specific APIs to extract the host's DNS configuration (if possible)
and provide a custom [`ResolverConfig`].
[trust-dns-resolver]: https://docs.rs/trust-dns-resolver/latest/trust_dns_resolver/#dns-over-tls-and-dns-over-https