Hi Marek, On Jan 7, 2013, at 17:53 , Marek Vavruša wrote: Yohoo! I'll try to play with this ASAP. Any SIG0 support or plans for SIG0 support? I realise that I don't have to use this, so from that POV I really don't have to care. But at the same time I do care about feature bloat and the importance of simplicity. So please read the rest of this from the point of view that I really like Knot, I have high hopes for it and this is not meant as a complaint, but rather as "this is my view, FWIW". Many years ago I was using the mostly identical functionality in BIND9. I.e. to "control" a remote nameserver we did things like rndc -s remote.server reconfig (at that time I also thought that "views" were a cool thing, but with time you gain experience ;-) But in an increasingly hostile world we've stopped using the BIND9 "controls" statement. The reason is that it required us to punch yet another hole in the firewall, and verify that there were no nasty bugs in the remote access code that would impact our service. And, very importantly, we really didn't need it. When I compare the complexity and functionality in doing either of rndc -s remote.server reconfig ssh remote.server rndc reconfig the latter version "wins" hands down. Because: * I already have an ssh-shaped hole in the firewall * I already [have to] trust ssh (not to mention that the amount of security audit that ssh sees probably outweighs what Knot-DNS see by at least 1000x). * I also gain simplicity from not having to deal with the controls statement * and the amount of extra typing is one single character ;-) So I'm inclined to regard this as "less than useful" to us. But if you can show me a use case where "knotc -s remote.server ..." adds important functionality that I don't get via "ssh remote.server knotc ..." then I'll reconsider. Perhaps. There are other nameservers that have been sucked down into the feature-bloat hole and they have a really hard time getting out, because once you have a feature then people will depend on it and then it very quickly becomes impossible to remove it because then users will complain. Therefore you have to be really, really careful with what you add...

Regards, Johan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

we're proud to announce, that release candidate for the next major release 1.2 is out!

Apart from a couple bugfixes, it features full DDNS support (including update forwarding).

There are a few limitations related to DNSSEC-signed zones, please refer to user manual for more information. Access control for dynamic updates could be configured in a similar fashion to transfers, using the 'update-in' keyword.

Next major thing is an updated remote control tool. Basic commands for start/stop/restart/compile and checks are the same as they were, but the command for refresh/flush/status could be executed remotely given the right configuration. You can enable remote control interface with a new config section 'control', f.e.: control { listen-on { address 127.0.0.1@5553; } allow remote0; }