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 <bryanlhar...@me.com > <mailto:bryanlhar...@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@lists.isc.org <mailto:bind-users@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
