10 Led
2013
10 Led
'13
17:04
Hi Marek,
On Jan 7, 2013, at 17:53 , Marek Vavruša wrote:
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