bluejekyll / trust-dns Goto Github PK

View Code? Open in Web Editor NEW

3.7K 47.0 429.0 15.55 MB

A Rust based DNS client, server, and resolver

License: Other

Rust 99.40% Shell 0.21% Just 0.32% Dockerfile 0.03% Jinja 0.04%

dns dns-server dynamic-dns dns-client trust-dns rust rust-lang dnssec hickory-dns

trust-dns's Issues

Add clippy to cargo and travis builds

Added in #288

Implement draft-ietf-curdle-dnskey-eddsa (EdDSA signatures for DNS)

See draft-ietf-curdle-dnskey-eddsa.

Cleaner header construction with the field_init_shorthand feature

https://github.com/bluejekyll/trust-dns/blob/2b705dc3001c369cd75446996cc10c8f673a35c1/client/src/op/header.rs#L289-L298

The field_init_shorthand unstable feature can probably help you get a cleaner header construction.

[Server] ResponseCode for NSEC on non-existent RecordType should be NoError

It appears that NSEC records returned from other servers (google) respond with NoError rather than NxDomain. It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well.

This should be validated in the RFCs. NSEC validation on the clientside is fuctioning appropriately.

Help wanted: Create a trust-dns logo

Inconsistent build (server + macOS): ssl linkage error

This is a tracking issue for sporadic linkage errors during the server build on macOS.

