Forward zone inside a view
bind at iment.com
Fri Feb 8 02:02:19 UTC 2019
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 resolved by your internal DNS to a
specialized proxy server.
Then set up this proxy server to forward those requests to
"teamviewer.org", *not* its IP address (since that can, of course,
change). This is likely the hard part, but the proxy can at least
assume that it never gets HTTP(S) requests in general.
In other words, move the mapping one level up in the protocol stack,
from the DNS layer to the HTTP(S) layer.
And, if the proxy can support the equivalent of name-based hosting, then
it could support multiple local domain redirects, if needed in the
P.S. PRIVOXY is probably able at least to do the redirect for a single
domain -- and it's lightweight.
On Thu, 7 Feb 2019 15:00:47 -0500
Alan Clegg <alan at clegg.com> wrote:
> On 2/7/19 2:30 PM, Roberto Carna wrote:
> > Dear, thanks for your contact. I've used teamviewer.com
> > <http://teamviewer.com> just for tests.
> > Desktops I mentioned can only access to web apps from internal
> > domains, but in some web apps there are links to download
> > Teamviewer client software from Internet. I can create a private
> > zone "teamviewer.com <http://teamviewer.com>" with all the
> > hostnames and IP's we will use, but if they change I will be in
> > trouble.
> Sounds to me like a use for a global block with RPZ and a passthrough
> for the domain that needs to be ... uh ... passed through.
> And from my experience, this is never going to work because whatever
> the "only thing we want to resolve" is, it will rely on something
> else that you don't (currently) resolve.
> Anyone that has ever tried to block their "smart TV" so that it only
> allows certain apps but not others will know exactly what I'm talking
More information about the bind-users