ndc error on 184.108.40.206-P5 / AIX4.3.2
Paul A Vixie
vixie at mibh.net
Wed Dec 8 01:36:35 UTC 1999
> Hmm. The more I think about it it would be nice, but not the ultimate goal.
> So 'fine' would have been an overstatement.
> To say it in other words: If the syntax of named.conf makes it mostly
> impossible to
> - differentiate between different error severities
> - recover from missing syntax elements in one directive 'zone' so
> that other directives can still be processed, to allow at least
> some of the functionality w.o rendering the whole named hors de
> combat (sp?)
> why was that configuration file structure/syntax chosen?
The current structure is optimized for flexibility. We need to be able to
add new keywords and options and directives without invalidating existing
syntax elements. We patterned our syntax after GateD's, which had the same
> A 'zone' statement can not be part of any other statement. Thus, cannot
> the parser be rewritten such that it considers each zone statement
> separately. If there is a problem in one zone statrement (missing/superfuous
> '}', spelling mistakes etc) and ffwd to the next zone statement to continue?
How would we recognize the next "zone" directive if there were a missing "}"?
Should we just scan tokens until we find the word "zone" standing alone by
itself, even if it's standing in the middle of a comment? (What if there's
an unclosed comment?) This is a recipe for even more undefined behaviour.
> I agree that errors in the ACL, LOGGING, OPTIONS etc should be considered
> fatal, but inside a zone-statement not.
I'll get right on that, but first I have to change the speed of light. :-).
More seriously, have you considered generating your named.conf file from a
Perl script, which looks at either a bunch of zone-named files in some
directory, or at a SQL database, or some other externally verifiable source,
and generates provably correct named.conf syntax?
More information about the bind-workers