我们很快就会开始工作，我们希望用户连接到基于Internet的服务器，但由于networking链接速度较慢，因此在现场连接到本地服务器。 我们将在现场分包商，基础设施将由主要客户提供。
我们希望我们的应用程序首先尝试连接到本地服务器，如果失败或无法find它，则在Internet上尝试全局服务器。 我正在考虑使用我们的域名注册商为每个服务器localproject.domain.com和project.domain.com创build一个项目子域名，而开发者不得不在应用configuration中使用原始IP地址。
我很高兴给project.domain.com Web服务器的公共互联网IP，但我可以给localproject.domain.com和内部192.168.xx地址？
至于最佳做法，我应该问客户端添加一个localproject.domain.com到他们的基于局域网的DNS的DNS条目，我们将捎带，而不是去旅行基于互联网的DNS服务器？
您不会第一个将DNSlogging指向公有领域的内部IP空间。 我对这个问题的理解基本上有三个问题：
1）你正在以一些小的方式揭露实体的内部运作。 您正在向任何想知道主机名和内部IP地址的人发送任何关于该公司networking/设置的内部结构的信息。 这可能是最小的或可缓解的风险。
2）任何试图去到那个地址的人都会试图打到那个本地IP，即使它们不是内部的 – 对于随机的外部用户和在具有无效设置的远程站点的实际客户用户而言，没有VPN，不在企业networking，等等），这可能导致额外的IT工作量。
3）有点符合＃2 – 如果有人试图击中“local.domain.com”，而不是在公司的网站，它解决的IP是一个有效的IP在他们实际上在networking上？ 如果这是一个坏事情的服务器呢？ 引入了一个安全风险，但同样有办法来缓解这个问题（比如应用程序有自己的authentication和安全机制来实现这样的事情）。
如果上述三个问题不是过分关注，或者你愿意努力减轻这些问题，我认为这不是一个特别糟糕的方法。 让应用程序首先尝试“local.domain.com”，如果它不解决或无法连接尝试“.domain.com”似乎是一个理智的方式来处理这个应用程序应该公开的服务器如果私人的不工作。
至于最佳做法，我应该问客户端添加一个localproject.domain.com到他们的基于局域网的DNS的DNS条目，我们将捎带，而不是去旅行基于互联网的DNS服务器？
当然是。 您不仅可以避免Nex7指出的问题，还可以让客户更轻松地debugging/更改地址（并允许您扩展：例如，当客户使用不同的本地networking打开第二个站点时，只需添加本地服务器与正确的IP）。