On 12/03/2021 16:41, g4sra via Dng wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 10, 2021 6:56 PM, Simon Hobson <si...@thehobsons.co.uk>
wrote:
g4sra via Dng dng@lists.dyne.org 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).
Split horizon is the term I would use.
However there's a major issue with Android and its network management
in-so-much-as when it switches bearers, for example from Wifi "inside"
your network to 4G "outside" and the IP address that the device has
changes, it doesn't re-resolve all the IP addresses and reset all the
connections so various things break.
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.
You'll be lucky of Jitsi works well with NAT due to the nature of
NAT-encumbered protocols like SIP and RTP.
We put our Jitsi server on a public IP address and it now always works.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
