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

Johan Ihrén johani at johani.org
Fri Aug 9 22:19:50 CEST 2013


Hi Marek,

On Aug 9, 2013, at 10:51 , Marek Vavruša wrote:

> 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.

Exactly. And having spent some time on figuring out the problem I had to beat myself up to find that it was exactly the issue that we were at the same time discussing by email, i.e. pros and cons of explicit quotation of strings.

>> 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.

Well, it is that because you parse it that way, not because it has to be. And looking at this from the perspective of the user, 99 out of 100 users will look at it as a list.

> 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 fully agree with this. I do understand the backwards compatibility issue. But the way I look at it, Knot-DNS right now has a user base of N... your expectation and hope is of course that in two years time the user base will be 100 x N, or something like that. Given that I think it is very important to sort out and fix any inconsistencies in the config language as quickly as possible, because the longer you wait, the more users you'll confuse.

> 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

Good start. I couldn't add to that page so I'll continue to comment here. You have thought more about this than I have ;-) I'll ponder my experiences for a bit to see if I can come up with anything more that I find inconsistent, but I think you got most of it.

Well, as we're really trying to find stuff... the keys declaration:

keys {
  foo.key hmac-sha256 "secret";
  bar.foo hmac-md5    "turkey";
}

while structurally a list (good!) with ";" terminators (good!) is still syntactically different from the other constructs, like remotes, etc. Perhaps

keys {
  foo.key { hmac-sha256; "secret"; }
  bar.foo { hmac-md5;    "turkey"; }
}

or even (assuming a future conversion to ";"-terminated lists:

keys {
  foo.key { hmac-sha256; "secret"; };
  bar.foo { hmac-md5;    "turkey"; };
}

while slightly more characters, would still be more consistent with the rest. I.e. I'm basically ok with the keys as they are, except that the notation for keys is once again different from other constructs.

I.e. there are a few different alternatives for list syntax here:

"Full-blown":

remotes {
   peter { address ...; port ...; };
   pan   { address ...; port ...; };
}

"Current remotes" style:

remotes {
  peter { address ...; port ...; }
  pan   { address ...; port ...; }
}

"Key" style:

remotes {
   peter address ... port ...;
   pan   address ... port ...;
}

"Groups" style:

remotes {
   peter { ... , ... }
   pan   { ... , ... }
}

I really don't like the "groups" style. "Key" style is compact and easy to type, but harder to write the parser for. "remotes" style is not really a list. "Full-blown" does have the benefit of supporting recursion, i.e. having a list as an element in a list works fine. And the parser is simpler.

> 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 :)

I agree 1.4 is not the place, nor is a patch release. Let's take some time to think through as many config corners as possible so that you can try fixing them all in one go.

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

You're welcome.

Johan




More information about the knot-dns-users mailing list