|
|
## Assorted list of materials
|
|
|
|
|
|
* NSCP original draft
|
|
|
* http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control-01
|
|
|
* http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control-01
|
|
|
* JSON RPC info
|
|
|
* http://www.jsonrpc.org/specification
|
|
|
* Unbound-control protocol
|
|
|
* http://unbound.nlnetlabs.nl/svn/trunk/doc/control_proto_spec.txt
|
|
|
|
|
|
## Background
|
|
|
|
|
|
This is a follow up to the initial talk about name server protocol design, reworked with the
|
|
|
remarks, thoughts and new use cases since then.
|
|
|
This draft is a far cry from a complete thing and very open to comments.
|
|
|
|
|
|
## Abstract
|
|
|
|
|
|
General idea is to have a common protocol for configuring and controlling name servers (NS)
|
|
|
in diverse environment. Traditionally, the same name server implementation was used
|
|
|
both as a master and slave. Now that we have a diverse implementations, it's getting
|
|
|
more problematic to configure them in the same way.
|
|
|
But the communication doesn't always have to be between human and the NS.
|
|
|
For example, there is a strong demand for a functionality, in which the master server
|
|
|
would be able to tell slaves about new zones, but also remove the old zones.
|
|
|
This was partially implemented as a [supermaster](http://doc.powerdns.com/html/slave.html) known in the PowerDNS, but with several limitations.
|
|
|
Another good example is visual front-end to NS communication for
|
|
|
less experienced users.
|
|
|
|
|
|
One must also take into account that each NS implementation treats configuration in a
|
|
|
different way, so complete unification would require powerful data models and mechanisms
|
|
|
to achieve that. Notable examples are:
|
|
|
http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control-01
|
|
|
http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control-02
|
|
|
On the contrary, the goal of this draft is to present a reasonable subset,
|
|
|
acceptable by vendors, as we must take an engineering economics point into the view.
|
|
|
|
|
|
## Goals
|
|
|
|
|
|
To sum up the goals from the abstract:
|
|
|
|
|
|
* Protocol understandable by both meatbags and machines
|
|
|
* Encrypted communication
|
|
|
* Clearly defined core functionality, but versioned to allow extensions later on
|
|
|
* Easy to implement and acceptable by the vendors
|
|
|
* Usable from the front-end (possible web based applications)
|
|
|
* Have reference implementation as soon as we decide on basics
|
|
|
|
|
|
We are addressing both users with diverse NS environment and NS vendors.
|
|
|
|
|
|
## Security
|
|
|
|
|
|
We'd like to treat security issues separately from the protocol design. Meaning channel
|
|
|
confidence and authentication (possibly finer grained authorization later on) should be
|
|
|
done outside of the protocol itself and it should be possible to use remote control for
|
|
|
example over AF_UNIX without authentication.
|
|
|
|
|
|
There are two things we need:
|
|
|
|
|
|
* Encryption layer
|
|
|
* Authentication layer
|
|
|
|
|
|
Since we need to do encryption anyway, this means TLS/SSL to carry the
|
|
|
data. If we went for X.509 certificates instead of secret based ciphersuites like TLS-SRP,
|
|
|
we could client certificate authentication for basic authentication.
|
|
|
|
|
|
If we used HTTPS, it would be nicer for the front-end web applications, would allow
|
|
|
different authentication methods. On the other hand it would require HTTP protocol parsing
|
|
|
and umarshalling of the data itself.
|
|
|
|
|
|
Last option would be an abstract layer like SASL.
|
|
|
While it is a good incentive not to care about how to deal with authentication,
|
|
|
it is another dependency, more complex configuration etc.
|
|
|
I'm far from an expert on this, so any ideas are quite welcome, but keep in mind the likelihood of protocol adoption
|
|
|
depends on the simplicity.
|
|
|
|
|
|
Another question is, how much motivation is there for fine grained ACLs.
|
|
|
|
|
|
## Protocol syntax
|
|
|
|
|
|
The original draft proposed a new notation, but raised a few good points about how to
|
|
|
deal with multi line answers and encoding. Since there already is a myriad of proven notations,
|
|
|
we propose a JSON for it's readability, simplicity and availability of small BSD/MIT licensed
|
|
|
parser libraries. There is also a specification of JSON-RPC, which we could leverage.
|
|
|
|
|
|
* It is versioned, so it may be extended later on.
|
|
|
* Carries and ID, so it keeps a context and allows transaction-like commands.
|
|
|
* It's well... bunch of named keys in JSON notation, so nothing to worry about.
|
|
|
|
|
|
An example of how it looks like:
|
|
|
|
|
|
``` nolang
|
|
|
--> {"method": "reload", "params": ["example.com"], "id": 1}
|
|
|
<-- {"result": "ok", "error": null, "id": 1}
|
|
|
```
|
|
|
|
|
|
## Core functionality
|
|
|
|
|
|
We probably don't need to mandate a schema here, unknown commands should return unsupported
|
|
|
error response and there should be a function to list all available commands.
|
|
|
That being said, several commands should be available for every implementations.
|
|
|
Result is always a status code and appropriate error code set unless stated otherwise.
|
|
|
|
|
|
Note: The original notes mandated a commands for server start|restart|stop. As it would require a
|
|
|
separate daemon with proper privileges to operate with binaries, I think it's reasonable to
|
|
|
leave this on the other means to start the binaries and the protocol should only concern
|
|
|
with already running daemons.
|
|
|
|
|
|
Core functionality is also easy to implement for all available name servers and doesn't
|
|
|
require any modification of the configuration.
|
|
|
|
|
|
### Helper commands
|
|
|
|
|
|
Because I can't find a proper name for this category.
|
|
|
|
|
|
#### info
|
|
|
|
|
|
Parameters: None
|
|
|
Output: Information about server, version.
|
|
|
|
|
|
#### commands
|
|
|
|
|
|
Parameters: None
|
|
|
Output: List all available commands. (Sort of declares the capabilities.)
|
|
|
|
|
|
#### reconfigure
|
|
|
|
|
|
Parameters: None
|
|
|
Meaning: Re-read server configuration.
|
|
|
|
|
|
### Controlling existing zones
|
|
|
|
|
|
Following commands work on configured zones, but don't alter zone contents directly
|
|
|
nor do they create/remove zones and don't require changes to server configuration.
|
|
|
|
|
|
#### list_zones
|
|
|
|
|
|
Parameters: None
|
|
|
Output: List of zones
|
|
|
|
|
|
#### reload
|
|
|
|
|
|
Parameters: List of zones (or empty list for all)
|
|
|
Meaning: Reload zones configuration and/or contents from zone files if changed.
|
|
|
|
|
|
#### refresh
|
|
|
|
|
|
Parameters: List of zones (or empty list for all)
|
|
|
Meaning: Check if the slave zones can be updated from the master, and start transfer if yes.
|
|
|
|
|
|
#### notify
|
|
|
|
|
|
Parameters: List of zones (or empty list for all)
|
|
|
Output: Status code or error number.
|
|
|
Meaning: Issue NOTIFY messages to slaves for given zones.
|
|
|
|
|
|
#### retransfer
|
|
|
|
|
|
Parameters: List of zones (or empty list for all)
|
|
|
Meaning: Similar to refresh, but retransfer listed zones without checking for changes.
|
|
|
|
|
|
## Non-core functionality
|
|
|
|
|
|
### Automatic provisioning
|
|
|
|
|
|
Dynamic zones require a way to change server configuration, so that the changes made by
|
|
|
this protocol are persistent after server restart. The protocol doesn't mandate how the
|
|
|
actual configuration changes, only that it's persistent.
|
|
|
|
|
|
#### zone_add
|
|
|
|
|
|
Parameters: Zone name.
|
|
|
Meaning: Adds a new empty zone, which should be treated as a slave zone waiting for bootstrapping,
|
|
|
although it wouldn't have any configuration yet.
|
|
|
|
|
|
#### zone_remove
|
|
|
|
|
|
Parameters: Zone name.
|
|
|
Meaning: Remove a zone file from the configuration.
|
|
|
|
|
|
#### zone_config
|
|
|
|
|
|
Parameters: Zone name.
|
|
|
Meaning: Show zone configuration, list of valid key-value pairs.
|
|
|
Note: The list of valid keys needs to be unified like: masters, allow*, file, type.
|
|
|
|
|
|
#### zone_setconfig
|
|
|
|
|
|
Parameters: Zone name, config key, config value.
|
|
|
Meaning: Alter zone configuration.
|
|
|
|
|
|
### Transaction commands
|
|
|
|
|
|
The dynamic commands most likely require zones configured before they are visible to the
|
|
|
outside world. Transactions make this possible by completing the set of commands as one
|
|
|
atomic block in the given order.
|
|
|
|
|
|
#### transaction
|
|
|
|
|
|
Meaning: Marks the start of a transaction for this context.
|
|
|
|
|
|
#### commit
|
|
|
|
|
|
Meaning: Execute commands from the start of transaction, each command must end as a success
|
|
|
otherwise the commit returns an error code and the transaction is scrapped.
|
|
|
|
|
|
#### rollback
|
|
|
|
|
|
Meaning: Scrap all changes in the current transaction. |
|
|
\ No newline at end of file |