I hope former US President Ronald Reagan would forgive me for borrowing and altering the slogan of his presidential campaign. After all, quite a few people seem to be doing it these days.
Knot DNS 2.1 introduced support for DNSSEC signing using PKCS #11. PKCS #11 (also called Cryptoki) is a standard interface to access various Hardware Security Modules (HSM). Such devices are usually used to improve protection of private key material. The interface is rather flexible and gives the HSM vendors huge amount of freedom, which unfortunately makes its use a bit tricky. There are often surprising differences between individual implementations.
This week I was approached by a man dressed in platypus pyjamas, he asked me: “These layers and modules you talk about, they’re cool. But can it be even better?”. After the initial costume distraction wore off, I pondered a bit and said: “Sure, let me just grab a cup of coffee”. The real story is that the layers are now much more interactive, and the documentation is improved.
Since you’re reading this, you probably know Lua, the world’s most infuriating language. If not, hop on to Lua in 15 minutes to get the basics right. Now there are two types of use cases where Lua shines – as a tiny script/configuration language, and for high-performance data processing (with JIT). I went through both of them with kresd, and wrote down some notes.
validator – need for speed – RPZ – views – new tests
It has been a few weeks since the final version of Knot DNS 2.0 came out. While it’s still fresh, I would like to explain our motivation for this new major version and also to summarize the most important changes included in this significant release.
IETF93 – prefetching and predictions – more cwrap – validating signatures
I/O improvements – documenting – validation – Happy Eyeballs
A short tutorial on how to block DNS slow-drip attack with kresd.