As seen onFavicon for https://en.blog.nic.czen.blog.nic.cz

Knot DNS Recursive goes beta

DNSSEC - RFC7646 NTA - RFC5011 TA updates

Embed

  1. The last big thing for this quarter landed in the master - the DNSSEC validator. This means it's mostly feature complete and we'll be focusing on ironing things out in the next few weeks before the public release. It also means that there shouldn't be any major hiccups, and I'd like to reach out to interested people to test it out. I've updated the documentation and readme, so the installation process should be more straightforward than a few months back - the two major dependencies (libuv 1.7 and libknot 2.0.1) are now in packages.
  2. What's our pitch?

  3. The obvious question is how does it stack? It's different in three ways - scaling approach, extensions and layers. While I've covered performance (and will continue to do so) in past posts about metrics, the tangible features come first. With layers you can trace what's going on inside the query resolution and react upon it (e.g. RBL, metrics). You can create and remove layers ad-hoc from console, in the configuration or in modules. So only the core stuff is built-in, and scripted extensions are partially sandboxed without sacrificing performance. The API is rich enough to use it for anything from policies, views, trust anchor management. That makes Knot DNS Recursive great as a foundation for a custom recursive DNS service, such as consented ad filtering, encrypting endpoint, or even a distributed object storage. It's the OpenResty of DNS, and I'm quite excited about what it's going to power.
  4. Sounds a bit overwhelming, but the trick is making all this as simple as possible. If you don't need any of it, just pass it an address where you want to run it and a path to the keyfile. No config, no anything.
  5. How can you try it?

  6. You can build it from source, or try the Docker thingy. Ansible module is on the way. I'd love to see people start packaging it.
  7. Then the DNSSEC

  8. This is probably one of the longest things to implement. As of now, it validates according to the RFC4034,4035. It's default on (like the Google's resolver), so it validates in the background even if you do not ask for it (but it doesn't return DNSSEC records then). It's probably the simplest thing to implement, as it doesn't require a separate cache for insecure records. It also supports RFC5011 automatic trust anchor management. Just point it to a keyfile containing a first trusted key and it's going to update it for you. The final thing is RFC7646 negative trust anchors, as a mean to prevent validation failures for broken zones.
  9. The validation algorithm isn't perfect, sometimes it has to refetch a query before validating and notably +cd isn't implemented.
  10. What can you expect in the release

  11. Fixed DNSSEC quirks, querying multiple unknown authoritatives at once (to avoid a situation when a sequence of unknown authoritatives timeout) and simplified build scripts / dependencies. And a writeup on a DNS test harness we're making.
  12. What can you expect after the release

  13. The same quarterly cycle with interleaving "features" and "performance / cleanup". We're keeping a list of ideas, but it's going to be assigned later on. Expect things like performance, message compression, better documentation on the scriptable APIs, better RPZs, improved coordination and threat prevention between instances, easy web monitoring and deployment interface.
  14. Another thing that I'm watching closely is the DNS privacy. As you know, Knot DNS Resolver implements QNAME minimisation by default, but no encryption between resolver and authoritatives and neither between resolver and user. There are promising standards for DNS/TLS on the way, but nothing decided yet.
1
Share

Share

Facebook
Google+