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-boun...@lists.isc.org on behalf of n6gh...@gmail.com> wrote: >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 _______________________________________________ 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