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