Forward zone inside a view
gtaylor at tnetconsulting.net
Tue Feb 12 22:56:37 UTC 2019
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 resolved by your internal DNS to a
> specialized proxy server.
It sounds like you might be talking about using a reverse proxy of sorts
to translate internal requests for teamviewer.local to external requests
> 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.
The internal (reverse) proxy can accept HTTPS protected requests for a
domain that it has the certificate for, i.e. teamviewer.local, or
possibly teamviewer.corpdomain.tld. (The latter would allow for TLS
certificates from 3rd parties like Let's Encrypt.)
> In other words, move the mapping one level up in the protocol stack,
> from the DNS layer to the HTTP(S) layer.
The other advantage that this has is that recursion could remain
disabled on the internal DNS servers. All that would need to be done is
to make the internal DNS server authoritative for teamviewer.local (et
> And, if the proxy can support the equivalent of name-based hosting, then
> it could support multiple local domain redirects, if needed in the future.
I've done this a number of times with Apache.
> P.S. PRIVOXY is probably able at least to do the redirect for a single
> domain -- and it's lightweight.
I think Squid can do it. I expect that other sufficiently capable proxy
or web server can do it too.
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the bind-users