[bind10-dev] Zone loading requirements, take 1

[Stephen Morris]

On 02/03/12 10:40, Shane Kerr wrote:
> All,
>
> In the spirit of old-style waterfall software engineering, we are going
> to be doing more requirements documents. We know we need work on our
> zone loader, so I've taken the liberty of typing some requirements up.
> Here's a link to the current draft:
>
> http://bind10.isc.org/wiki/ZoneLoadingRequirements
>
> It turns out that loading a DNS master zone file is... non-trivial. :(

Comments, a number of which may be rather pedantic:

 > 3.1.1 C++ data source
 > The loader will use the BIND 10 C++ data source as the location where 
data is stored.
Suggest: "where data is to be stored".  At the moment, "location" could 
be understood to be the location at which the source data is stored.

 > 3.2.1 Zone loading any time
 > It must be possible to load a zone during runtime.
I would add a requirement as to what to do in the case of a fatal error, 
e.g.

3.2.1.1 Action in case of error
If an error is encountered during a load, existing data in the target 
data source must not be changed.

(This is especially important if loading data into a running system.)

 > 3.2.3 Zone loading from stream
 > It must be possible to load a zone from an input stream.
Probably a design issue, but what constitutes the end of the stream? 
(Important if the new requirement about action in case of an error is 
accepted; how do we know when we have read the entire source of a zone 
and that there are no fatal errors?)

 > unique issue number for this loading attempt
I'm not clear what this is - "issue" seems to refer to a problem, hence 
each "issue identifier".  But a unique number for this loading attempt 
appears to indicate a unique number generated for each instance of an 
error message.

 > 3.3.5 Blank Lines
Should this requirement also state that blank lines are ignored?

 > 3.3.6 $ORIGIN control entry
How about adding a requirement that if $ORIGIN is specified, it is a 
fatal error for the argument not to be a fully-qualified domain name? 
(I am thinking of the case back in 2009 where the trailing "." was 
missed in the zone file of a TLD ...)

 > 3.3.8 $INCLUDE control entry on streams
I can see Michal's argument for allowing this on the basis that a stream 
might be a pipe from a local program, but I think it could be 
error-prone. For example, what if the file specified were something like 
"./common.txt" - the file picked up might not be the one intended.

 > 3.3.20 Broken parenthesis
 > Parenthesis do not nest. A second open paren before a close paren is 
an issue, and usually considered a warning. If treated as a warning, it 
is ignored.
Being nit-picking:
s/arenthesis/arentheses/g
s/paren /parenthesis /g

 >3.4.2 SOA singleton
 >If it appears again with a different value, it is considered an issue 
and usually treated as an error.
By same "value", I assume "same domain name"?

If we take the restricted view that these requirements are for a zone 
loader only, this is perfectly correct.  However, as it stands, this 
requirement appears to rule out the use of a single file containing 
multiple zones.

Perhaps we should add a section about loading multiple zones?  In this 
case, I think it would be fair to require that the SOA be the first RR 
in each zone, and that encountering an SOA with a different name marks 
the end of one zone and the start of the next.

 > 3.4.3 Missing glue
Ambiguous phrasing - the first sentences recognises that glue is not 
required for all delegations, then the remainder of the section ignores 
that and states that missing A/AAAA records mean that the delegation is 
broken.


Stephen