0

I am trying to find the best solution for my DNS problem. We are running several services in our company that you can reach only over VPN. Other services, that are reachable through the internet got the domain ... At the moment all services inside the VPN network go by .local... These have an VPN IP of the private network 192.168.252.0/24. Clients reach from Linux over OSX to Windows.

I can think of 4 possibilities to implement a DNS infrastructure:

  1. Most common: an internal DNS Server, that is pushed by the VPN. But this has several drawbacks: your DNS responses are limited to the speed of the VPN Connection and your own DNS server. Because of very complex websites, this can increase the time for a page to load quite a lot. Also: we have several VPNs that are not connected to each other and all of them have their own DNS server.

  2. Several DNS servers locally. These have to be configured by hand. And you have to use some third party tool like dnsmasq. If you start a DNS request, you ask your locally running DNS server, which decides which server to ask for which domain name. One college of mine uses such a solution with this OSX (I am sorry, I don't remember the name of the application).

  3. You use your domain hoster. Most of them have APIs available to manipulate your DNS entries. So you could pull your private network informations to your domain hoster. I am not sure whether they all accept private network IPs. But I guess there will be some problems in the same way as in number 4.

  4. The one we currently use, because it's for us the most logical choice: we forward the sub domain *.local.. to our own public DNS Server. This works quite good for some public DNS Servers like Google. But most ISPs do not forward the answers. Or don't do that always. Like my ISP sends me a positive result of the a DNS request of a *.local.. domain only every 10th time I make a nslookup. (Can someone explain this?)

Here the real Question:

Is there another solution we were not thinking about?

Or:

What of these methods do you use?

closed as off-topic by Andrew B, mdpc, Ward, dawud, Nathan C Sep 3 '14 at 15:01

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Questions must demonstrate a minimal understanding of the problem being solved. Try including attempted solutions, why they didn't work, and the expected results. See How can I ask better questions on Server Fault? for further guidance." – Andrew B, Ward, Nathan C
  • "Questions must be relevant to professional system administration. Server Fault is dedicated to professional system and network administrators. End user and enthusiast questions are off-topic (contact your system administrator or hire a professional to help you out). Please see the Help Center for more information." – mdpc, dawud
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    You haven't actually described your problem. – joeqwerty Aug 22 '14 at 0:39
  • Solution 5: DNS is not easy to understand from end to end, and it's wise to read a book before tackling these problems. Solution #4 suggests that you do not have a good working understanding of your existing infrastructure. Understanding what you have and how it works (or doesn't work) is essential to designing a better solution. We can't explain the specifics of this problem as you have not provided an actual record for us to troubleshoot. – Andrew B Aug 22 '14 at 0:45
  • I did read several resources about the topic. Most of the people recommend to don't put private IPs into a public DNS Server because of security reasons. But as we use SSL with all our services, this is not a real issue for us. We even plan to implement DNSSEC in the near future. The real problem is, that this depends on the DNS policy of the specific ISP and beside a draft from 2002 of the ietf I could not find any sources of real standards (means RFCs) regarding public DNS and private address spaces. – ribx Aug 22 '14 at 10:24
2

Solution 1 is the correct solution. If uses are connecting over VPN, all traffic including DNS should be running over the VPN. The VPN should be pushing one or more DNS server addresses.

You should not be providing either .local or private IP addresses over the Internet. Solution 4 is broken, as would be solution 3.

If you have distributed offices, using VPN to interconnect them, then use a DNS server in each site. In this case you are likely to have DHCP running on each site, and it should be providing the DNS server addresses.

Most browsers will cache DNS names for a period of time. You can also install a name server caching daemon on Linux which will cache addresses.

If it is your sites that are pulling from so many hosts that load times are excessively slow, then you may want to look as simplifying your sites. Normally, a page would load from 1 to 3 sites, excluding add content. It is possible to proxy content through servers as well to limit the number of DNS lookups required.

  • 1
    Yes, solution 1 is the good old way of doing this. But we have no "sites" that we connect to. Our infrastructure is virtual or "in the cloud". We have all services running on vservers on the internet. We are just a startup, yet. Also we have customers, where we connect through other VPNs. So the problem is: when I use solution one, I cannot connect to our customer and access our internal services at the same time (because I can use only one DNS server set at once). – ribx Aug 22 '14 at 10:31
  • we are not using .local domains at all. The domains are local.<company>.<tld>. You could interpret this as the domain name of our (virtual) site. – ribx Aug 22 '14 at 10:32
  • Yes, browsers do cache DNS request. But look at a site like reddit.com: I have 9 DNS request sent to load the landing page. It's not like a big deal, but when you DNS server through VPN adds up 50 ms per request, I wait 0.5 seconds longer to load a page. For me this is not acceptable. – ribx Aug 22 '14 at 10:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.