Confused about a basic concept

[Carlos M. Martinez]

The 'hidden master' setup is a very good strategy for a number of reasons.

I think the original description only derails a bit when using the term
'authoritative':

> I'm being told "our authoritative DNS
>>     servers should not receive any queries", as well as "DNS slaves
>>     respond to queries".  These statements seem like a conflict to me,
>>     but maybe I'm simply confused?

Many people confuse authority with master/slave. Slaves will also
respond authoritatively. In fact, by just looking at a DNS response is
hard to tell which NS points to the actual master, if any (in the case
of the hidden master, no NS actually points to a master).

cheers!

~Carlos

On 6/5/13 11:18 AM, Ben Croswell wrote:
> Everything you listed is pretty close to accurate.
> A couple points of clarification.
> 
> 8) The master needs UDP/TCP 53 open to the slaves.  Before a zone
> transfer can happen the slave needs to get the SOA RR from the master to
> see if the serial number has changed.  This normally happens over UDP
> 53(see my point on 9).  So The slaves need to also be in the allow-query
> ACL on the master, if they cant query for SOA they can never determine
> the serial number and cant transfer.
> 9) You should always have UDP/TCP 53 open to DNS servers.  "Normal"
> queries happen on UDP 53, but if an answer is too large to fit in a
> single packet the answer will be truncated and the TC bit will be set.
>  This bit tells the client they didnt get the "full" answer and that
> they may want to try the same query via TCP.
> 
> On you last points you are pretty much spot on the answer but are
> wondering the mechanics. Most best practices state that you should not
> have recursion and authoritative on the same DNS server. That is a
> should, but not a must.  What you said is the normal answer you run DNS
> servers that host zones, and you run DNS servers that serve direct
> client queries. The client caching DNS servers would need to know where
> your authoritative servers are via NS records or forwarding.
> 
> One big reason for the split is DNSSEC. An authoritative DNS server cant
> validate DNSSEC for a query sent directly to it from a client.  There
> has to be another step in between.  For instance if I ask you if you are
> Bryan and you say yes, why should I believe you.  However, if I ask a
> trusted friend if you are Bryan I will believe you because there is
> third party verification.
> 
> 
> 
> On Wed, Jun 5, 2013 at 10:02 AM, Bryan Harris <bryanlharris at me.com
> <mailto:bryanlharris at me.com>> wrote:
> 
>     Hi all,
> 
>     I think I may be confused about a very basic DNS concept.  Sorry if
>     this has been asked before.
> 
>     1. I have a master and two slaves.
>     2. The master server is the SOA for my zone.  The SOA record points
>     to the master server.
>     3. Each of the two slaves are authoritative for my zone.
>     4. There are 2 NS records for my zone.  The first NS = slave1 and
>     the second NS = slave2.
>     5. The Master server is not listed in the NS records for my zone.
>     6. The master does not receive any queries from the clients.
>     7. The slaves receive queries from the clients.
>     8. The master -> slaves relationship is via tcp/53 (notifies & zone
>     transfers)
>     9. The slaves -> clients relationship is via udp/53 (queries)
> 
>     Is this correct so far?  I'm being told "our authoritative DNS
>     servers should not receive any queries", as well as "DNS slaves
>     respond to queries".  These statements seem like a conflict to me,
>     but maybe I'm simply confused?
> 
> 
>     I don't see how a slave could respond to a query unless it's
>     authoritative.  The only thing I can imagine is adding some more
>     caching servers just for queries and have them forward+recurse to
>     the authoritative slave servers (but they're not slaves themselves).
>      But even in that case, the authoritative servers would still need
>     to respond to queries, no?  Otherwise how would the caching servers
>     get any answers in the first place?
> 
>     Bryan
> 
> 
>     _______________________________________________
>     Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>     unsubscribe from this list
> 
>     bind-users mailing list
>     bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> 
> -- 
> -Ben Croswell
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>