Inheritance from globally-set options to zone statements

[Barry Margolin]

In article <cfbie6$2t1d$1 at sf1.isc.org>, junk at 1command.com (BOG) wrote:

> 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.

When servers communicate with each other, they use the internal 
representation of the serial number, which is just a 32-bit number.  The 
dotted notation is only used when the server is parsing the zone file, 
and it never appears on the wire.

> 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
> > > 
> > > 
> > > 
> > > 
> > >

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***