11 Led
2013
11 Led
'13
7:25
2013/1/10 Johan Ihrén <johani(a)johani.org>rg>:
Hi Marek,
On Jan 7, 2013, at 17:53 , Marek Vavruša wrote:
Hi, Johan,
Sorry for intervention, but old control tool is the main reason why I
didn't put Knot in production yet. Because to use old-fashioned knotc
you have to be either root, or user who owns knotd process. That's not
an option for us.
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).
Yohoo! I'll try to play with this ASAP.
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.
Any SIG0 support or plans for SIG0 support?
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;
}
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
--
AP