5

Say I have a domain name that points to my IP address. I have a router that handles port forwarding to a server in my living room. If I type the domain in a browser for example, it would eventually get pointed to "itself".

So, the propagation would be:

server -> router -> ISP -> (DNS spaghetti) -> ISP -> router -> server

but once it knows the IP address (and it's cached throughout), is "the system as a whole" likely set up to know it can short circuit to:

server -> router -> server ?

or even

server -> server (via "localhost" or whatever?)

what if I have another computer behind the router? if I SSH into the server (by its domain name) is every keystroke getting propagated like

computer -> router -> ISP -> router -> server ?

or is it smart enough to just go

computer -> router -> server ?

This is just a question of whether I should have two aliases for ssh-ing into my home server (sshmyserverlocal or sshmyserverremote) so I'll have the quickest connection possible if local, or if DNS takes care of that for me.

  • 23
    It's hard to make sense of this question. What does it have to do with DNS? – David Schwartz Feb 8 '17 at 5:59
  • 5
    I think the question is: is the router smart enough to route queries from the LAN targeted to its external IP back to the LAN, following its routing table, without sending any data to the WAN? – Gustavo Rodrigues Feb 8 '17 at 10:36
  • 4
    Why not run your own DNS server in your LAN adn point to internal addresses directly? – ivanivan Feb 8 '17 at 14:28
  • 8
    Noobish question: since you seem to have it already set up, why don't you use traceroute to see the path of the requests? – frarugi87 Feb 8 '17 at 16:00
  • Yes, you'll have to use multiple aliases. If you really want to use a single alias, then you'll have to set up a LAN DNS server. – chue x Feb 8 '17 at 22:56
48

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.

| improve this answer | |
  • 6
    However, the DNS points to the router address, and I don't think the "port forwarding" is considered by the routing algorithm. – Bergi Feb 8 '17 at 7:55
  • @Bergi: Depends on the type of routing. With NAT routing and port forwarding it wouldn't work (just like you explained). However, if the host on the local network has a public IP address then everything should be fine assuming a sane router setup. Unfortunately OP doesn't mention the routing type. – David Foerster Feb 8 '17 at 14:05
  • 1
    @Bergi, DNS does not know anything about the router address. It translates a, presumably, human readable-name into a machine readable IP address. Are you confusing DNS with DHCP, which should return a router address? The configured gateway (router) for a host will route packets based on the destination IP address, without regard to whatever DNS has told the host. – Ron Maupin Feb 9 '17 at 1:58
  • 1
    @RonMaupin OP's router does port forwarding to the server. So the IP address of incoming packets will be the address of the router. – Taemyr Feb 9 '17 at 8:20
  • 1
    @MSalters agreed. The incoming packet has the router's adress as it's destination adress. – Taemyr Feb 9 '17 at 9:10
12

@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..."

| improve this answer | |
  • 1
    aka "Stupid DNS Tricks®" – Alnitak Feb 8 '17 at 14:22
  • 1
    That still doesn't affect IP routing. The IP routing decisions are purely based on the destination IP address in the IP packet header. How that address is populated has nothing to do with the routing. What you are describing seems to be anycast, where multiple devices have the same IP address, and routing sends the traffic destined to that IP address to the (network) closest device with that IP address. – Ron Maupin Feb 9 '17 at 2:03
6

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.

| improve this answer | |
5

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.

| improve this answer | |
  • 2
    I think you have a double negative here: "avoiding NAT is the least efficient" should presumably read "using NAT is the least efficient", or "avoiding NAT is the most efficient". – IMSoP Feb 9 '17 at 14:04
  • 1
    @IMSoP Thank you that was a typo. You are absolutely right. I intended to use one of the two wordings you suggest. I must have changed my mind about which of the two wordings to use halfway through the sentence, which lead to accidentally saying the opposite of what I intended to. – kasperd Feb 10 '17 at 1:01
4

Short Answer

No.

However, you can use DNS to (help) accomplish what you're seeking to do.

Assessing the situation

This really seems like a case of XY problem. You're trying to figure out how a DNS configuration will be controlling routing. The problem is that DNS has very little impact on routing. This is probably due to some lack of familiarity with how routing works.

So, I'm agreeing with D34DM347's answer. However, when there's an XY problem, I realize that sometimes you don't just need an answer that tries to help you face the right direction, because that direction may not seem desirable unless you understand more details about the reasons why that direction should be pursued. So, I touch upon some design concepts here.

Generalizing this is unsafe

is "the system as a whole" likely set up to...

Well, information about "the system as a whole" can vary substantially. There are different approaches to do things. Some may be more efficient, although at the cost of complexity in setting things up.

You're question is seeking the possibility of shortening the path that traffic takes, so that the traffic can use your local equipment and skip going through the Internet. Well, whether that is possible, or not, is going to depend on your local equipment. The answer will be different for different networks, based on what your local equipment is. Standards for worldwide Internet routing aren't going to be addressing a lot of details about whether your local equipment is running a DNS server.

I don't want to get overly specific by providing just one answer for how things do work, because there are multiple ways that things can happen. Different solutions have different capabilities. The limitations of simple capabilities are one reason why different options may be available.

Another reason for multiple possible designs may be that some equipment may have more advanced capabilities than what I am likely to predict. For instance, I remember configuring a router to send traffic to a computer that would validate outbound traffic, and pass validated traffic back to the router which had the physical connection to the Internet. My setup failed because the router was designed to optimize traffic, so the equipment tried to out-smart my design by having the traffic skip what it thought was an unnecessary step.

Since there are different possible situations that can depend on details like what "DNS server" software may be getting used, there isn't just one simple answer that will say what your local network is capable of. (Your question was rather vague about some details about your setup (like what equipment is being used, and possibly what operating systems or web browsers you use), there isn't just one simple answer that applies to all possible situations.) So, I will just provide some general guidelines on what is commonly available.

