11 Led
2013
11 Led
'13
11:41
Hi Johan,
thanks for reaching to us, really appreciated.
On 10 January 2013 17:04, Johan Ihrén <johani(a)johani.org> wrote:
I'm with you about the keep-it-simple concept. But - majority of the
code doesn't add any extra specific complexity that wasn't there. Just
the medium changed from signals due to specific limitations (mentioned
below).
Hi Marek,
On Jan 7, 2013, at 17:53 , Marek Vavruša wrote:
Not at the moment, but it could be interesting. I'll push it to our
issue tracking system
and let you know how it goes, thanks!
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.
I understand the feelings and reasoning behind this, but there are
couple good reasons why we implemented it. As Peter noted - it is not
possible to control process operation by signals unless you have the
appropriate rights for it. And for some scenarios, it is desirable to
run server as a different user and control by others. As for the
firewall thing, control interface was never meant to be exposed on a
public interface (also noted in the documentation), but rather on a
loopback or trusted LAN.
Maybe it would be better to have a UNIX socket for that, I really went
for the BSD sockets for the configuration consistency and... laziness.
Perhaps I'll reconsider.
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
I'll keep that in mind, in fact, we're in the process of removing
(although hidden and internal) complexity. It doesn't have to be bare
bone and bloated, there (usually) is some sweet spot of what's useable
in real world and what is bling. That probably is what we're trying to
achieve.
Kind regards,
Marek