Is DNS smart enough to route local connections via the shortest (within LAN) path?

Solution 1:

DNS and routing are totally separate systems. The address returned by your DNS query is simply assigned as the destination when your client system initiates a connection to the server. The route that the packet will follow to reach the server is totally independent of this process. These systems are separate by design, so the routing process should always return the fastest possible route to the destination regardless of how DNS behaves.

Solution 2:

@D34DM347 is correct, DNS is not normally involved in IP packet routing decisions.

There's one slight exception however (where some of the confusion might come from) some of the big DNS servers, provided by Content Distribution Networks (CDNs) that have identical servers all around the world, look at where the request came from and change the answer based on that. If you're coming from a French IP then Akamai will serve you a response that points to one of their identical computers in France for example. See this blog post. This might be where your confusion lies and why you might have reasonably expected DNS to assist with routing.

As for routing, some devices offer NAT Loopback where they intelligently work out that the address you're trying to reach is actually local and so don't send those packets down the external network.. but that will be router device specific.

You will either need to point to a more local IP address or mess around with IP routing tables.. which is beyond the scope of your question of "Is DNS smart enough to route..."

Solution 3:

DNS query for the IP address corresponding to the domain name will go to whichever name server you have configured in the device where you are making the domain query. Most often that is your ISP's DNS server.

Then, the IP packets from client to server will go through the router where the port forwarding is set up.

If you configure an internal name server that returns the private IP address of the server for the domain name query, then the traffic will go directly from client to server, provided that they are located in the same subnet.

Solution 4:

The answer to your question is going to depend on exactly what you mean when you say "router".

A lot of end users use the word router to describe a device which primary function is to perform NAT (Network Address Translation). However the routers which make of the backbone of the internet are rarely configured to perform NAT. Those backbone routers are based on chips designed to do routing efficiently in hardware and not much else.

These distinction is so significant that I will answer your question separately in each of the two scenarios.

Using a NAT device between server and ISP

For this example I will assume your server has IP address 10.0.0.2 and your NAT device has IP address 192.0.2.42.

When your server connects to other servers on the internet the NAT device will change the source IP address of every packet send by your server from 10.0.0.2 to 192.0.2.42 as it passes through, it may also have to change the source port number. When a packet comes back the NAT device will change the destination address of the packets from 192.0.2.42 to 10.0.0.2.

In order to support connections from the internet to your server you will have configured a port forwarding on your NAT device. This port forwarding is what lets NAT device know which destination address to replace 192.0.2.42 with when it sees the first packet establishing a new connection. Once the connection is established the NAT device will perform the same translation as in the previous case.

In order for all of this to work your domain name will have to resolve to 192.0.2.42. But that means when the server itself resolves the domain name it will also get 192.0.2.42.

When the server wants to connect to 192.0.2.42 it will find that address to be outside of the LAN, since the LAN only covers 10.0.0.0/24. So it will send the packet to its default gateway, which would be the LAN interface of the NAT device.

As long as the NAT device is intelligent enough to NAT the same packet twice it will turn around and return to your server having had first the source IP address changed from 10.0.0.2 to 192.0.2.42 and next having the destination IP address changed from 192.0.2.42 to 10.0.0.2. The return traffic will go through the same translation process.

In this scenario the answer will be that the traffic travels from the server to the NAT device and then back to the server.

If your NAT device is a little less intelligent the traffic might go all the way to the ISP before it turns around. Or the NAT device might NAT the packet only once and send a packet with both source and destination address 10.0.0.2 back to your server, which your server will silently drop.

If you have your own DNS server (possibly hosted on the NAT device), you can make tricks with producing different responses to queries on the LAN from what answers those queries would get on the internet.

So even though the actual IP address of your domain is 192.0.2.42 clients on the LAN would be told it is 10.0.0.2.

This approach can however not be fully automated. Imagine you have forwarded port 80 on 192.0.2.42 to port 80 on 10.0.0.2 and port 22 on 192.0.2.42 to port 22 on 10.0.0.3. And the NAT device sees a DNS response with IP address 192.0.2.42. Which IP address should it replace 192.0.2.42 with before passing it on to a client on the LAN? It does not yet know if that client is going to connect to port 22 or port 80, so it cannot know which IP address to return to the client.

This means such split horizon DNS will always require some amount of manual configuration. And it can become a mess.

Using a router between server and ISP

For this example I will assume your server has IP address 203.0.113.2 and your router has the external IP address 192.0.2.42.

When your server connects to other servers on the internet, your router will forward the packet with no changes other than decreasing the TTL. The remote server will see packets originating from 203.0.113.2, and your ISP will have a routing table saying that all packets to 203.0.113.0/29 need to be routed through 192.0.2.42, which is how the return traffic gets back to your server.

In DNS the IP address allocated to your server will be 203.0.113.2. And both clients on your LAN and on the internet will see that address. Clients on the LAN will recognize that 203.0.113.2 is a local address and send packets directly to the server without traversing the router. Connections from the server to itself will not even reach the network interface as the IP stack on the server will recognize that the destination address is local to the server itself.

Should you want to connect from outside to port 80 on one server with IP address 203.0.113.2 and port 22 on another server with IP address 203.0.113.3, you simply do it. No translation is needed and traffic from outside explicitly specify which IP address it is destined for.

Your router might have a firewall functionality such that you have to configure the open ports before connections initiated from the internet to your LAN are permitted. But there is no translation needed which means it will be faster and more reliable.

Why even use NAT?

From the difference between these two scenarios we see that avoiding NAT is the most efficient of the two methods. The reason for using NAT is to reduce the number of IP addresses needed.

In the first example you would have been allocated just 1 IP address from your ISP. In the second example you would have been allocated 9 IP addresses. And that is the smallest number of IP addresses the ISP could get away with allocating to you without needing any hacks.

If our ISP has a state of the art network with support for both IPv4 and IPv6 things could look better. In that case it is possible to use NAT for only IPv4 and routing for IPv6.

Your server could have IP addresses 10.0.0.2 and 2001:db8:42:cafe::2, your NAT/router could have IP addresses 192.0.2.42 and 2001:db8:42::2. In this case your domain would have IP addresses 192.0.2.42 and 2001:db8:42:cafe::2.

Notice that the domain resolves to the IPv4 address of the router and the IPv6 address of the server.

Connections from the internet to the server will go through the router regardless of whether the client uses IPv4 or IPv6. Connections from the server to itself can try IPv4 and IPv6 in parallel and use the fastest, which will be IPv6 because the IPv4 connection will have to take a detour through the NAT/router.