Total Pageviews

Sunday 14 January 2018

trust-dns,一个基于rust的支持 DNS over TLS 的dns客户端程序/服务器程序


A Rust based DNS client and server, built to be safe and secure from the ground up.
This repo consists of multiple crates:
Library Status Description
Proto trust-dns-proto Raw DNS library, exposes an unstable API and only for use by the other Trust-DNS libraries, not intended for end-user use.
Client trust-dns Used for sending query, update, and notify messages directly to a DNS server.
Server trust-dns-server Use to host DNS records, this also has a named binary for running in a daemon form.
Resolver trust-dns-resolver Utilizes the client library to perform DNS resolution. Can be used in place of the standard OS resolution facilities.
Rustls trust-dns-rustls Implementation of DNS over TLS protocol using the rustls and ring libraries.
NativeTls trust-dns-native-tls Implementation of DNS over TLS protocol using the Host OS' provided default TLS libraries
OpenSsl trust-dns-openssl Implementation of DNS over TLS protocol using OpenSSL

Goals

  • Build a safe and secure DNS server and client with modern features.
  • No panics, all code is guarded
  • Use only safe Rust, and avoid all panics with proper Error handling
  • Use only stable Rust
  • Protect against DDOS attacks (to a degree)
  • Support options for Global Load Balancing functions
  • Make it dead simple to operate

Status:

Client

Using the ClientFuture is safe. ClientFuture 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 ClientFuture. If this is an inconvenience, I may add a convenience wrapper around ClientFuture that would match the old Client; if this is something you would like to see, please file an issue.

Unique client side implementations

These are standards supported by the DNS protocol. The client implements them as high level interfaces, which is a bit more rare.
Feature Description
SecureSyncClient DNSSec validation
create atomic create of a record, with authenticated request
append verify existence of a record and append to it
compare_and_swap atomic (depends on server) compare and swap
delete_by_rdata delete a specific record
delete_rrset delete an entire record set
delete_all delete all records sets with a given name
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 ClientFuture 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. There currently is no way to limit TCP and AXFR operations, so it is still not recommended to put into production as TCP can be used to DOS the service. Master file parsing is complete and supported. There is currently no forking option, and the server is not yet threaded (although it is implemented with async IO, so threading may not be a huge benefit). There is still a lot of work to do before a server can be trusted with this externally. Running it behind a firewall on a private network would be safe.
Zone signing support is complete, to insert a key store a pem encoded rsa file in the same directory as the initial zone file with the .key suffix. Note: this must be only readable by the current user. If one is not present one will be created and written to the correct location. This also acts as the initial key for dynamic update SIG(0) validation. To get the public key, the DNSKEY record for the zone can be queried. This is needed to provide to other upstream servers to create the DS key. Dynamic DNS is also complete, if enabled, a journal file will be stored next to the zone file with the jrnl suffix. Note: if the key is changed or updated, it is currently the operators responsibility to remove the only public key from the zone, this allows for the DNSKEY to exist for some unspecified period of time during key rotation. Rotating the key currently is not available online and requires a restart of the server process.

DNS over TLS 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. 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.

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.

RFC's implemented

Basic operations

Update operations

Secure DNS operations

  • RFC 3007: Secure Dynamic Update
  • RFC 4034: DNSSEC Resource Records
  • RFC 4035: Protocol Modifications for DNSSEC
  • RFC 4509: SHA-256 in DNSSEC Delegation Signer
  • RFC 5702: SHA-2 Algorithms with RSA in DNSKEY and RRSIG for DNSSEC
  • RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
  • RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
  • RFC 6840: Clarifications and Implementation Notes for DNSSEC
  • RFC 6844: DNS Certification Authority Authorization Resource Record
  • RFC 6944: DNSKEY Algorithm Implementation Status
  • RFC 6975: Signaling Cryptographic Algorithm Understanding
  • RFC 7858: DNS over TLS

RFC's in progress or not yet implemented

Basic operations

  • RFC 2317: Classless IN-ADDR.ARPA delegation

Update operations

