Best Practices for Authoritative Servers

[Baird, Josh]

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