38 breaking releases
0.39.0 | Feb 24, 2023 |
---|---|
0.38.0 | Nov 25, 2022 |
0.37.0 | Oct 14, 2022 |
0.34.0 | Jul 5, 2022 |
0.6.0 | Mar 29, 2019 |
#2140 in Network programming
102,061 downloads per month
Used in 101 crates
(3 directly)
265KB
5K
SLoC
DNS 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:
- This fails (panics even!) if
/etc/resolv.conf
does not exist. This is the case on all versions of Android. - DNS configuration is only evaluated during startup. Runtime changes are thus ignored.
- 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
].
Dependencies
~9–18MB
~357K SLoC