Confused about a basic concept

Wed Jun 5 16:52:59 UTC 2013

Hi everyone,

Thanks for all the detailed responses, I think I have a better understanding of things now.  I was completely and totally confused about UDP/TCP.  I am just going to take a wild guess that doing iptables the way I described would've caused a bunch of problems...

After reading everything it looks to me like our hidden master configuration is basically okay, but by some of the best practices described, it could be better and easier to work with if we had a separate caching layer.

Also per Ben's description of DNSSEC we are going to need need different servers (caching/recursion servers) validating the DNSSEC keys (or whatever they're called).  I suppose we need to implement the caching layer if we intend to implement DNSSEC for our zone properly.

Regarding if we need a hidden master in the first place, I wish I could remember. :-)  It's been that way since I came here and I suspect it's a requirement we will simply have to keep using.

Thanks again for all the responses!
Bryan
On Jun 05, 2013, at 09:36 AM, "Carlos M. Martinez" <carlosm3011 at gmail.com> wrote:

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
> 
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130605/c4472d90/attachment-0001.html>