Inheritance from globally-set options to zone statements

[Simon Dodd]

Thanks, Kevin. I have another question, regarding the serial number.
Albitz/Liu (Ed.4), pp151-152, states that while one CAN place a period in a
serial number, BIND 4x interprets the serial number by treating the number
trailing a period as a multiplier for the number before the period, then
appends the original multiplier, leading to some weird issues (e.g. to BIND
4, 1.1 > 1.10). What neither the Albitz/Liu book, nor a quick web search,
has made clear is whether BIND 9x reproduces this behaviour. 

The specification handed down to me is that we want to be using the format
date.customer number.revision number, e.g. 20040721.6651.02. If BIND 9x
behaves the same way as BIND 4 does in this regard (which is my principal
question), then (and here's my comprehension check question) surely the
proposed serial number convention couldn't possibly work, because BIND will
multiply the numbers way above and beyond the 32-bit maximum
(20040721.6651.02, for example, I'm thinking would become
11111000010001100000010111101101010110, which is 7 characters too long).

Regards,
Simon

> -----Original Message-----
> From: bind-users-bounce at isc.org 
> [mailto:bind-users-bounce at isc.org] On Behalf Of Kevin Darcy
> Sent: Tuesday, July 20, 2004 4:46 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: Inheritance from globally-set options to zone statements
> 
> Simon Dodd wrote:
> 
> >I'm sorry if this is an obvious question, and it may be more a 
> >nomenclature problem making my searches fail than anything else.
> >
> >I'm setting up a BIND9 server, and my named.conf will have the 
> >following options set:
> >
> >	options {
> >      	  directory "/var/named";
> >	        version "8.3.3-REL-NOESW";
> >      	  allow-transfer{"none"};
> >	        allow-update{"none"};
> >	        recursion no;=20
> >	};
> >
> >Am I correct in assuming that because I've set 
> allow-update{"none"} in 
> >the global options, I won't need to include this in the zone 
> >information, because inheritance will apply that stricture 
> to each zone?
> >
> >So in an example zone:
> >
> >	zone "0.0.127.in-addr.arpa" in{
> >		type master;
> >		file "localhost.rev";
> >		allow-update{none;};
> >	};
> >
> >Is the line allow-update{none;} going to be superfluous because I've 
> >already declared in the global options that NO zones can be updated?
> >
> >Sorry to ask obvious questions, but I want to get this right before 
> >putting in 200-odd zones statements!
> >
> Yes, there's no point in duplicating in a zone statement what 
> has already been set globally.
> 
> Also, in the specific case of "allow-update { none; };", 
> there's no point in setting that globally either, since it's 
> the default setting. 
> (The same does not hold true for "allow-transfer { none; };" 
> or "recursion no;", however).
> 
> - Kevin
> 
> 
> 
> 
>