We will be running a job soon where we want users to connect to a Internet based server but connect to a local server when on site due to slow network links. We will be subcontractors at the site and the infrastructure will be provided by the main client.
We'd like our application to try and connect to the local server first and if it fails or cannont find it then try the global server out on the Internet. I was thinking of using our domain registrar to create a project subdomain for each of the servers localproject.domain.com and project.domain.com as opposed to the devs having to use raw IP addresses in the app config.
I'm happy enough to give the project.domain.com the public Internet IP of the web server but can I give localproject.domain.com and internal 192.168.x.x address?
As for best practice should I instead be asking the client to add a DNS entry for localproject.domain.com to their LAN based DNS that we will be piggybacking off rather than having to make a trip to the Internet based DNS servers?
Best Answer
You wouldn't be the first to have DNS records pointing at internal IP space on a public domain. My understanding of the issue is there are basically three issues with it:
1) You are exposing in some small way the internal workings of the entity. You're handing anyone who wants to know a hostname and an internal IP address it is tied to, which may allow them to infer any number of things about the internal structure of that company's network/setup. This may be minimal or mitigate-able risk.
2) Anyone attempting to go to that address is going to try to hit that local IP, even if they're not internal -- a potential point of confusion both for random external users and for actual customer users at remote sites with invalid setups (no VPN, not on corporate network, blah blah) that can lead to additional IT work load.
3) Somewhat in line with #2 -- what if someone attempts to hit 'local.domain.com' when not at the corporate site and the IP it resolves to IS a valid IP on the network they're actually on? What if it's a server that does bad things? A security risk is introduced, but again, there are ways to mitigate this (such as the application having its own authentication and security mechanisms to realize things like this).
If the above 3 issues are not overly concerning or you're willing to work on mitigating them, I don't think it's a particularly bad way to go. Having the application try 'local.domain.com' first and if it doesn't resolve or fails to connect try '.domain.com' seems like a sane way of handling the idea that the application should make it out to the public server if the private one doesn't work.