Name resolution

Many DNS servers support a concept called "split-horizon", which basically means that the answer that is received from a DNS server will depend on where the request comes from. For instance, a common technique is to provide one answer (which is an internal address) to all requests that come from "IETF BCP 5" addresses (more commonly known as "RFC 1918" addresses, which are IPv4 addresses starting with "10." or "192.168." or a number starting with "172.16." through "172.31.") gets sent to your internal address. Requests from other IPv4 addresses would get a different answer which results in pointing to another address, which is reachable from most locations on this planet. (IPv6 will also get handled using different configuration details, but can be set up to work similar to IPv4. To keep things sane, IPv6 probably should be set up similar to IPv4.)

Now, whether that is an easily available option for you, or not, may depend on factors like what DNS server is being used.

If your web browser is on a computer that forwards all DNS traffic to a famous public DNS server, like google-public-dns-a.google.com (8.8.8.8) or OpenDNS (208.67.222.222 and 208.67.220.220), then this is likely not an option for you. That is a common scenario.

However, another rather common scenario may work fine. If your web browser uses whatever DNS server is recommended by your DHCP server, and if your DHCP server is your local router, and if that recommended DNS server is also your local router, then you may be able to set this up by looking in your router configuration for the "DNS server" functionality and look for something referencing split horizon (or a similar term, like "split DNS").

