|
|
## Problematic use cases now
|
|
|
|
|
|
* Hosting scenario (lots of zones, reconfiguration overhead proportional to length of the configuration)
|
|
|
* Dynamic modules (can only accept string instead of module-specific element for example)
|
|
|
* Dynamic reconfiguration (no zone file generator, possibly slow to rewrite after each change)
|
|
|
|
|
|
## Ideas about the current configuration
|
|
|
|
|
|
* Lists (`groups`, `ACLs`) are inconsistent with the rest of configuration (like `remotes` not separated by ';', `interface` specification is also inconsistent)
|
|
|
* `address` keyword is superfluous
|
|
|
* `interfaces` naming is probably overkill
|
|
|
* Differentiate between unquoted strings *(identifiers, tokens)* and quoted strings *(string values)*
|
|
|
* Special addresses like `0.0.0.0` could be treated as `ANY` without zero prefix
|
|
|
* ~~Logging should behave like syslog (severity `warning` should incorporate `error, fatal...` and so on)~~
|
|
|
* Knot places both journal and zone files into `storage` directory, maybe we could have something like `zonedir`?
|
|
|
|
|
|
## Possible changes
|
|
|
|
|
|
#### ACLs for zone changes
|
|
|
|
|
|
We could allow users to change zone configuration if they pass an ACL check as in the DDNS update.
|
|
|
i.e. if the user has the keys to change the zone contents, he could be allowed to change zone configuration as well. This could give more fine-grained access control without an additional user/groups/roles model.
|
|
|
|
|
|
We should probably restrict this to some variables only, in order to prevent the users to rewrite zone files
|
|
|
of other zones etc.
|
|
|
|
|
|
#### ACLs: Why may the design be flawed, rants
|
|
|
|
|
|
I think associating remotes/groups 1:1 to different ACL rules is a bit problematic since it doesn't have a sense of how the rules will be enforced and (importantly) in what order.
|
|
|
I grew accustomed to that, but I see many benefits of (very loose) iptables-style rule enforcing. Another thing is that `xfr-in` and `notify-out` are treated as ACLs but really shouldn't be and it may be confusing. So instead of different remote lists for `xfr-out`, `notify-in` or `update-in` we should have a rules and rule sets.
|
|
|
Like:
|
|
|
|
|
|
```nolang
|
|
|
deny all # optional
|
|
|
allow 1.2.3.4/0 key abcd for xfer, update
|
|
|
allow key cdef for xfer
|
|
|
allow 1.1.1.1 for notify
|
|
|
```
|
|
|
|
|
|
This would:
|
|
|
|
|
|
* Make it clear in what order the rules are applied
|
|
|
* Oriented on WHO rather than "in what list shall we put who"
|
|
|
* Apply named ruleset to the zones like `zone { ...; acl myrules0; }`
|
|
|
|
|
|
## Configuration in JSON/YAML
|
|
|
|
|
|
The custom configuration format is inconsistent (use of semicolons, ...) and the paser is difficult to maintain. We could switch to JSON or YAML, as it is simple to read/write both by human and by computer.
|
|
|
|
|
|
Disadvantages:
|
|
|
|
|
|
* JSON: does not support comments (can be solved by custom preprocessor)
|
|
|
|
|
|
Advantages:
|
|
|
|
|
|
* Universal
|
|
|
* YAML: very well human readable
|
|
|
* JSON: human readable, but not so well as YAML
|
|
|
* Get rid of lex and yacc
|
|
|
* Easy to parse/modify configuration by third party scripts
|
|
|
* We can query the configuration easily using `knotc getconfig <option>` (or similar), useful for packages (not necessary to awk/sed/grep the config)
|
|
|
|
|
|
JSON libraries:
|
|
|
|
|
|
* `jansson` - very very very nice API, object model, no dependencies, MIT license, Linux + BSD
|
|
|
* `json-c` - object model, no dependencies, MIT license, Linux + BSD
|
|
|
* `yajl` - stream parser, very small footprint, ISC license, Linux + BSD
|
|
|
* ...
|
|
|
|
|
|
YAML libraries:
|
|
|
|
|
|
* `libyaml` - very nic, much stream paser, no dependencies, so stable, MIT license, Linux + BSD, wow
|
|
|
* `syck` - dead project
|
|
|
* nothing else for C
|
|
|
|
|
|
## When & how?
|
|
|
|
|
|
Not sure yet. |
|
|
\ No newline at end of file |