design restconf

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.

Links

• RESTCONF RFC document
  • https://tools.ietf.org/html/draft-ietf-netconf-restconf-05
• Gitlab resources
  • Issue
  • NSPRC-obsolete
  • The repo for the app
  • YANG model for the config
  • Cap'n Proto

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 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.