Hi all,
I have a RPZ setup to whitelist several domains.
The issue I am facing is that, even though domains are blocked, the cashing
DNS server still proceeds to resolve the domain. The bahavior that I was
hoping to see is the server to not bother resolving the domain if the RPZ
policy replies wit
Hello Alex,
> Is this expected behaviour? Is there any way to make the server avoid
> proceeding with the resolution, when the initial client requests is
> blocked?
Yes, this is expected behavior. You need "qname-wait-recurse no" to
change the behavior:
response-policy {
zone "rpz-whitelist-
Hi Daniel,
Thank you very much!
It was exactly what I was looking for.
On Tue, Feb 12, 2019 at 4:03 PM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:
>
> Hello Alex,
>
> > Is this expected behaviour? Is there any way to make the server avoid
> > proceeding with the resolution, when the
Hello.
Am Donnerstag, den 07.02.2019, 10:32 -0300 schrieb Roberto Carna:
> Dear, I have Bind 9.10.3 as our private DNS service with two views,
> one of them let some clients to query linux.org domain from Internet
> forwarding the query to our Bind resolvers, but the query is refused
> by our priv
Define root zone.
Delegate teamviewer.com from root zone.
Define teamviewer.com as "type forward".
"recursion no" is incompatible with *any* type of forwarding or iterative
resolution. Should only be used if *everything* you resolve is from
authoritative data, i.e. for a hosting-only BIND instan
On 02/07/2019 07:02 PM, Paul Kosinski wrote:
I haven't analyzed the details and pitfalls, but could a Web proxy
mechanism of some sort be of help? In particular, rather than having
your users directly access "teamviewer.org" (or whatever), have them to
access "teamviewer.local", which is resolv
On 02/12/2019 03:45 PM, Kevin Darcy wrote:
"recursion no" is incompatible with *any* type of forwarding or
iterative resolution. Should only be used if *everything* you resolve is
from authoritative data, i.e. for a hosting-only BIND instance.
I know it's not yet an option and won't yet work f
All these replies are correct in the details (as usual), but miss the point.
Blocking name resolution, while popular, does not meet the OP's requirement:
"The point is I have several desktops that *must* have access **only**
to internal domains.*"
Let's say that your client's favorite illicit si
Controlling DNS resolution isn't the panacea for all security challenges,
but then neither is a firewall. Or IPS. Or DLP. Or
blacklisting/whitelisting. Or restrictive routing. Or NAT'ing. But some
combination of those can be part of an overall security strategy. Defense
in depth.
- Kevin
On Tue,
9 matches
Mail list logo
