Best Practices for Authoritative Servers

Chris Buxton cbuxton at menandmice.com
Thu Jan 31 23:15:02 UTC 2008


OK, yes, that's much clearer.

First, the resolving servers are authoritative for the zones, they're  
just not listed in the NS RRSet at each zone's apex. I'll call them  
stealth slaves for this discussion.

The decision of whether to list the advertised slaves in the stealth  
slaves' zone statements is up to you. However, the more redundancy,  
the better - there's no downside to listing the advertised slaves as  
masters after the primary master, other than continuing administration  
over time if servers move. But of course if one of four masters move  
to a new address, there's no perceptible immediate harm. So again, no  
downside, some upside, so it's probably a good idea to do what you  
have suggested.

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to which  
it is addressed. If the reader of this message is not the intended  
recipient, you are hereby notified that any retention, dissemination,  
distribution or copy of this e-mail is strictly prohibited. If you  
have received this e-mail in error, please notify us immediately by  
reply e-mail and immediately delete this message and all its attachment.



On Jan 31, 2008, at 2:58 PM, Baird, Josh wrote:

> Chris,
>
> Sorry for the terminology confusion.  Let me try to explain again:
>
> I have three authoritative servers: 172.20.1.1, 172.20.1.2,  
> 172.20.1.3.  These three servers are listed in the NS RRset for all  
> of my internal domains.  They do not allow recursion.  172.20.1.1's  
> zones are defined as masters:
>
> zone "blah.com"{
>         type master;
>         file "blah.com";
> };
>
> The other two authoritative servers contain zones that are slaves to  
> 172.20.1.1:
>
> zone "blah.com"{
>         type slave;
>         masters { 172.20.1.1; };
>         file "blah.com";
> };
> Now, I have several resolving/recursive servers that contain these  
> zones as well that devices use for resolution.  I could get the same  
> result by using stub zones, which I might change to in the future.   
> The zone statements on the resolving servers are as follows:
>
> zone "blah.com"{
>         type slave;
>         masters { 172.20.1.1; };
>         file "blah.com";
> };
> My question was, are the zone statements on the resolving servers  
> correct?  Should I include all three of the authoritative servers in  
> the masters { } substatement in the zone definitions of the  
> resolving servers?  Would there be any additional benefit of doing  
> this?
>
> Thanks -- hope this was a bit clearer,
>
> Josh
>
>
>
>
> From: bind-users-bounce at isc.org on behalf of Chris Buxton
> Sent: Thu 1/31/2008 5:14 PM
> To: John Wobus
> Cc: Bind-Users List
> Subject: Re: Best Practices for Authoritative Servers
>
> A server is authoritative for a zone if it has a complete, non-cached
> copy of the zone. In other words, if it is master or slave for that
> zone, and if the zone loads correctly, then it is authoritative. This
> is indicated by the 'aa' flag in a response from the server.
>
> It does not matter whether any NS record in the zone refers to the
> server by name. In fact, a name server doesn't necessarily know its
> own name(s), nor does it normally need to do so. I don't believe the
> BIND name server makes any attempt to figure out a name for its host
> machine, for example.
>
> - --
>
> To the original poster, I have to say, the question is unclear. In
> what way are you including name servers in the zone definitions? What
> zone definitions? It is always clearest to other people when
> discussing BIND if you use standard BIND terminology, even if that
> terminology does not come naturally to you. Therefore, you might
> discuss configuration items such as a "zone statement", a "masters
> substatement inside a slave zone statement", a zone's "apex
> records" (the records in the zone that have the same name as the zone
> itself - this one's not too commonly used, I think), etc.
>
> Chris Buxton
> Professional Services
> Men & Mice
> Address: Noatun 17, IS-105, Reykjavik, Iceland
> Phone:   +354 412 1500
> Email:   cbuxton at menandmice.com
> www.menandmice.com
>
> Men & Mice
> We bring control and flexibility to network management
>
> This e-mail and its attachments may contain confidential and
> privileged information only intended for the person or entity to which
> it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution or copy of this e-mail is strictly prohibited. If you
> have received this e-mail in error, please notify us immediately by
> reply e-mail and immediately delete this message and all its  
> attachment.
>
>
>
> On Jan 31, 2008, at 12:39 PM, John Wobus wrote:
>
> > This brings to mind a point I am confused about.  What causes bind9
> > to mark a query-response as authoritative?  Is it sufficient that  
> the
> > data come from a zone configured in this nameserver to be either
> > master or slave?  Or, does it matter if there exists an NS record  
> that
> > points
> > at the nameserver itself?  The specific point is whether, you can
> > run a caching server also that transfers some select zones, yet  
> answer
> > queries for names in these zones as if they were cached.
> >
> > I couldn't find a quick answer with google or any of my books.
> >
> > John
> >
> > On Jan 31, 2008, at 2:47 PM, Baird, Josh wrote:
> >
> >> I currently have three authoritative (non-recursive) internal
> >> nameservers (these servers are listed in the NS RRset for all of my
> >> internal domains).  I also have several resolving/caching servers
> >> which
> >> hold the slave zones for these authoritative servers.  On these
> >> resolving servers, the zone definitions only define one of the  
> three
> >> authoritative servers.  Would it be best to include all three
> >> authoritative servers in the zone definitions for the slaves?  What
> >> benefit would I gain?  Is there even a point in having three
> >> authoritative servers, when only one is listed in the zone
> >> definitions
> >> for the slaves?
> >>
> >>
> >> I appreciate any input.
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Josh
> >>
> >>
> >>
> >
> >
>
>
>



More information about the bind-users mailing list