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.
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 (184.108.40.206) or OpenDNS (220.127.116.11 and 18.104.22.168), 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.
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.
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).