:: Re: [DNG] Jitsi-meet server in DMZ
Forside
Slet denne besked
Besvar denne besked
Skribent: g4sra
Dato:  
Til: Simon Hobson
CC: dng@lists.dyne.org
Emne: Re: [DNG] Jitsi-meet server in DMZ
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 10, 2021 6:56 PM, Simon Hobson <simon@???> wrote:

> g4sra via Dng dng@??? wrote:
>


> > > > The meeting being hosted on the server needs to be simultaneously
> > > > accessible as two different domains, internal.com and external.com.
> > > > Anyone achieved this yet or know a better way ?
>


> > Decided to use the external FQDN and implement BIND's response-policy' lying to the internal domain.
> > If anyone can think of a good reason why this is a bad idea please shout.
>


> Can you clarify what the issue is ?
> It is as simple as needing to connect to the server at different IPs (i.e. the internal IP from inside, the external IP from outside), but using the same URL ?


In a nutshell, yes.

> If so, then split horizon DNS is your friend - and I'm assuming that's


> what you are referring to when you say using BINDs response policy.

No.

BIND's 'responce policy' is a, um, policy similar to a normal zone BUT anything in this zone can mask a real resolve from occurring.
It's downside is it's non-authorative, breaks dnssec, and site certificate authentication.
In some way it is comparative to masking by having an entry in your hosts file, only you don't need to edit every host.

So you could for instance put "detectportal.firefox.com CNAME www.mylocal.net" in it and bounce firefox to pull www.mylocal.net:<webroot>/success.txt from your server and prevent it calling home every time you launch it on any pc using your internal network.


> I run split horizon DNS at home. I have an internal zone for thehobsons.co.uk which has internal addresses for my devices, and an external zone for it which lists only the public IPs. Two views (in BIND terminology), with rules applied to determine which view is used for which clients.


Yes, I use two different views for internal and external traffic too (not heard the term 'split horizon' before).


> Some will tell you that it's wrong - but as long as we have NAT then it's a decent and reliable workaround for the breakage that NAT causes.

The reason it is wrong is...your internal DNS server is exposed to to a higher hacking threat than if you had two separate servers, with the one in the DMZ serving external queries and the internal one on the local lan behind a secondary firewall.