On Fri, 26 Oct 2018 10:52:17 -0400
Kevin Darcy <kevin.da...@fcagroup.com> wrote:
> My basic rule of thumb is: use forwarding when connectivity
> constraints require it. Those constraints may be architectural, e.g.
> a multi-tiered, multi-layer network for security purposes, or may be
> the result of screwups or unintended consequences, e.g. a routing
> blackhole. Use forwarding to get around those blockages.
>
> Now, if one thinks one can use forwarding for efficiency/performance
> ("forward first") as opposed to using it for connectivity ("forward
> only"), then do so based on *documented* , *observed* evidence, not
> just on assumptions or conjecture. A lot of folks just take for
> granted that forwarding to a rich cache will speed up their lookups.
> Maybe it will, maybe it won't -- MEASURE IT.
>
> Also, bear in mind that while forwarding to a rich cache may help your
> *best* case, and maybe your *average* case, it may hurt your *worst*
> case, since in the case of a cache miss, you have your wasted
> forwarding attempt *plus* however long it takes to fetch the data
> yourself. Your worst case is going to be the one that causes apps to
> time out, support calls, tickets, everyone blaming the DNS
> infrastructure, etc. You've been warned.
>
>
> - Kevin
kinda my points exactly. while forwarding works, and is a useful tool.
it is not a delegation or an authoritative zone. so, building critical
name spaces with it should be avoid unless you have to. it not
something you plan upfront with. thats just silly.
>
> On Fri, Oct 26, 2018 at 10:41 AM Bob Harold <rharo...@umich.edu>
> wrote:
>
> >
> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost <n6gh...@gmail.com> wrote:
> >
> >> Hi All,
> >>
> >> have two questions first, I am not a huge fan of using forwarding
> >> zones and our "load balancing" team, has there zone delegated to
> >> them in a way that needs an internal forward zone to work properly
> >> on the inside and not rely on on internet POP.
> >>
> >> I want to move a core namespace to the load balancer but i want
> >> them to let me assign them a new zone thats internally
> >> authoritative and use it as the LB domain.
> >>
> >> which would be:
> >> cname name.domain.com -> newname.newzone.domain.com
> >>
> >> they want:
> >> cname name.domain.com -> newname.oldzone.domain.com
> >>
> >> old zone is directly delagated from outside to them so we need an
> >> internal forward zone for it. i dont want to rely on that.
> >>
> >> any thoughts on this? what can i use to present to management to
> >> win this?
> >>
> >
> > The users should never see the domain that the CNAME points at, it
> > is just an internal name used by DNS. If they can change where "
> > newname.oldzone.domain.com" points more easily than "
> > newname.newzone.domain.com" then they might have a valid reason to
> > want it. Otherwise, newname.newzone.domain.com will be a faster
> > and more reliable choice.
> >
> > Definitely avoid forwarding when possible. It causes slower
> > lookups and more points of failure. (There will occasional be
> > times when it has some advantage, or requirement.)
> >
> > --
> > Bob Harold
> >
> >
> >>
> >> next, we where a bind shop but switched to infoblox for some stuff
> >> and now out grew it. and are going back to bind.
> >>
> >> but we started using the dns firewall part of it and they actually
> >> really liked it. any ideas for domain blacklisting? via some sort
> >> of feed etc? what is everyone doing for that sort of thing?
> >>
> >> thanks
> >>
> >> -N6Ghost
> >> _______________________________________________
> >> 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
> >
>
_______________________________________________
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
