Confused about a basic concept
Carlos M. Martinez
carlosm3011 at gmail.com
Wed Jun 5 14:36:11 UTC 2013
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
>
More information about the bind-users
mailing list