|
|
## The idea
|
|
|
|
|
|
The idea is to control Knot DNS using the RESTCONF protocol. Gradually everything can be controlled in that manner. This proposal obsoletes the [previous](design-nsrpc).
|
|
|
|
|
|
## Links
|
|
|
* RESTCONF RFC document
|
|
|
* https://tools.ietf.org/html/draft-ietf-netconf-restconf-05
|
|
|
* Gitlab resources
|
|
|
* [Issue](https://gitlab.labs.nic.cz/labs/knot/issues/377)
|
|
|
* [NSPRC-obsolete](design-nsrpc)
|
|
|
* [The repo for the app](https://gitlab.labs.nic.cz/labs/jetconf)
|
|
|
* [YANG model for the config](https://gitlab.labs.nic.cz/labs/dns-server-yang/tree/master)
|
|
|
* [Cap'n Proto](https://capnproto.org/)
|
|
|
|
|
|
## What we want
|
|
|
|
|
|
1. Primarily we want to configure Knot DNS over network. RESTCONF was selected due to its overall better quality than NETCONF: statelessness, simplicity, JSON, etc.
|
|
|
2. Secondly, "because we can", we'd like to manage kaspdb and zonedb (zones in general) and control the server using RPC.
|
|
|
|
|
|
## How we can get it
|
|
|
|
|
|
The overall design:
|
|
|
Client -> RESTCONF -> JSON -> HTTP/2.0^1 -> Network -> HTTP/2.0^1 -> JSON -> RESTCONF -> knot-restconf-server -> {datastore, rpc}
|
|
|
|
|
|
The knot-restconf-server is a separate binary from Knot DNS.
|
|
|
* Advantages:
|
|
|
* No extra dependencies for Knot
|
|
|
* No extra code to maintain in Knot, which is critical, and separating this non-critical into its own codebase
|
|
|
* Should be quite simple in the end as well
|
|
|
* Modularity
|
|
|
* Flexibility
|
|
|
* Disadvantages:
|
|
|
* Extra code to keep up-to-date with current Knot DNS development. If something related changes in Knot, this needs to change here. This can be reduced, though.
|
|
|
|
|
|
|
|
|
The datastore:
|
|
|
* configuration: we split Knot DNS server and its configuration subsystem and make that into a library. We use that library in our knot-restconf-server to alter the config LMDB on disk. When we're done with it, we do RPC to close-and-reopen the read-only transaction in the confdb in Knot. This all should be very simple and extremely fast; LMDB supports this and in essence we should get RCU-like behaviour.
|
|
|
* kaspdb: we do things just as keymgr does them.
|
|
|
* zonedb: for starters we can dump zones on disk and use knotc^2 to reload zones. **We should improve this, though. TODO**. (zone-api dependent?)
|
|
|
* RPC: knotc^2.
|
|
|
|
|
|
|
|
|
Problems:
|
|
|
* We need to either dump the new config into a configuration file, or write into a configuration log/journal. The reason is to prevent configuration inconsistencies in case of a server crash/restart.
|
|
|
|
|
|
--------
|
|
|
^1 [H2O](https://h2o.examp1e.net/) should be fast. In any case, I couldn't find any GnuTLS-based HTTP/2.0 libs.
|
|
|
|
|
|
^2 For proof-of-concept call knotc binary, then do it properly.
|
|
|
|