8 Srp
2013
8 Srp
'13
22:10
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).
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