Jay Taylor's notes
back to listing indexbluejekyll/trust-dns
[web search]client | Bfry/split client server (#68) | 12 days ago | |
scripts | moved config_tests out of the server crate | 10 days ago | |
server | moved config_tests out of the server crate | 10 days ago | |
.coveralls.yml | trying to get coveralls to work | 11 months ago | |
.editorconfig | start of resource records | a year ago | |
.gitignore | Bfry/split client server (#68) | 12 days ago | |
.travis.yml | Bfry/split client server (#68) | 12 days ago | |
CHANGELOG.md | Bfry/split client server (#68) | 12 days ago | |
Cargo.lock | Bfry/split client server (#68) | 12 days ago | |
Cargo.toml | Bfry/split client server (#68) | 12 days ago | |
Kjqmt7v.csr | RRSIG validation back to the root | 9 months ago | |
LICENSE-APACHE | Relicense to dual MIT/Apache-2.0 | 11 months ago | |
LICENSE-MIT | Relicense to dual MIT/Apache-2.0 | 11 months ago | |
README.md | moved config_tests out of the server crate | 10 days ago | |
copyright.txt | Persistence (#18) | 5 months ago |
README.md
trust-dns
A Rust based DNS client and server, built to be safe and secure from the ground up.
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.
- secure_query - 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
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.
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
- RFC 1035: Base DNS spec (partial, caching not yet supported)
- RFC 3596: IPv6
- RFC 2782: Service location
- RFC 6891: Extension Mechanisms for DNS
Update operations
- RFC 2136: Dynamic Update
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 6840: Clarifications and Implementation Notes for DNSSEC
- RFC 6944: DNSKEY Algorithm Implementation Status
RFC's in progress or not yet implemented
Basic operations
Update operations
- RFC 1995: Incremental Zone Transfer
- RFC 1996: Notify slaves of update
- Update Leases: Dynamic DNS Update Leases
- Long-Lived Queries: Notify with bells
Secure DNS operations
- RFC 5155: DNSSEC Hashed Authenticated Denial of Existence
- RFC 6975: Signaling Cryptographic Algorithm Understanding
- 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:
normal$ git clone https://github.com/bluejekyll/trust-dns.git
$ cd trust-dns
normal
Prerequisites
- openssl development libraries
- sqlite3 development libraries (server only)
Mac OS X: using homebrew
normal $ brew install openssl
$ brew install sqlite
$ export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
$ export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
normal
Debian-based (includes Ubuntu & Raspbian): using apt-get
normal $ apt-get install openssl
$ apt-get install libssl-dev
$ apt-get install libsqlite3-dev
normal
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
orserver
andcargo test
normal $ scripts/runtests.sh
normal
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.
normal $ scripts/runtests.sh -- --ignored
normal
Benchmarks
Waiting on benchmarks to stabilize in mainline Rust.
Building
- Production build, first change directories into either the crate directory,
client
orserver
normal $ cargo build --release
normal
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
normal $ server/target/release/named --version
normal
- Get help
normal $ server/target/release/named --help
normal
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.
License
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.