Inheritance from globally-set options to zone statements

[BOG]

Greetings,
 Sorry to butt in here. But if your version 9 servers should ever communicate
with a BIND4 server, you will still cause the problem with that version 4
server. If I'm not mistaken, a couple of the root servers are still using v.4.x.

Just a thought I felt might be worth mentioning.

Best wishes.

"Simon Dodd" <simon.dodd at joink.com> wrote in message news:<cdmm0h$2des$1 at sf1.isc.org>...
> 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
> > 
> > 
> > 
> > 
> >