= note: "cc" "-m64" "-L" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/secure_client_handle_tests-1186407fd8b3feb4.0.o" "-o" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/secure_client_handle_tests-1186407fd8b3feb4" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps" "-L" "/usr/lib" "-L" "/usr/local/opt/openssl/lib" "-L" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/build/ring-b04a0c9d4dc7829a/out/lib" "-L" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libtrust_dns_server.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libtrust_dns.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libtokio_core-7d79a0061e4987e4.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libscoped_tls-53036341d2dbbe26.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libmio-d8a3ebfe89185cdb.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libslab-69010361762af86e.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/librand-8ea7d489d4a383a0.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libopenssl-c9e7b933bde3d3a6.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libdata_encoding-8503efda09142c21.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libchrono-7342810e34d1c30d.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/librusqlite-a221a739db38f0bf.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libtime-750bfdd52feafcb7.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libbitflags-0e272044714c8076.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libtoml-1a75b37a708f335b.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/librustc_serialize-6b938435173797f7.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblazycell-d53b754addaf1d91.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnix-56d9e0b660233faa.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libring-863fd845bbadbb87.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libfutures-21d097dc8f05f683.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libbitflags-75746cc7f0e9d928.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblibsqlite3_sys-02dacca8e9891790.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblazy_static-7f1b96a3a3eb529d.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libtest-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libterm-f5a209a9.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libopenssl_sys-6c510e83c5b0b664.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liberror_chain-5731652bab0d1a8e.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libbacktrace-dffaf784d6265843.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/librustc_demangle-9f84838926c47318.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libdbghelp-72843bd5c387f78b.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libwinapi-0889532d327ff4e2.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnum-1fa4854b44bb6a54.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnum_iter-50df698bc905252c.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnum_integer-52fdddf28cd8e924.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnet2-755d3e4f87237d0e.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libcfg_if-72c1f992b13d5087.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblibc-e1db4c5f3a4f3c2f.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libuntrusted-6d5be7309ea48309.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblru_cache-5df7c7dfb11fae93.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblinked_hash_map-8bca62f90f0f04c7.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libnum_traits-92bb90166cd1857c.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libvoid-2cc31605fcb01ba1.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libgetopts-f5a209a9.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/liblog-bf16bb9a4912b11d.rlib" "/Users/benjaminfry/Development/rust/trust-dns/target/debug/deps/libkernel32-df86a08647459244.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librand-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcollections-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-f5a209a9.rlib" "/Users/benjaminfry/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-f5a209a9.rlib" "-l" "c++" "-l" "sqlite3" "-l" "sqlite3" "-l" "sqlite3" "-l" "ssl" "-l" "crypto" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m"
  = note: Undefined symbols for architecture x86_64:
  "_EVP_DigestVerifyFinal", referenced from:
      openssl::sign::Verifier::finish::h2254ce4db54d0d04 in libopenssl-c9e7b933bde3d3a6.rlib(openssl-c9e7b933bde3d3a6.0.o)
  "_EVP_DigestSignFinal", referenced from:
      openssl::sign::Signer::finish::hd5e70040d912dd63 in libopenssl-c9e7b933bde3d3a6.rlib(openssl-c9e7b933bde3d3a6.0.o)
  "_EVP_DigestVerifyInit", referenced from:
      openssl::sign::Verifier::new::hb1fc11f25f026f4f in libopenssl-c9e7b933bde3d3a6.rlib(openssl-c9e7b933bde3d3a6.0.o)
  "_EVP_DigestSignInit", referenced from:
      openssl::sign::Signer::new::h3ca1d35e4b331ef5 in libopenssl-c9e7b933bde3d3a6.rlib(openssl-c9e7b933bde3d3a6.0.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It seems to be a race condition and happens more regularly on TravisCI macOS builds, but I see it regularly on my local machine as well.

There is a linked issue on rust-openssl sfackler/rust-openssl#554

Move client integration tests back from server/ to client/ after split

To make the dependency chain sane, the integration tests for the client were moved to the server crate. This means that when running tests in the client, the integration tests for the client are not run inside the client crate. They will run in CI, etc., but this isn't a desirable dev experience.

Support ring in addition to OpenSSL

Depends on

briansmith/ring#226

[Server] Support wildcard `*.example.com` rrsets in the authority

The trust-dns server currently doesn't support wildcard records

Move all integration tests into /test directory

Should clean up the code a bit, and possibly easy the splitting of the libraries.

[Client] NSEC3 validation not correctly implemented

I don't think NSEC3 is necessarily something I want to support. I think there are probably better ways to support hiding the data in a zone. I'll post more on this in the future.

Wildcard is not handled correctly when verifying RRset

In Signer::determine_name, only one label is stripped if num_labels < fqdn_labels, but according to RFC 4035 5.3.2, we should keep only rrsig_label label. This will break if there are more than 1 label in the wildcard part of domain. Appendix C.6 describes an example of this case.

Fix mtls, client auth feature

As of now, there have been some unexpected results when working with the ClientAuth feature of rust-native-tls.

See sfackler/rust-native-tls#23 for additional details.

Support the DNSCrypt protocol

It would be nice if this server supported the DNSCrypt protocol:

https://dnscrypt.org/

cc @jedisct1

Switch out direct usage of MIO for futures.rs (server)

The server side of the Futures work

Add fuzzer for cargo-fuzz

https://github.com/rust-fuzz/cargo-fuzz

AXFR response ordering incorrect

dig reports an error with since the SOA record is not the first in the response. This will be fixed as I implement the DNSSec RFC's, where canonical ordering is a requirement.

Support for mDNS, Multicast DNS

Should be very simple extension over the UDP version.

https://tools.ietf.org/html/rfc6762

also, see IPv6 neighbor discovery and SLAAC:
https://tools.ietf.org/html/rfc4861
https://tools.ietf.org/html/rfc4862

Build fails with rust 1.12.0-beta.1

Hey,

Since I'm using a macOS beta (Sierra) on my computer, I'm forced to use 1.12.0-beta1.

The build fails with rust 1.12.0:

--- stderr
src/c_helpers.c:4:20: error: incomplete definition of type 'struct ssl_st'
    CRYPTO_add(&ssl->references, 1, CRYPTO_LOCK_SSL);
                ~~~^
/usr/local/include/openssl/crypto.h:166:39: note: expanded from macro 'CRYPTO_add'
#  define CRYPTO_add(a,b,c)       ((*(a))+=(b))
                                      ^
/usr/local/include/openssl/ossl_typ.h:181:16: note: forward declaration of 'struct ssl_st'
typedef struct ssl_st SSL;
               ^
src/c_helpers.c:8:20: error: incomplete definition of type 'struct ssl_ctx_st'
    CRYPTO_add(&ctx->references,1,CRYPTO_LOCK_SSL_CTX);
                ~~~^
/usr/local/include/openssl/crypto.h:166:39: note: expanded from macro 'CRYPTO_add'
#  define CRYPTO_add(a,b,c)       ((*(a))+=(b))
                                      ^
/usr/local/include/openssl/ossl_typ.h:182:16: note: forward declaration of 'struct ssl_ctx_st'
typedef struct ssl_ctx_st SSL_CTX;
               ^
src/c_helpers.c:12:21: error: incomplete definition of type 'struct x509_st'
    CRYPTO_add(&x509->references,1,CRYPTO_LOCK_X509);
                ~~~~^
/usr/local/include/openssl/crypto.h:166:39: note: expanded from macro 'CRYPTO_add'
#  define CRYPTO_add(a,b,c)       ((*(a))+=(b))
                                      ^
/usr/local/include/openssl/ossl_typ.h:161:16: note: forward declaration of 'struct x509_st'
typedef struct x509_st X509;
               ^
3 errors generated.
thread 'main' panicked at 'explicit panic', /a/long/cargo/path/gcc-0.3.28/src/lib.rs:840
stack backtrace:
   1:        0x10330eaf9 - std::sys::backtrace::tracing::imp::write::h6f07380f45fe1307
   2:        0x103314c60 - std::panicking::default_hook::_{{closure}}::he6993150602797ff
   3:        0x10331408a - std::panicking::default_hook::h42f7cdc1bed8dd00
   4:        0x103314656 - std::panicking::rust_panic_with_hook::hdcce59947203a4c0
   5:        0x1032f86b4 - std::panicking::begin_panic::h6e522b8d506dc874
   6:        0x10330224e - gcc::fail::h25611a6497098034
   7:        0x103302066 - gcc::run::h0d2d8efda2e0dff3
   8:        0x1032fa161 - gcc::Config::compile::he274dd27a071a635
   9:        0x1032f78e5 - build_script_build::main::hb7741c2c34a9f03d
  10:        0x10331524a - __rust_maybe_catch_panic
  11:        0x103313b5e - std::rt::lang_start::h14913182d401dec2

Edit:

Seems like CRYPTO_LOCK_SSL was removed from openssl. Seems to be an upstream issue with the openssl crate..?

Add TCP client and server

TCP is needed for AXFR and IXFR operations.

Crash when creating journal from zone with allow_update=true

2016-09-08T12:50:34.387565536+00:00 INFO named:115 loading zone file: "src/config/test/example.com.zone"`
2016-09-08T12:50:34.416164124+00:00 INFO named:129 enabling journal: "src/config/test/example.com..jrnl"
2016-09-08T12:50:34.417395558+00:00 INFO trust_dns::authority::authority:156 persisting zone to journal at SOA.serial: 199609203
thread '<main>' panicked at 'schema version mismatch, schema_up() resolves this', src/authority/persistence.rs:58
stack backtrace:
   1:     0x55d0d4c23c3f - std::sys::backtrace::tracing::imp::write::h3800f45f421043b8
   2:     0x55d0d4c2699b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0ef6c8db532f55dc
   3:     0x55d0d4c26623 - std::panicking::default_hook::hf3839060ccbb8764
   4:     0x55d0d4c1852d - std::panicking::rust_panic_with_hook::h5dd7da6bb3d06020
   5:     0x55d0d48ff737 - std::panicking::begin_panic::h4c14e704ed94392f
                        at src/libstd/panicking.rs:328
   6:     0x55d0d4979704 - trust_dns::authority::persistence::Journal::insert_record::h7a7e1920fda45865
                        at /home/apexo/ext/dev/ext/trust-dns/<std macros>:3
   7:     0x55d0d4979130 - trust_dns::authority::authority::Authority::persist_to_journal::h05d78c5d49a01b1a
                        at src/authority/authority.rs:159
   8:     0x55d0d48d76a6 - named::load_zone::hd2498ba4e50bc526
                        at src/named.rs:138
   9:     0x55d0d48e7b93 - named::main::h1c8ee60b18765fac
                        at src/named.rs:225
  10:     0x55d0d4c26268 - std::panicking::try::call::hbbf4746cba890ca7
  11:     0x55d0d4c30aeb - __rust_try
  12:     0x55d0d4c30a8e - __rust_maybe_catch_panic
  13:     0x55d0d4c25d0e - std::rt::lang_start::hbcefdc316c2fbd45
  14:     0x55d0d48f7a29 - main
  15:     0x7fa51e4992b0 - __libc_start_main
  16:     0x55d0d48d5569 - _start
  17:                0x0 - <unknown>

Reload all config on SIGHUP without requiring server to go offline

Currently the server requires a restart if keys or zone files are updated.

Switch to mio for all IO

Current std::net sockets don't have enough options

Convert all errors to use error-chain!{..}

This should simplify error handling in Trust-DNS

Split trust-dns into multiple crates

move the repo into this format over time:

trust-dns/trust-dns-core/ - record serialization, no networking, etc.
trust-dns/trust-dns-client/ - futures impl of all lookup logic, optionally compile in DNSSec, etc.
trust-dns/trust-dns-server/ - authority implementations, dependency on SQLLite here, etc.
trust-dns/trust-dns-cache/ - LRU caching layer that can wrap the client, aka resolver?

edit: I realized that changing the trust-dns crate name would orphan the existing library in crates.io. My plan right now is to maintain that name for the client library, but fork out the server library.

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](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.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 trust-dns Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

@bluejekyll

[Server] Support DNS64 (RFC 6147)

I struggle to find something for DNS64 that is not BIND.

rustc version 1.11.0 gives: private type in public interface [E0446]

Should building with rustc v 1.11.0 work? If anything newer than 1.0 is needed, I'd appreciate a note in the README.

I'm struggling:

$ git log -n1
commit 764255a8e2c07105f892a8a2498186d404678ddb
Merge: f74d52c 3520d18
Author: Benjamin Fry <[email protected]>
Date:   Thu Nov 3 00:17:52 2016 -0700

$ rustc --version
rustc 1.11.0

$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading futures v0.1.3
 Downloading rusqlite v0.7.3
 ...
   Compiling mio v0.5.1
   Compiling tokio-core v0.1.0
   Compiling docopt v0.6.86
src/client/client_future.rs:61:29: 61:41 error: private type in public interface [E0446]
src/client/client_future.rs:61              stream_handle: StreamHandle,
                                                           ^~~~~~~~~~~~
src/client/client_future.rs:61:29: 61:41 help: run `rustc --explain E0446` to see a detailed explanation
src/client/client_future.rs:80:38: 80:50 error: private type in public interface [E0446]
src/client/client_future.rs:80                       stream_handle: StreamHandle,
                                                                    ^~~~~~~~~~~~
src/client/client_future.rs:80:38: 80:50 help: run `rustc --explain E0446` to see a detailed explanation
error: aborting due to 2 previous errors
error: Could not compile `trust-dns`.

To learn more, run the command again with --verbose.

Feature request: Add support for local resource records (DNS blackholes / overrides)

It would be nice to have the ability to load lists of local resource records to override any upstream records, without having to specify a complete zone.

Our primary use case for this is being able to "blackhole" requests made to known malicious domains (e.g. malware C&C), or other domains that we wish to block (e.g. advertising content). We achieve this with Unbound by downloading and processing feeds from various threat intelligence sources (e.g. malwaredomains), and having the domains generated into local-data records which Unbound then resolves to 127.0.0.1. An example of local-data being used in this way can be seen here.

An advanced extension to this concept (which I believe is not currently achievable in Unbound) would be to match IP addresses (e.g. resolved from an A record lookup, or received from a client for PTR lookup) and block/replace the request as necessary.

Change return from query to just return RRSets?

While working on the SecureClientFuture interface, I realized that returning Message, makes it difficult to implement cacheing over the current interfaces. I'm considering having query() return only RRSets, instead of Message to make caching wrapper libraries simpler. Similarly, I'm finding that I while I like that the SecureClientFuture interface is just a wrapper of ClientFuture, I may transform the returned RRSets. I was thinking of having it strip all unverified RRSets from the response. But I haven't figured this out yet...

I like that Message is returned today, because it allows consumers to do what they want. For cacheing this isn't great though, because there technically is no Message response from a cache request, it would be built on the stack. Similarly, for a DNSSec request the question is what to do with invalid records.

For example: there may be a set of DNSKEY records that have been validated, and a set that could not be validated. This is a valid situation, IMO, as the invalid DNSKEYs may exist as new which haven't yet been signed, or old keys that are in the process of being removed. Obviously we don't want DNSKEYs used which have not been validated, so I'm considering stripping them from the Message RRSets. This seems hacky though, so I'm considering changing the return from query() entirely to make it simpler for both this case and for caching cases.

Does anyone have any strong concerns in this area?

Feature request: Add support for logging DNS queries with dnstap

It would good to have support for generating dnstap (http://dnstap.info/) logs.

As a use case, in our current configuration the pf firewall redirects all outbound DNS requests to approved internal resolvers running Unbound. Each query is logged to dnstap and is ingested by our SIEM platform which alerts upon abnormal requests. dnstap logs also provide very useful data when investigating an incident.

Tracking issue for moving trust-dns to trust-dns org

Before doing this, I need to validate that no tracking information between crates.io, docs.rs, etc. will be lost or broken...

update all crates.io and docs.rs references

Randomize client port and query_id

http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

Feature request: RFC 7858, DNS over TLS

I just finished reading your article about this implementation and noticed that you are working on DNSCrypt integration. I thought maybe it would be a better idea to be the first project to put support for RFC 7858 (DNS over TLS) in a production grade client/server.

Feature request: Add support for sandboxing

It would be useful to have support for sandboxing trust-dns, in particular decoding of requests.

rusty-sandbox offers an abstraction layer over the sandboxing mechanisms provided by several operating systems, and could be incorporated as an optional compile-time feature.

Verify no resource leak in MIO and event registry

The current methods coded around portability issues with Mac OS X and Linux (Windows, is unknown) where register, reregister and deregister are not acting as expected. See comments in code.

Support PKCS11 for private key storage

This should improve overall security and allow the DNS server to use an HSM module or similar.

Changelog persistence for zones

A write-ahead log of the zone records captured as transactional changes, i.e. updates might include multiple updates, a delete and create in one request, this should capture a single update transaction, not both independently.

License metadata disagrees with comment

In Cargo.toml, there's a fragment:

# license identifiers from http://spdx.org/licenses/. Multiple licenses can
# be separated with a `/`
license = "MIT OR Apache-2.0"

It looks like the comment should say "OR", or the license should use "/"

[Server] Add Forwarding Zone support

I'm fairly new to rust, so with the understanding that I could be completely wrong about all of this...

It appears that there isn't any support for forwarding zones. Though a zone file can be declared as a forwarding zone, there isn't actually any support for this behavior in the code - it appears to treat all zones the same for lookup purposes.

It appears like Authority::lookup() and Catalog::find_auth_recurse() would be the primary areas that would need to be modified, along with the requisite configuration changes.

I'm interested in contributing code, and would be willing to try and implement this if I'm not mistaken.

Thanks!

Listen on all addresses

Currently, named doesn't actually listen on all specified addresses. It takes the first address (both v4 and v6), or a default of 0.0.0.0 and ::0. In addition, there's no way to disable IPv4 or IPv6 as even if an IPv4 address is specified the system still will use the default IPv6 address - even if no IPv6 address is set or even if it is explicitly set to the empty list.

This breaks some dual-stack systems as well where IPV6_V6ONLY is by default false, because the v6 socket cannot bind as it conflicts with the v4 socket.

The attached patch is my attempt to fix the issue - I haven't tested every edge case, but it works on my system (debian) with the default configuration (example.toml) under simple tests, and seems sane to me.
0001-Listen-on-all-available-IP-addresses.txt

Go through and remove clone() and have better shared memory usage

This will require some global storage for Names and the Catalog

[Server] Feature request: Allow custom backends to be used for Authorities/Catalogs

As the title, says. Split out the low level functions into a nice DNS library and then build the server and client crates on top of that library. See #43 (comment) and the comments that follow that one for details.

Switch out direct usage of MIO for futures.rs (client)

http://aturon.github.io/blog/2016/08/11/futures/

and

https://crates.io/crates/futures

Upgrade OpenSSL to 0.8.x

Before the upgrade to ring, I'd like to request that trust-dns adopt rust-openssl version 0.8. I found in my use of rust-openssl in rust-ftp that some usage of rust-openssl version 0.7 lead to a memory error that was resolved immediately by the update to 0.8.

For a tiny bit more information, see the issue I opened on hyperium/hyper.

Client fails to verify records with uppercased names

Test case:

#[test]
fn test_dnssec_rollernet_td() {
    use trust_dns::udp::UdpClientConnection;
    use trust_dns::client::Client;
    let c = Client::new(UdpClientConnection::new("8.8.8.8:53".parse().unwrap()).unwrap());
    c.secure_query(
        &Name::parse("rollernet.us.", None).unwrap(),
        DNSClass::IN,
        RecordType::DS,
    ).unwrap();
}

This fails with No DNSKEY proof available error while validating the returned NSEC record, but according to http://dnsviz.net/d/rollernet.us/dnssec/ , the server returns correct RRSIG. From what I can tell, this server returns uppercased names in the record, but all names are converted to lowercase on deserialization, which breaks verification.

bluejekyll / trust-dns Goto Github PK

trust-dns's Issues

Why?

How?

Contributor checkoff

Recommend Projects

Recommend Topics

Recommend Org