Re: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 17:37:47 +
Joe Dahlquist wrote:
> 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"
>
> wrote:
>
> >On Fri, 26 Oct 2018 10:52:17 -0400
> >Kevin Darcy 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
> >> wrote:
> >>
> >> >
> >> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost
> >> > 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
Thanks will check it out!
> >> >
> >> >
> >> >>
> >> >> 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
Re: 2 Questions - forward zone and DNS firewalling
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"
wrote:
>On Fri, 26 Oct 2018 10:52:17 -0400
>Kevin Darcy 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
>> wrote:
>>
>> >
>> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost 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
Re: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 10:52:17 -0400
Kevin Darcy 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
> wrote:
>
> >
> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost 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
Re: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 10:40:40 -0400 Bob Harold wrote: > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost 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. I agree with this, basically the deal is we have a parent who owns our primary DNS zone which we hang off of. there DNS NS is outside of our network. so, all of our zones are delegated to us. (we have a pretty big DNS infrastructure) and we then create our own namespaces, zones whatever we need. we have our own public and internal NS. My issue with the load balancer is they went around that and had the parent delegate to them... and had us, create forward to them. to prevent lookups from relying on need to always go to parent. if we where authoritative no outside lookup would be needed. I think thats a bad way to do it. and I want to avoid, having our critical namespaces (ldap and ldaps) use it like that. > > 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.) > ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 09:46:39 -0600 Grant Taylor via bind-users wrote: > On 10/26/2018 01:08 AM, N6Ghost wrote: > > maybe its just old habits, > > Fair enough. I know that I have plenty of my own old (¿bad?) habits > too. > > > i think its a bad idea to build your infrastructure in a way the > > needs forward zones to work. not when you can build it with proper > > delegation. > > > i just think when building namespaces proper delegation should be > > used and forward zones should be avoided if you can. > > Ah. > > I see forward zones, and slaving, as tools to help enable restricted > environments work. Specifically where there is proper delegation as > seen by the larger organization and / or the Internet. I've had a > few departments where they were not allowed to access anything > outside their network. So their local DNS server (running on a > multihomed bastion) would slave or forward zones from the larger > organizational namespace. The limitation was imposed by the small > department, not an issue with the overall namespace. > > > i agree with this, forward is a use it you must, avoid if you can. but valable tool for all sorts of wacky use cases. but if your planning out critical namespaces... you should not PLAN on forward zones. unless you have to. thats just a micky mouse way of doing it. your just assuming to much with forward zones. ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 09:50:31 -0600
Grant Taylor via bind-users wrote:
> On 10/26/2018 08:52 AM, Kevin Darcy 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.
>
> Agreed all around.
>
> Is there any reason to not prefer to slave the zone instead of
> forwarding? I would think that would provide better performance
> results and lessen the requirement for always on nature of the
> forwarded target.
its a netscaler load balancer, the zone name is the zone that the
netscaler "owns", so it can create LB records off of it that it owns and
can control.
so we cant slave it, it had to be a forward. i called this out years
ago when this was being built and said it was a bad idea and that we
should do proper delegation and plan it out. by the time everything was
said and done it was, said it was to late to change it... to work with
or around it doh...
>
> > 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.
>
> Duly noted. Thank you for articulating.
>
>
>
___
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
Re: 2 Questions - forward zone and DNS firewalling
On 10/26/2018 08:52 AM, Kevin Darcy 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.
Agreed all around.
Is there any reason to not prefer to slave the zone instead of
forwarding? I would think that would provide better performance results
and lessen the requirement for always on nature of the forwarded target.
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.
Duly noted. Thank you for articulating.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
___
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
Re: 2 Questions - forward zone and DNS firewalling
On 10/26/2018 01:08 AM, N6Ghost wrote: maybe its just old habits, Fair enough. I know that I have plenty of my own old (¿bad?) habits too. i think its a bad idea to build your infrastructure in a way the needs forward zones to work. not when you can build it with proper delegation. i just think when building namespaces proper delegation should be used and forward zones should be avoided if you can. Ah. I see forward zones, and slaving, as tools to help enable restricted environments work. Specifically where there is proper delegation as seen by the larger organization and / or the Internet. I've had a few departments where they were not allowed to access anything outside their network. So their local DNS server (running on a multihomed bastion) would slave or forward zones from the larger organizational namespace. The limitation was imposed by the small department, not an issue with the overall namespace. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: 2 Questions - forward zone and DNS firewalling
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
On Fri, Oct 26, 2018 at 10:41 AM Bob Harold wrote:
>
> On Thu, Oct 25, 2018 at 4:34 PM N6Ghost 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
Re: 2 Questions - forward zone and DNS firewalling
On Thu, Oct 25, 2018 at 4:34 PM N6Ghost 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
Re: 2 Questions - forward zone and DNS firewalling
On 26/10/2018 08:08, N6Ghost wrote: > maybe its just old habits, i think its a bad idea to build your > infrastructure in a way the needs forward zones to work. not when you > can build it with proper delegation. > > i just think when building namespaces proper delegation should be used > and forward zones should be avoided if you can. There's also static-stub you might like to look at instead of forwarding. Details in the ARMs for current versions of BIND. https://kb.isc.org/docs/aa-01031 It's intended for the situation where you want your resolver to query authoritative servers that you know are a better choice than the ones advertised in a zones NS RRset, perhaps because you have an internal-only route to them, or something like that. ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On Thu, 25 Oct 2018 15:57:48 -0600 Grant Taylor via bind-users wrote: > On 10/25/18 2:34 PM, N6Ghost wrote: > > 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. > > Can I ask why you don't like forwarded zones? > > Is it a possibility to slave the zone off of them instead of > forwarding to them? > > > any thoughts on this? what can i use to present to management to win > > this? > > I think it comes down to pros and cons of each: existing zone + > forwarders vs new zone. > > IMHO it's perfectly fine to have dislikes. You just need to be able > to explain them and / or set them aside if someone explains their > position better. > > > 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? > > Response Policy Zone(s) are what you want. I thought that's how > Infoblox did it themselves. Maybe they were using the newer Response > Policy Service. - It's my understanding that the RPS API is open > and documented. It's just that there aren't any Open Source / free what about nonfree feeds? > RPS services. > > IMHO: RPS is similar to milter for Sendmail or WCCP for caching > proxies. > > > ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On Thu, 25 Oct 2018 15:57:48 -0600 Grant Taylor via bind-users wrote: > On 10/25/18 2:34 PM, N6Ghost wrote: > > 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. > > Can I ask why you don't like forwarded zones? maybe its just old habits, i think its a bad idea to build your infrastructure in a way the needs forward zones to work. not when you can build it with proper delegation. i just think when building namespaces proper delegation should be used and forward zones should be avoided if you can. > > Is it a possibility to slave the zone off of them instead of > forwarding to them? > > > any thoughts on this? what can i use to present to management to win > > this? > > I think it comes down to pros and cons of each: existing zone + > forwarders vs new zone. > > IMHO it's perfectly fine to have dislikes. You just need to be able > to explain them and / or set them aside if someone explains their > position better. > > > 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? > > Response Policy Zone(s) are what you want. I thought that's how > Infoblox did it themselves. Maybe they were using the newer Response > Policy Service. - It's my understanding that the RPS API is open > and documented. It's just that there aren't any Open Source / free > RPS services. > > IMHO: RPS is similar to milter for Sendmail or WCCP for caching > proxies. > > > ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On Thu, Oct 25, 2018 at 2:57 PM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 10/25/18 2:34 PM, N6Ghost wrote: > [snip] > > > 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? > > Response Policy Zone(s) are what you want. I thought that's how > Infoblox did it themselves. Yes, Infoblox’s DNS implementation is a wrapper around BIND and DNS Firewall is just straight up BIND RPZ underneath. If you still have Infoblox around, you can dump the BIND configuration at the CLI and see exactly what is going on underneath it all. ___ 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
Re: 2 Questions - forward zone and DNS firewalling
On 10/25/18 2:34 PM, N6Ghost wrote: 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. Can I ask why you don't like forwarded zones? Is it a possibility to slave the zone off of them instead of forwarding to them? any thoughts on this? what can i use to present to management to win this? I think it comes down to pros and cons of each: existing zone + forwarders vs new zone. IMHO it's perfectly fine to have dislikes. You just need to be able to explain them and / or set them aside if someone explains their position better. 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? Response Policy Zone(s) are what you want. I thought that's how Infoblox did it themselves. Maybe they were using the newer Response Policy Service. - It's my understanding that the RPS API is open and documented. It's just that there aren't any Open Source / free RPS services. IMHO: RPS is similar to milter for Sendmail or WCCP for caching proxies. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
