Skip to content
Snippets Groups Projects
Select Git revision
  • declarative-config-stabilization
  • root-fallback-addresses
  • module-tunnel-filter
  • dname_kru
  • dname_limiting
  • defer-hard-timeout
  • ci-jobs-reorganization
  • master default protected
  • nightly protected
  • manager-api-config-fix
  • tls-authority-whitelist
  • rfc-list
  • manager-files-watchdog
  • tmp/test-deckard
  • forward-tls-insecure
  • doh-stuck-status
  • module-filter
  • coverity protected
  • ci-docker-tests-update
  • kresctl-comp-config-levels
  • v6.0.11 protected
  • v6.0.10 protected
  • v6.0.9 protected
  • v6.0.8 protected
  • v5.7.4 protected
  • v5.7.3 protected
  • v6.0.7 protected
  • v5.7.2 protected
  • v6.0.6 protected
  • v5.7.1 protected
  • v6.0.5 protected
  • v6.0.4 protected
  • v6.0.3 protected
  • v6.0.2 protected
  • v5.7.0 protected
  • v6.0.1 protected
  • v6.0.0a1 protected
  • v5.6.0 protected
  • v5.5.3 protected
  • v5.5.2 protected
40 results
Compare History
Vladimír Čunát's avatar
validator: bottom->up chase DS if RRSIG(s) are missing
Vladimír Čunát authored 
This is about situations when validator *thinks* it's in a signed zone
but an unsigned answer comes in. The assumption was that RRSIGs didn't
make it through some middle-boxes and it retried with explicit QTYPE=RRSIG.

There were two issues with that.
1. It seems that in most cases the cause of the situation is that
   we skipped over a zone cut that transitioned to insecure state,
   so the signatures correctly don't exist.
2. An explicit RRSIG query appears to be more trouble than worth;
   it seems reasonable for servers not to answer it (fully);
   see RFC 8482 sect. 7.

The new approach simply tries to find a proof that the name is insecure,
by spawning a QTYPE=DS sub-query on that name.  That fixes some
real-life cases; usually this happens in iteration mode where one IP
address serves zones on both sides of a cut that transitions to insecure.
For details see new comments in that rrsig_not_found() function.

The change resulted in the iterator fallback not making sense anymore
so it was removed.
703d918a
Name Last commit Last update
bench
ci
client/.packaging
contrib
daemon
distro
doc
etc
lib
modules
scripts
systemd
tests
utils
.clang-tidy
.dir-locals.el
.gitattributes
.gitignore
.gitlab-ci.yml
.gitmodules
.luacheckrc
.mailmap
.travis.yml
AUTHORS
COPYING
CodingStyle
Dockerfile
NEWS
README.md
meson.build
meson_options.txt
README.md

Knot Resolver

Build Status Coverage Status Documentation Status

Knot Resolver is a caching full resolver implementation written in C and LuaJIT, both a resolver library and a daemon. The core architecture is tiny and efficient, and provides a foundation and a state-machine like API for extensions. There are three modules built-in - iterator, validator, cache, and a few more are loaded by default. Most of the rich features are written in Lua(JIT) and C. Batteries are included, but optional.

The LuaJIT modules, support DNS privacy and DNSSEC, and persistent cache with low memory footprint make it a great personal DNS resolver or a research tool to tap into DNS data. TL;DR it's the OpenResty of DNS.

Strong filtering rules, and auto-configuration with etcd make it a great large-scale resolver solution.

The server adopts a different scaling strategy than the rest of the DNS recursors - no threading, shared-nothing architecture (except MVCC cache that may be shared) that allows you to pin instances on available CPU cores and grow by self-replication. You can start and stop additional nodes depending on the contention without downtime.

It also has strong support for DNS over TCP, notably TCP Fast-Open, query pipelining and deduplication, and response reordering.

Packages

The latest stable packages for various distributions are available in our upstream repository. Follow the installation instructions to add this repository to your system.

Knot Resolver is also available from the following distributions' repositories.

Building from sources

Knot Resolver mainly depends on Knot DNS libraries, LuaJIT and libuv. See the Building project documentation page for more information.

Docker image

This is simple and doesn't require any dependencies or system modifications, just run:

$ docker run -Pit cznic/knot-resolver

The images are meant as an easy way to try knot-resolver, and they're not designed for production use.

Running

The project builds a resolver library in the lib directory, and a daemon in the daemon directory. It requires no configuration or parameters to run a server on localhost.

$ kresd

See the documentation at knot-resolver.readthedocs.io for more options.

Contacting us