So, one option may involve setting up a DNS server at your location. However, even that may be more work than what you need. You may be able to accomplish the same thing by using a "name resolution" technique other than DNS. Most computers will support using a "hosts file" as a primary resource to check first, and then use DNS if the system's local "hosts file" doesn't provide information that is more specific. So, if you have just one web browser that you want to do this to, you may be able to accomplish your goal (or shortening the traffic's route) simply by editing a text file, which circumvents DNS entirely.

SSH keystrokes

if I SSH into the server (by its domain name) is every keystroke [going to the ISP]

Whether your keystrokes go to the ISP, or not, will entirely depend on details like what IP address you are using, and how IP traffic to that IP address gets routed. (Understand that an IP address is rather numaric, like 192.168.0.10 in IPv4, or fd00::abcd in IPv6 which uses hexadecimal. A domain name used in DNS, like example.com, is not an IP address.) When you "SSH into the server (by its domain name)", what really happens is that your SSH client will perform a "name resolution" lookup, which will likely involve checking for data in a "hosts file" and then check DNS. (There may be other steps too, like checking the local "resolver" cache before doing either of those thing, and then if DNS is used, storing the results in the "resolver" cache to speed things up next time.) Your SSH client does this before trying to communicate with the remote machine. Then, once the "name resolution" process has been used to generate an IP address, the SSH client will make an SSH connection using the IP address that resulted from the "name resolution" lookup. So the way that traffic gets handled will depend on the IP address, not whether you typed a domain name.

The basic common job of DNS is essentially just to help the "name resolution" process convert a name to an IP address. How traffic moves throughout the system is a concept that most commonly called "routing", and that is handled by different software/configurations than the "name resolution". So, people who understand this stuff well will try to answer your DNS-related questions separate from your router-related questions, because they are really separate technologies designed for separate purposes, and things are simplest if you try to think about things how they were designed. In your head, keep DNS and routing separate.

That completes my coverage of the topic of DNS. Now, let me tackle the other big focus of your question, which is how the traffic gets routed.

Routing

server -> server

This might also be an option. When the computer tries to send network traffic, part of the process is to create a proper "Layer 2" frame. The most common forms of "Layer 2" frames in home networks are an Ethernet frame that will get sent over UTP cable, or a Wi-Fi frame that gets sent over the airways. (Commercial sites may use other technologies like fiber-optic connections.) A typical "Layer 2" frame will use a MAC-48 address to identify the recipient.

The computer that is sending traffic will check what the destination address IP is. For example, let's say that the computer sending traffic is using IPv4 192.168.1.205 and the computer that will be receiving traffic is IPv4 192.168.1.15. If your computer is using a subnet mask of 255.255.255.0, that means that the size of the subnet is 256 addresses. (If you had a different subnet mask that starts with "255.255.255.", then it would be a smaller subnet.) There is one subnet which has 256 addresses and which contains 192.168.1.205, and that is the subnet that goes from 192.168.1.0 through 192.168.1.255.

Since 192.168.1.15 is part of that same subnet, the computer will send a Layer 2 frame using the MAC-48 address of the desired destination (which your diagram indicates is a server). There will be no traffic sent to any of the addresses of the router.

If, on the other hand, the destination address was 203.0.113.6, then that would not be part of the same subnet as the source (192.168.1.205). In that case, the routing table specifies that traffic gets sent to a "gateway" device. (The "default gateway" is likely your router.) So the computer will send a Layer 2 frame using the MAC-48 address of the gateway. The intent is for your computer to trust that the gateway will know which of its network connections will be useful for getting the traffic to the desired destination. The gateway might use the network connection that communicates with the Internet Service Provider, or might not. These details are controlled by factors like which IP addresses are being used, and how big the subnets are.

Routing is handled by key routing details like the source computer's IP address, the destination IP address, the size of the source computer's subnet, and a "default gateway" that handles traffic which is not part of a more-specific subnet. A computer on a home network usually gets most those details for IPv4 by using DHCP. The one exception is the "destination IP address", and that is the only part of the process that "name resolution" is likely to be getting involved with.

server -> router -> server

You were asking if this is a possibility. It may be. I will describe how this can work.

This is preferable over sending traffic to the ISP. (It doesn't bother the ISP's equipment at all, and the communication goes faster than needing to send traffic to a remote end.)

First of all, when the router receives traffic, it looks at the destination MAC-48 address. If the destination is MAC-48 address is not the router, then the router doesn't do anything with the traffic, unless the router is configured to act like a switch. Usually, home routers label some of their network ports as a “LAN port”, and these ports are treated as a single “link”, so the router will act like a switch for these devices. If that's the case, the router will send traffic out one or more of the ports that are being treated like a switch.

In order for traffic to go from an internal LAN port to the ISP, the router has to send traffic out the network port that communicates to the ISP. Your typical home network is not likely to do that if the destination IP address is one of the "private" addresses, such as the IPv4 addresses specified in IETF BCP 5 (more famously known as RFC 1918). Furthermore, most ISP's will just block IETF BCP 5 traffic on sight (and will not send that traffic back to you). So, this setup (server -> router -> server) is more likely to be what is actually happening, rather than a more complex process involving the ISP.

If information is going through the router, but you're just using IETF BCP5 addresses on the internal LAN ports, I usually don't refer to that as involving a router. Instead, the router handles the traffic just like a "switch", by just using the MAC-48 addresses to make decisions related to traffic flow.

There is another possible setup, which is that you may be using the WAN address. In that case, multiple subnets are being used, and so the device is acting like a router. This gets more complicated, but because it is a possibile way that things may be working, it is worth covering here. I'll provide an example of how this can work successfully. This next paragraph contains a few IP addresses. To help keep those addresses straight, the main detail to keep track of here is that the addresses starting with "192.168.1" are for IP addresses on the LAN, while the addresses starting with "203.0.113" are addresses for the WAN connection (where the router connects to the ISP).

What can happen is that the gateway device at the ISP might have a gateway device using an address like 203.0.113.5, and IPv4 address 203.0.113.6 assigned to the "WAN port" of your router. If your computer at 192.168.1.200 tries to communicate with 203.0.113.6 (you router's WAN port), then your router will receive traffic (on you router's LAN port, maybe at 192.168.1.15), and the router will realize traffic should communicate using subnet that contains 203.0.113.5 and 203.0.113.6. When the router realizes that traffic is being received by 203.0.113.6, your router may realize a traffic-handling rule for 203.0.113.6 which says that TCP port 80 traffic should have "network address translation" (NAT) applied. To do this, your router creates a new IP packet that gets delivered from 203.0.113.6 to your local web server, which may be at 192.168.1.50. The router realizes that 192.168.1.50 is on the same subnet as 192.168.1.15 and send traffic out a local LAN port.

If that is how all this happens, then the router will never have a reason to send traffic to 203.0.113.5, so it never goes to the ISP.

In fact, if the ISP did get this traffic, the ISP would probably say "Received traffic is meant for this customer's network. However, the traffic came from the customer's network. This traffic was sent to me unnecessarily. I don't want to cooperate with this. I will just drop/ignore the traffic." The ISP expects that if this causes problems, the problems will be fixed by intelligently fixing your internal network so that it doesn't unnecessarily send traffic to the ISP.

(This also addresses the concept of “computer -> router -> ISP -> router -> server”. If you were meaning to refer to one router both of the times that you said “router”, because you thought traffic might turn around at the ISP, then this is quite undesirable, and quite possibly infeasible due to a common way that ISPs handle traffic.)

So, is “server -> router -> server” theoretically possible? Yes. However, not all devices will necessarily support NAT, or support them in the same way. Some devices might be designed to only support NAT at a particular point in the traffic-handling process, and this might be before the traffic switches subnets from "192.168.1" addresses to "203.0.113" addresses. So, in some cases this might not work. As explained in the last paragraph, the solution is not to try to get traffic sent to the ISP. (The solution is to not have traffic be sent to the IP address on the router's WAN port. You could most easliy avoid that by affecting how "name resolution" works.)

This is just a question of whether I should have two aliases for ssh-ing into my home server (sshmyserverlocal or sshmyserverremote) so I'll have the quickest connection possible if local, or if DNS takes care of that for me.

You want to have this taken care of, whether by using "name resolution" or IP routing or both. If you have multiple names, and you end up using the wrong name, then sometimes a detail like that won't matter at all, and sometimes they will. For instance, the "ping" command uses ICMP and would probably be unaffected. However, if you were using HTTPS (instead of SSH), then the host names may matter quite a bit more. As for SSH (which was mentioned in the example), that probably wouldn't matter much, although at least some versions of sshd have used Reverse DNS and so you might have delays if things don't match up as expected.

For your own peace of mind, and possible for proper technical functionality, you'll want to always be using the right host name. For instance, the web server's SSL certificate should have a name matching what is typed into the web browser. The easy way to make all this work, avoiding related problems, is to just have one host name (even if that has multiple IP addresses, thanks to the use of a "hosts file" or by using split DNS).

| improve this answer | |
2

You can setup some DNS forwarder such as Unbound (I answered no so long ago here how to do that) where you can override any public DNS records, or a simple way is to add to your hosts file

your.tld ip.of.local.machine

but you need to comment out it when you out of your local network, so some respectful firewall such as PFsense of some DNS forwarder installed locally on your LAN would be much more convenient way

| improve this answer | |
1

In your first scenario, this is what happens assuming that the browser is running on the same server:

  1. Server contacts DNS Server by way of router to resolve hostname
  2. DNS Server responds with IP address of hostname (which points to router)
  3. Server contacts IP address of router and router port forwards back into LAN

The IP address will be cached for the next 86,400 seconds (1 day) on Windows, so only step 3 above should be executed during that time. After the cache expires it will start over at step 1.

So yes, the router is smart enough to know what its own external address is and not route you to the Internet to find it. You are only routed to the Internet to resolve the hostname if it is not known (unless your router is your DNS, then it will resolve it for you).

This same series of steps would apply to your SSH scenario as well, though you can bypass the router and go straight from host to host if you use the internal addressing by IP or by an addition in the hosts file (this is what I do).

In a different but similar scenario, the router may issue an ICMP Redirect to the actual internal address of the server so that you bypass the router. It is not likely that a port forwarding router would do this.

| improve this answer | |
1

Your problem can be solved by either routing or DNS (at least with PFSense). PFSense calls it respectively NAT reflection (redirect traffic that was intended for WAN interface to a internal host) and DNS split (internal and external hosts resolve the address differently).
Outside of the definitions I don't have much experience with those features, you should read this article on PFSense's wiki for more details. This is pretty much vendor-specific, so there is little hope that other routers, software or hardware, also behave the same way.

| improve this answer | |
1

Your best option is to configure the DNS proxy that is likely already running on your router. You may need console access to the router for that. Most likely your proxy is software called dnsmasq Through dnsmasq you can allocate both fixed IP adresses (via the DHCP server, and dns names for all your servers. You would give them the same names you would use outside (e.g. server.mydyndns.com), but only with local, non-routable addresses. As long as local machines use your router as a DNS to do name resolutions, they will connect directly to your servers without being routed outside. Once you disconnect from your local network, name resolutions will then be handled by another public DNS, and you will then connect to your public IP. YOu already had configured port forwarding, so from the outside nothing will change. If you can not configure your router's dnsmasq, then you could install dnsmasq software on a different local server and use it as a DNS proxy (deactivate DHCP, as otherwise it will be in conflict with the router's DHCP). you must keep it running all the time though! The initial configuration will require reading the documentation, but updates (adding additional servers is very easy).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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