Skip to content
Snippets Groups Projects

design config changes

Last edited by Jan Vcelak

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:

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.

Comments

    Please register or sign in to add a comment.