[knot-dns-users] system.nsid reconfiguration bug

Marek Vavruša marek.vavrusa at nic.cz
Fri Aug 9 10:51:42 CEST 2013


On 8 August 2013 22:10, Johan Ihrén <johani at johani.org> wrote:
> On Aug 8, 2013, at 12:56 , Marek Vavruša wrote:
>
>> The addresses are parsed as a different token, so it shouldn't be allowed.
>> My point was that if it is either strict or relaxed, you don't have to
>> think about how to write it out.
>> If there are exceptions, it may work well but it also might be
>> annoying to configure, if you are not
>> able to guess whether it should or shouldn't be quoted instinctively.
>>
>> I think if we require quoted string for values, it is a good compromise.
>> Things where it is obvious like paths, TSIG secret, CH TXT + NSID
>> related strings and I can't think
>> of what else. So this change would touch only several parameters, to
>> which most of the people use quoted strings anyway?
>
> So I agree this seems like a reasonable compromise. However, as we're discussing
> parsing the conf file I have two more observations:
>
> 1. If I declare a TISG key without the quotes:
>
> keys {
>     foo. hmac-sha256 secret;
> }
>
> Then checkconf claims that the config is valid, but starting the server will lead to a segmentation fault when trying to do the TSIG protected zone transfer. I'm aware that I should use quotes, but checkconf didn't catch that (and regardless of format, segmentation faults are not cool).

Right, this is parsed in a wrong way. Not cool at all, I'll fix it promptly.
https://gitlab.labs.nic.cz/knot/issues/137
But it also shows that it could be avoided if we differentiated
between quoted strings/unquoted tokens-identifiers in the first place,
good.

> 2. I'm a bit confused regarding the syntax for "lists":
>
> remotes {
>    foo { address ...; port ...; }
>    bar { address ...; port ...; }
> }
>
> To me, the {...} after "foo" is a list. The elements of this list are terminated by a ";". This is all fine and a standard notation known from many other places.
>
> However, what about the {...} after "remotes", isn't that also a list (of remotes)? If so, why are the elements not terminated by a ";"?
>
> And it gets worse, see groups:
>
> groups {
>   self { me, myself }
> }
>
> I think that the {...} after "self" is a list, but now we have a third notation: comma as a separator, instead of semicolon as a terminator, (or space as a separator, as in the "remotes" case).
>
> Am I missing anything here or is this really a bit inconsistent?
>
> Regards,
>
> Johan
>

Hmm, it may be so. The remote declaration is not a list per-se, it is
a nested structures requiring named attributes, just like it is with
'system {}' or 'keys {}' or any other. But the truth is, that for
example interfaces are named only for the 'via' keyword, not much
useful and could be reduced to list.
Lists are used for groups and ACLs only.

That being said, it could be confusing, yes. I think most of of the
configuration could be converted to a list-like notation, separated
with ';'. That change however would be very hardly backwards
compatible, so
if we break it for some next major version, we might as well put in as
many improvements as possible.
I don't fancy the repetition of "address" keyword in remote/interface
for example, naming of the interfaces is probably superfluous, 0.0.0.0
could mean ANY without prefix spec, zone ACLs are not always clear,
like "xfr-in" does not imply strongly that the following remote will
be used as a master and others.
I have created a small page on our wiki to collect bits and pieces
https://gitlab.labs.nic.cz/knot/wikis/config-changes

This probably won't happen in the 1.4, but it is a very good idea to
collect ideas at this point and if we're going to break things, I'd
rather make it worthwhile :)

Johan, many thanks for the input. This is exactly the honest feedback
I value so much.

Marek



More information about the knot-dns-users mailing list