Inheritance from globally-set options to zone statements
Barry Margolin
barmar at alum.mit.edu
Wed Aug 11 04:03:55 UTC 2004
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 ***
More information about the bind-users
mailing list