2 Questions - forward zone and DNS firewalling

[Joe Dahlquist]

N6Ghost,

Re: DNS Firewall options on bind, a shameless plug for Threatstop.com and
the first you should investigate.

Other sources of RPZ with quality data you can look at: Farsight, SURBL,
Spamhaus

Regards,
Joe Dahlquist






On 10/26/18, 9:49 AM, "bind-users on behalf of N6Ghost"
<bind-users-bounces at lists.isc.org on behalf of n6ghost at gmail.com> wrote:

>On Fri, 26 Oct 2018 10:52:17 -0400
>Kevin Darcy <kevin.darcy at 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 <rharolde at umich.edu>
>> wrote:
>> 
>> >
>> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost <n6ghost at 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 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
>> >  
>> 
>
>_______________________________________________
>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