ndc error on 188.8.131.52-P5 / AIX4.3.2
mathias at staff.singnet.com.sg
Wed Dec 8 01:54:15 UTC 1999
On Tue, 7 Dec 1999, Paul A Vixie wrote:
| Date: Tue, 07 Dec 1999 17:36:35 -0800
| From: Paul A Vixie <vixie at mibh.net>
| To: bind-workers at isc.org
| Subject: Re: ndc error on 184.108.40.206-P5 / AIX4.3.2
| > 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
| requirements originally.
I know, but I think that the requirements for named are different. An authoritative
nameserver effectively considers each zone separately, so it should be able
to continue with healthy zone configs even if others are faulty. I just think
that using a config file syntax that barfs in the face of a single wrongly placed
syntax element unsuited for a nameserver.
| > 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.
While not easy, it should be possible to improve it. Maybe like this:
1. check for/eliminate all comments
2. check for errors in OPTIONS, ACL, LOGGING etc
3. examine each 'zone' statement separately, taking the presence of a
new 'zone' keyword as beginning of a new statement (if by then the
current statement is not complete, consider that an error for that zone only).
Ignore superfluous braces unlessthey affect the syntax withing the zone statement.
| > 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?
Yes, we are working on that, and while that takes away a lot of
possibility for errors, it does not guarantee error-free zonefiles. What's more,
the generation etc will likely be running at night, when there is no-one
(awake enough) to check a few-thousand-zone config file...
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | mathias at koerber.org
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
More information about the bind-workers