<div dir="ltr"><div>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.<br><div><br></div><div> - Kevin</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 6:34 PM Timothe Litt <<a href="mailto:litt@acm.org">litt@acm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>All these replies are correct in the details (as usual), but miss
the point.</p>
<p>Blocking name resolution, while popular, does not meet the OP's
requirement:</p>
<p>"The point is I have several desktops that *must* have access
**only** to internal domains.*"</p>
<p>Let's say that your client's favorite illicit site is
<a href="http://facebook.com" target="_blank">facebook.com</a>.</p>
<p>One dig (or host) command reveals that:<br>
</p>
<p> <a href="http://facebook.com" target="_blank">facebook.com</a> has address 157.240.3.35<br>
<a href="http://facebook.com" target="_blank">facebook.com</a> has IPv6 address 2a03:2880:f101:83:face:b00c:0:25de<br>
</p>
<p>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.<br>
</p>
<p>Or use a public nameserver. Or... <br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.)<br>
</p>
<p>It is worth listening to the OP's problem statement and steering
him away from illusory technology. It's the responsible thing to
do.<br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<pre class="gmail-m_-8838422168423783596moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<blockquote type="cite">
<div>On 12-Feb-19 17:45, Kevin Darcy wrote:<br>
</div>
</blockquote>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Define root zone. </div>
<div><br>
</div>
<div>Delegate <a href="http://teamviewer.com" target="_blank">teamviewer.com</a> from root zone.</div>
<div><br>
</div>
<div>Define <a href="http://teamviewer.com" target="_blank">teamviewer.com</a> as "type forward".</div>
<div><br>
</div>
<div>"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.</div>
<div><br>
</div>
<div>
- Kevin</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 11, 2019 at 9:06
AM Roberto Carna <<a href="mailto:robertocarna36@gmail.com" target="_blank">robertocarna36@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div>Matus, I've followed whatyou say:</div>
<div><br>
</div>
<div>view "internet" {</div>
<div> match-clients { internet_clients; key "pnet"; };</div>
<div><br>
</div>
<div>recursion yes;</div>
<div><br>
</div>
<div>zone "<a href="http://teamviewer.com" target="_blank">teamviewer.com</a>" {</div>
<div> type forward;</div>
<div> forward only;</div>
<div> forwarders {</div>
<div> 8.8.8.8;</div>
<div> };</div>
<div>};</div>
<div><br>
</div>
<div>};</div>
<div><br>
</div>
<div>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 "<a href="http://teamviewer.com" target="_blank">teamviewer.com</a>", but I
don't know why.</div>
<div><br>
</div>
<div>Please can yoy give me more details, using forward or
not, how can let some clients resolve just <a href="http://teamviewer.com" target="_blank">teamviewer.com</a> ??? I
confirm that my BIND is an authorittaive name server for
internal domains.</div>
<div><br>
</div>
<div>Thanks a lot again.</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El lun., 11 feb. 2019 a
las 10:49, Matus UHLAR - fantomas (<<a href="mailto:uhlar@fantomas.sk" target="_blank">uhlar@fantomas.sk</a>>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11.02.19 10:38,
Roberto Carna wrote:<br>
>Dear Mathus, thanks al lot for your help.<br>
><br>
>>> what is the point of running DNS server with
only two hostnames allowed<br>
>>> to resolve?<br>
><br>
>The point is I have several desktops that must have
access only to internal<br>
>domains. The unique exception is they have access to <a href="http://teamviewer.com" rel="noreferrer" target="_blank">teamviewer.com</a>
in<br>
>order to download the Teamviewer client and a pair of
operations in this<br>
>public domain.<br>
<br>
if you disable recursion, any client using that server
will only have access<br>
to the domains that are configured on that server
internally.<br>
<br>
That also means they won't be allowed to contact any
internal domains,<br>
unless you configure those internal domains on that
server.<br>
Also no windows updates, nothing.<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<p>[Snip, message too large]</p>
<p><br>
</p>
</div>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>