does zone trump forward?

Kevin Darcy kcd at chrysler.com
Mon Jun 3 19:39:42 UTC 2013


Why would you use forwarding over links that are "neither fat nor 
reliable"? Are you a masochist? Replication of the data is much 
recommended over such links...

As for your "pecking order", what distinction are you drawing between 
forwarding and recursion? Forwarding is recursive. The high-level 
distinction is between having the data authoritative locally and not 
having it authoritative locally. If you want to make a finer distinction 
within the not-locally-authoritative case, then make the distinction 
between recursive (e.g. forwarding) and iterative (e.g. stub, or 
delegation from an internal root zone).

                                     - Kevin
On 6/3/2013 2:53 PM, Alan Shackelford wrote:
>
> I agree with Len. Whenever we merge a new location into our network, 
> and the circuit is neither fat nor reliable, I make their DNS forward 
> queries for our internal zones to us, keep authority for their own 
> zones, and do recursion for everything else. This allows us to serve 
> the users as we slowly homogenize the whole mess. The "pecking order" 
> seems to be authoritative first, forward second, and recursion last.
>
> Alan
>
> Alan V. Shackelford                             Senior Systems 
> Software Engineer
>
> The Johns Hopkins University and Johns Hopkins Medical Institutions
>
> Baltimore, Maryland USA ashackel at jhmi.edu <mailto:ashackel at jhmi.edu> 
> 410-735-4773
>
> *From:*bind-users-bounces+ashackel=jhmi.edu at lists.isc.org 
> [mailto:bind-users-bounces+ashackel=jhmi.edu at lists.isc.org] *On Behalf 
> Of *Leonard Mills
> *Sent:* Sunday, June 02, 2013 3:29 PM
> *To:* Jonathan Reed; bind-users
> *Subject:* Re: does zone trump forward?
>
> As I understand  AUTHORITATIVE trumps anything.  For example, from an 
> inside intranet name server forward the root (".") to somewhere on 
> your edge, sprinkle in a few internal-only authoritative zones, and 
> enjoy.  This is certainly not the only choice, but it functions pretty 
> well.
>
> Len
>
>     ------------------------------------------------------------------------
>
>     *From:*Jonathan Reed <cronstate at gmail.com
>     <mailto:cronstate at gmail.com>>
>     *To:* bind-users <bind-users at lists.isc.org
>     <mailto:bind-users at lists.isc.org>>
>     *Sent:* Sunday, June 2, 2013 12:10 PM
>     *Subject:* does zone trump forward?
>
>
>
>     I've only ever come across bind configs where forwarding is in
>     place to locate certain zones, then all other queries are handled
>     by either recursion or authoritatively. But what about the other
>     way around, where I'm master for a few zones but forward the rest?
>     Consider this:
>
>     view "the-internet" {
>
>       recursion no;
>
>       type forward;
>
>       forwarders { 8.8.8.8; };
>
>       zone "example.com <http://example.com/>" {
>
>           type master
>
>           file "example.com <http://example.com/>"
>
>       ......
>
>     }
>
>     Whats confusing me is the implied configuration setting of forward
>     first when the forward statement is used. If it truly forwards
>     first, then I see an odd logical scenario happening. All queries
>     are sent to the forwarder before being handled by localhost. Then,
>     once the forwarder recognizes that I'm the master of example.com
>     <http://example.com/>, why would a loop not occur if the forwarder
>     matches this view?
>
>     To ask the question another way, does the zone statement take
>     precedence on matching queries over any forwarding?
>
>     Thanks
>
>
>     _______________________________________________
>     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
>
>
>
> _______________________________________________
> 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/20130603/bd402485/attachment.html>


More information about the bind-users mailing list