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 thi
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: Enforcing minimum TTL...
On 10/26/2018 11:11 AM, Brian Greer wrote: You could setup a DNSMASQ / Unbound service as a front end, which then queried bind. Both of those allow the setting of a minimum TTL (max of 3600 seconds in DNSMASQ). It cannot be done with bind by itself. *nod* I was aware that there were other resolvers that could do this. But my preference is to do it with BIND if possible. Thank you for confirming what others have said, and what I thought about other resolvers. -- 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: Enforcing minimum TTL...
You could setup a DNSMASQ / Unbound service as a front end, which then queried bind. Both of those allow the setting of a minimum TTL (max of 3600 seconds in DNSMASQ). It cannot be done with bind by itself. > On Oct 26, 2018, at 11:41, Grant Taylor via bind-users > wrote: > > On 10/26/2018 01:23 AM, Matus UHLAR - fantomas wrote: >> there is not. > > Thank you, Matus and Tony, for the direct answer. > >> using short TTLs is very risky, and forcing minimum TTL is apparently not >> way to work around. > > Understood. - I /think/ that I'm somewhat (dangerously?) informed and > /choosing/ my own poison. Maybe. > > To be clear, I'm not wanting to artificially lower the TTL. I want to > respect any and all TTLs that are longer than my locally administered minimum. > > My motivation for setting the minimum TTL (while fully accepting any and all > risk and associated responsibility there for) is to thwart DNS Rebinding. Or > to at least make it much more difficult (as in longer than my artificial > minimum TTL) to do. > > > > -- > Grant. . . . > unix || die > > ___ > 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: Enforcing minimum TTL...
On 10/26/2018 01:23 AM, Matus UHLAR - fantomas wrote: there is not. Thank you, Matus and Tony, for the direct answer. using short TTLs is very risky, and forcing minimum TTL is apparently not way to work around. Understood. - I /think/ that I'm somewhat (dangerously?) informed and /choosing/ my own poison. Maybe. To be clear, I'm not wanting to artificially lower the TTL. I want to respect any and all TTLs that are longer than my locally administered minimum. My motivation for setting the minimum TTL (while fully accepting any and all risk and associated responsibility there for) is to thwart DNS Rebinding. Or to at least make it much more difficult (as in longer than my artificial minimum TTL) to do. -- 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: Enforcing minimum TTL...
Grant Taylor via bind-users wrote: > Is there a way to enforce a minimum TTL? Not without changing the code along the lines of https://salsa.debian.org/dns-team/bind9/blob/master/debian/patches/10_min-cache-ttl.diff Tony. -- f.anthony.n.finchhttp://dotat.at/ champion the freedom, dignity, and well-being of individuals ___ 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: Enforcing minimum TTL...
On 10/25/2018 09:27 PM, Mark Andrews wrote: Use a browser that maintains its own address cache tied to the HTTP session. That is the only way to safely deal with rebinding attacks. Rebinding attacks have been known about for years. There is zero excuse for not using a browser with such protection. On 25.10.18 21:50, Grant Taylor via bind-users wrote: That is sound advice. Unfortunately it does not answer my question of is there a way to enforce a minimum TTL (with BIND). there is not. Nor does it protect less intelligent browsers or (IoT) devices. using short TTLs is very risky, and forcing minimum TTL is apparently not way to work around. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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: forward zone
On 26.10.18 00:12, Frédéric Lochon wrote: I'm new to this list, but I use BIND for quite some time. I have a machine running BIND which is authoritative for some domains I own and is the nameserver for my home network. Thus: - BIND answers to any query from my home network - BIND answers to queries from the whole planet Earth for the domains I own This is because: - in "options", I have (among others) allow-query { trusted; }; - in each domain zone I have allow-query { any; }; Today, I just set-up a new zone of type "forward" but I have trouble to make it work properly: - my home network is allowed to send queries because it is "trusted" - nobody from outside my home network is allowed to send queries because it is not "trusted" As you can't have "allow-query" in a zone of type "forward", I don't find any nice solution. You can and you also need to add allow-query for it. However, since forward zone is not stored locally, all requests for it are fowarded, so you must allow recursion for the zone, if you want to allow everyone to use it. Now I have a question, why do you want people from outside to access forward zone? can't you slave it instead? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.* ___ 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