Secure DNS operations

  • RFC 5155: DNSSEC Hashed Authenticated Denial of Existence
  • DNSCrypt: Trusted DNS queries
  • S/MIME: Domain Names For S/MIME

Usage

This assumes that you have Rust stable installed. These presume that the trust-dns repos have already been synced to the local system:
$ git clone https://github.com/bluejekyll/trust-dns.git
$ cd trust-dns

Prerequisites

  • openssl development libraries (optional in client, min version 1.0.2)
  • sqlite3 development libraries (server only)

Mac OS X: using homebrew

  $ brew install openssl
  $ brew install sqlite
  $ export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
  $ export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib

Debian-based (includes Ubuntu & Raspbian): using apt-get

  # note for openssl that a minimum version of 1.0.2 is required for TLS, 
  #  if this is an issue, TLS can be disabled (on the client), see below.
  $ apt-get install openssl
  $ apt-get install libssl-dev
  $ apt-get install libsqlite3-dev

Testing

  • Unit tests
    These are good for running on local systems. They will create sockets for local tests, but will not attempt to access remote systems. Tests can also be run from the crate directory, i.e. client or server and cargo test
  $ scripts/run_tests.sh
  • Functional/Integration tests
    These will try to use some local system tools for compatibility testing, and also make some remote requests to verify compatibility with other DNS systems. These can not currently be run on Travis for example.
  $ scripts/run_tests.sh -- --ignored
  • Benchmarks
    Waiting on benchmarks to stabilize in mainline Rust.

Building

  • Production build, first change directories into either the crate directory, client or server
  $ cargo build --release

Running

Warning: Trust-DNS is still under development, running in production is not recommended. The server is currently only single-threaded, it is non-blocking so this should allow it to work with most internal loads.
  • Verify the version
  $ server/target/release/named --version
  • Get help
  $ server/target/release/named --help

Using as a dependency

The Client has a few features which can be disabled for different reasons when embedding in other software.
  • dnssec-openssl default It is a default feature, so default-features will need to be set to false (this will disable all other default features in trust-dns). Until there are other crypto libraries supported, this will also disable DNSSec validation. The functions will still exist, but will always return errors on validation. The below example line will disable all default features and enable OpenSSL, remove "openssl" to remove the dependency on OpenSSL.
  • dnssec-ring Ring support can be used for RSA and ED25519 DNSSec validation.
[dependencies]
  ...
trust-dns = { version = "*", default-features = false, features = ["dnssec-openssl"] }

FAQ

  • Why are you building another DNS server?
    Because of all the security advisories out there for BIND. Using Rust semantics it should be possible to develop a high performance and safe DNS Server that is more resilient to attacks.
 from https://github.com/bluejekyll/trust-dns
----------------------

我的补充说明:
在vps上。
git clone https://github.com/bluejekyll/trust-dns
cd trust-dns
rustup update
(记得一定要先更新一下cargo的版本 ,才去运行cargo build --release
cargo build --release

the exec file named will appear in target/release/

在mac上。
rustup update
cargo version
shows:
cargo 1.39.0-nightly (22f7dd049 2019-08-27)
yudeMacBook-Air:trust-dns brite$ sudo cargo build --release
shows:
...
Finished release [optimized] target(s) in 50m 17s
(the exec file named will appear in target/release/)
cd target/release/

./named -h
it shows:
OPTIONS:
    -c, --config               Path to configuration file [default: /etc/named.toml]
        --https-port     Listening port for DNS over HTTPS queries, overrides any value in config file
    -p, --port                 Listening port for DNS queries, overrides any value in config file
        --tls-port         Listening port for DNS over TLS queries, overrides any value in config file
    -z, --zonedir

              Path to the root directory for all zone files, see also config toml

参考:https://github.com/bluejekyll/trust-dns/issues/826
---------

支持 DNS over TLS 的公共 DNS 服务器都在欧美,非常少并且慢.DNS Privacy 项目 (https://dnsprivacy.org/wiki/) 提供的 DNS 服务器也都在荷兰,也很慢。
这个项目https://github.com/bluejekyll/trust-dns支持自建 DNS over TLS 的 DNS 服务器.