update some readmes

This commit is contained in:
Benjamin Fry 2019-12-22 11:47:34 -08:00
parent b31cd9ed3d
commit dfd424734b
4 changed files with 70 additions and 21 deletions

View File

@ -38,18 +38,15 @@ This repo consists of multiple crates:
# Status:
## Resolver
The Trust-DNS Resolver is a native Rust implementation for stub resolution in Rust applications. The Resolver supports many common query patterns, all of which can be configured when creating the Resolver. It is capable of using system configuration on Unix and Windows. On Windows there is a known issue that relates to a large set of interfaces being registered for use, so might require ignoring the system configuration.
The Resolver will properly follow CNAME chains as well as SRV record lookups. There is a long term plan to make the Resolver capable of fully recursive queries, but that's not currently possible.
## Client
Using the AsyncClient is safe. AsyncClient is a brand new rewrite of the old
Client. It has all the same features as the old Client, but is written with the
wonderful futures-rs library. Please send feedback! It currently does not cache
responses, if this is a feature you'd like earlier rather than later, post a
request. The validation of DNSSec is complete including NSEC. As of now NSEC3
is broken, and I may never plan to support it. I have some alternative ideas
for private data in the zone. The old Client has been deprecated, so please
use the AsyncClient. If this is an inconvenience, I may add a convenience
wrapper around AsyncClient that would match the old Client; if this is something
you would like to see, please file an issue.
The Trust-DNS Client is intended to be used for operating against a DNS server directly. It can be used for verifying records or updating records for servers that support SIG0 and dynamic update. The Client is also capable of validating DNSSEC. As of now NSEC3 validation is not yet supported, though NSEC is. There are two interfaces that can be used, the async/await compatible AsyncClient and a blocking Client for ease of use. Today, Tokio is required for the executor Runtime.
### Unique client side implementations
@ -67,10 +64,6 @@ These are standards supported by the DNS protocol. The client implements them
| [delete_all](https://docs.rs/trust-dns/0.11.0/trust_dns/client/trait.Client.html#method.delete_all) | delete all records sets with a given name |
| [notify](https://docs.rs/trust-dns/0.11.0/trust_dns/client/trait.Client.html#method.notify) | notify server that it should reload a zone |
### DNS over TLS on the Client
DNS over TLS is supported. This is accomplished through the use of `rust-native-tls`. To use DNS over TLS with the `Client`, the `TlsClientConnection` should be used. See the `TlsClientConnectionBuilder::add_ca()` method. Similarly, to use the tokio `AsyncClient` the `TlsClientStream` should be used. ClientAuth, mTLS, is currently not supported, there are some issues still being worked on. TLS is supported for Server validation and connection privacy.
## Server
The server code is complete, the daemon supports IPv4 and IPv6, UDP and TCP.
@ -96,10 +89,18 @@ Zone signing support is complete, to insert a key store a pem encoded rsa file
key rotation. Rotating the key currently is not available online and requires
a restart of the server process.
### DNS over TLS on the Server
### DNS-over-TLS and DNS-over-HTTPS on the Server
Support of TLS on the Server is managed through a pkcs12 der file. The documentation is captured in the example test config file, [example.toml](https://github.com/bluejekyll/trust-dns/blob/master/crates/server/tests/test-data/named_test_configs/example.toml). A registered certificate to the server can be pinned to the Client with the `add_ca()` method. Alternatively, as the client uses the rust-native-tls library, it should work with certificate signed by any standard CA.
## DNS-over-TLS and DNS-over-HTTPS
DoT and DoH are supported. This is accomplished through the use of one of `native-tls`, `openssl`, or `rustls` (only `rustls` is currently supported for DoH). The Resolver requires only requires valid DoT or DoH resolvers being registered in order to be used.
To use with the `Client`, the `TlsClientConnection` or `HttpsClientConnection` should be used. Similarly, to use with the tokio `AsyncClient` the `TlsClientStream` or `HttpsClientStream` should be used. ClientAuth, mTLS, is currently not supported, there are some issues still being worked on. TLS is useful for Server authentication and connection privacy.
To enable DoT one of the features `dns-over-native-tls`, `dns-over-openssl`, or `dns-over-rustls` must be enabled, `dns-over-https-rustls` is used for DoH.
## DNSSec status
Currently the root key is hardcoded into the system. This gives validation of
@ -108,7 +109,7 @@ Currently the root key is hardcoded into the system. This gives validation of
appear to rate limit the connections, validating RRSIG records back to the root
can require a significant number of additional queries for those records.
Zones will be automatically resigned on any record updates via dynamic DNS.
Zones will be automatically resigned on any record updates via dynamic DNS. To enable DNSSEC, one of the features `dnssec-openssl` or `dnssec-rustls` must be enabled.
## RFCs implemented

View File

@ -14,6 +14,26 @@ This a named implementation for DNS zone hosting. It is capable of performing si
- ANAME resolution, for zone mapping aliass to A and AAAA records
- Additionals section generation for aliasing record types
## DNS-over-TLS and DNS-over-HTTPS
Support of TLS on the Server is managed through a pkcs12 der file. The documentation is captured in the example test config file, [example.toml](https://github.com/bluejekyll/trust-dns/blob/master/crates/server/tests/test-data/named_test_configs/example.toml). A registered certificate to the server can be pinned to the Client with the `add_ca()` method. Alternatively, as the client uses the rust-native-tls library, it should work with certificate signed by any standard CA.
DoT and DoH are supported. This is accomplished through the use of one of `native-tls`, `openssl`, or `rustls` (only `rustls` is currently supported for DoH). The Resolver requires only requires valid DoT or DoH resolvers being registered in order to be used.
To use with the `Client`, the `TlsClientConnection` or `HttpsClientConnection` should be used. Similarly, to use with the tokio `AsyncClient` the `TlsClientStream` or `HttpsClientStream` should be used. ClientAuth, mTLS, is currently not supported, there are some issues still being worked on. TLS is useful for Server authentication and connection privacy.
To enable DoT one of the features `dns-over-native-tls`, `dns-over-openssl`, or `dns-over-rustls` must be enabled, `dns-over-https-rustls` is used for DoH.
## DNSSec status
Currently the root key is hardcoded into the system. This gives validation of
DNSKEY and DS records back to the root. NSEC is implemented, but not NSEC3.
Because caching is not yet enabled, it has been noticed that some DNS servers
appear to rate limit the connections, validating RRSIG records back to the root
can require a significant number of additional queries for those records.
Zones will be automatically resigned on any record updates via dynamic DNS. To enable DNSSEC, one of the features `dnssec-openssl` or `dnssec-rustls` must be enabled.
## Future goals
- Distributed dynamic DNS updates, with consensus

View File

@ -54,6 +54,24 @@ if let &RData::A(ref ip) = answers[0].rdata() {
}
```
## DNS-over-TLS and DNS-over-HTTPS
DoT and DoH are supported. This is accomplished through the use of one of `native-tls`, `openssl`, or `rustls` (only `rustls` is currently supported for DoH).
To use with the `Client`, the `TlsClientConnection` or `HttpsClientConnection` should be used. Similarly, to use with the tokio `AsyncClient` the `TlsClientStream` or `HttpsClientStream` should be used. ClientAuth, mTLS, is currently not supported, there are some issues still being worked on. TLS is useful for Server authentication and connection privacy.
To enable DoT one of the features `dns-over-native-tls`, `dns-over-openssl`, or `dns-over-rustls` must be enabled, `dns-over-https-rustls` is used for DoH.
## DNSSec status
Currently the root key is hardcoded into the system. This gives validation of
DNSKEY and DS records back to the root. NSEC is implemented, but not NSEC3.
Because caching is not yet enabled, it has been noticed that some DNS servers
appear to rate limit the connections, validating RRSIG records back to the root
can require a significant number of additional queries for those records.
Zones will be automatically resigned on any record updates via dynamic DNS. To enable DNSSEC, one of the features `dnssec-openssl` or `dnssec-rustls` must be enabled.
## Minimum Rust Version
The current minimum rustc version for this project is `1.39`

View File

@ -16,7 +16,7 @@ This library contains implementations for IPv4 (A) and IPv6 (AAAA) resolution, m
- CNAME chain resolution
- *experimental* mDNS support (enable with `mdns` feature)
- DNS over TLS (utilizing `native-tls`, `rustls`, and `openssl`; `native-tls` or `rustls` are recommended)
- *experimental* DNS over HTTPS (currently only supports `rustls`)
- DNS over HTTPS (currently only supports `rustls`)
## Example
@ -44,13 +44,13 @@ if address.is_ipv4() {
}
```
## Enabling DNS-over-TLS and DNS-over-HTTPS
## DNS-over-TLS and DNS-over-HTTPS
**DNS-over-TLS**, DoT, the underlying implementations have been available as addon libraries to the Client and Server, but the configuration is experimental in Trust-DNS Resolver. *WARNING* The author makes no claims on the security and/or privacy guarantees of this implementation.
DoT and DoH are supported. This is accomplished through the use of one of `native-tls`, `openssl`, or `rustls` (only `rustls` is currently supported for DoH). The Resolver requires only requires valid DoT or DoH resolvers being registered in order to be used.
To use you must compile in support with one of the `dns-over-tls` features. There are three: `dns-over-openssl`, `dns-over-native-tls`, and `dns-over-rustls`. The reason for each is to make the Trust-DNS libraries flexible for different deployments, and/or security concerns. The easiest to use will generally be `dns-over-rustls` which utilizes the native Rust library (a rework of the `boringssl` project), this should compile and be usable on most ARM and x86 platforms. `dns-over-native-tls` will utilize the hosts TLS implementation where available or fallback to `openssl` where not. `dns-over-openssl` will specify that `openssl` should be used (which is a perfect fine option if required). If more than one is specified, the precedence will be in this order (i.e. only one can be used at a time) `dns-over-rustls`, `dns-over-native-tls`, and then `dns-over-openssl`. *NOTICE* the author is not responsible for any choice of library that does not meet security requirements.
To use with the `Client`, the `TlsClientConnection` or `HttpsClientConnection` should be used. Similarly, to use with the tokio `AsyncClient` the `TlsClientStream` or `HttpsClientStream` should be used. ClientAuth, mTLS, is currently not supported, there are some issues still being worked on. TLS is useful for Server authentication and connection privacy.
**DNS-over-HTTPS**, DoH, currently the only supported TLS library is `rustls`. To enable, us the feature `dns-over-https-rustls`.
To enable DoT one of the features `dns-over-native-tls`, `dns-over-openssl`, or `dns-over-rustls` must be enabled, `dns-over-https-rustls` is used for DoH.
### Example
@ -69,6 +69,16 @@ let mut resolver = Resolver::new(ResolverConfig::cloudflare_tls(), ResolverOpts:
/// see example above...
```
## DNSSec status
Currently the root key is hardcoded into the system. This gives validation of
DNSKEY and DS records back to the root. NSEC is implemented, but not NSEC3.
Because caching is not yet enabled, it has been noticed that some DNS servers
appear to rate limit the connections, validating RRSIG records back to the root
can require a significant number of additional queries for those records.
Zones will be automatically resigned on any record updates via dynamic DNS. To enable DNSSEC, one of the features `dnssec-openssl` or `dnssec-rustls` must be enabled.
## Minimum Rust Version
The current minimum rustc version for this project is `1.39`