Best Practices for Authoritative Servers

[Chris Buxton]

Umm... No.

A server is authoritative if it says it is. A server will declare  
itself to be authoritative if it has an authoritative copy of the  
zone, either through a local source or via zone transfer from a master  
server.

The OP's question has nothing to do with the authority claims of the  
advertised slaves. Rather, he asks if there's any upside to listing  
them as master servers for the stealth slaves. The answer is probably  
yes, there is a marginal upside, but this depends largely on specific  
circumstances and the perceived cost of long-term maintenance of  
multiple masters in a masters list.

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 3:10 PM, david brett wrote:

> The short answer is yes, all three servers need to be included if  
> all three are to be
> authoritative servers
>
> david
>
> --- "Baird, Josh" <jbaird at follett.com> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>       
> ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
>