Forward zone inside a view

Tue Feb 12 23:57:00 UTC 2019

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, Feb 12, 2019 at 6:34 PM Timothe Litt <litt at acm.org> wrote:

> 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 site is facebook.com.
>
> One dig (or host) command reveals that:
>
>   facebook.com has address 157.240.3.35
>  facebook.com has IPv6 address 2a03:2880:f101:83:face:b00c:0:25de
>
> Fits on scrap of paper.  Carry in to office.  Connect - with a Host header
> for http, SNI for TLS, and off you go.  Or just put it in hosts.txt/hosts.
>
> Or use a public nameserver.   Or...
>
> If you want to block access, you need a firewall.  If you merely want to
> inconvenience people or reduce the risk of clicking on ransomware
> hyperlinks, mess with their default nameserver.  RPZ is good for that.  If
> you have a private address space & need to resolve some names differently
> inside and out, views are good for that. (Or you can have a different
> nameserver; tastes vary.)  If you are resource limited and want to benefit
> from a public server's larger cache, while serving authoritatively some
> local names, forwarding can be a good choice.
>
> But "**must** have access **only**" implies that one expects that the
> solution should resist *more* than a cooperative or unmotivated client.  NO
> DNS-only based solution will do that.
>
> Governments and political pressure groups think that DNS corruption is an
> effective tool for limiting access.  People here know better.  It deters
> certain casual problem behavior.  It does not prevent anyone with a modicum
> of knowledge and determination from watching cat videos.  (Or downloading
> malware, or whatever other behavior a policy maker wishes to ban.)
>
> It is worth listening to the OP's problem statement and steering him away
> from illusory technology.  It's the responsible thing to do.
>
> That there are technical answers to the question asked doesn't mean that
> it's the right question.  If it's not (and in this case it does not appear
> to be), those answers are not helpful.  Even though they are correct in
> other contexts.
>
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> On 12-Feb-19 17:45, Kevin Darcy wrote:
>
>
> 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 instance. Since you want
> to forward -- selectively -- you need "recursion yes". Nothing outside of
> that part of the namespace will be forwarded, since named considers
> everything else to be contained in the root zone.
>
>
>       - Kevin
>
> On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna <robertocarna36 at gmail.com>
> wrote:
>
>> Matus, I've followed whatyou say:
>>
>> view "internet" {
>>    match-clients { internet_clients; key "pnet"; };
>>
>> recursion yes;
>>
>> zone "teamviewer.com" {
>>         type forward;
>>         forward only;
>>         forwarders {
>>                 8.8.8.8;
>>         };
>> };
>>
>> };
>>
>> but clients can resolve ANY public Internet domain, in addition to
>> teamviewer.com....I think "recursion yes" apply to every public domain and
>> not just for "teamviewer.com", but I don't know why.
>>
>> Please can yoy give me more details, using forward or not, how can let
>> some clients resolve just teamviewer.com ??? I confirm that my BIND is
>> an authorittaive name server for internal domains.
>>
>> Thanks a lot again.
>>
>> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
>> uhlar at fantomas.sk>) escribió:
>>
>>> On 11.02.19 10:38, Roberto Carna wrote:
>>> >Dear Mathus, thanks al lot for your help.
>>> >
>>> >>> what is the point of running DNS server with only two hostnames
>>> allowed
>>> >>> to resolve?
>>> >
>>> >The point is I have several desktops that must have access only to
>>> internal
>>> >domains. The unique exception is they have access to teamviewer.com  in
>>> >order to download the Teamviewer client and a pair of operations in this
>>> >public domain.
>>>
>>> if you disable recursion, any client using that server will only have
>>> access
>>> to the domains that are configured on that server internally.
>>>
>>> That also means they won't be allowed to contact any internal domains,
>>> unless you configure those internal domains on that server.
>>> Also no windows updates, nothing.
>>>
>> [Snip, message too large]
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190212/21783447/attachment.html>