Simple answer, related to level of question
Ignoring exotic uses of DNS, and also reverse DNS lookup (not relevant to question), almost all DNS use is of the form:
- Client sends domain name (fully qualified or otherwise) to a DNS server
- DNS server returns domain information from its records. Usually the key information requested is either the IP address to communicate with web/email on that domain, or the IP address of another DNS server better able to provide that information.
Once the client has contacted the server, the server itself will take over and the DNS system drops out of the picture.
What that means is, the the DNS system doesn't need to supply port information, and it almost never does so. So although the aim of the question is valid, and often done, it isn't actually the DNS system which does it. That's why you can't work it out :)
The idea is that once your client can locate the specific machine or server it's looking for, it is down to that machine to listen on any ports it chooses, and accept/deny/respond to any protocols on any ports configured.
For example, HTTP web services are usually provided on port 80. That means that once the client knows a machine IP, it can assume that sending a message to port 80 will result in that message being read/responded by that machine's web service. But it doesn't have to be that way. If the server is configured to listen for web incoming requests on port 9000, any client able to reach port 9000 will be able to reach its web service. If the server is behind a proxy/NAT/router that redirects port 10000 to port 9000, and the client sends a web request on port 10000, the server will receive it on port 9000 and respond as well.
Redirect/mapping within the web server
You asked about redirect mapping or rewrite in a comment. These are functions a web server can do. Basically, you can configure the web server (or most/many web servers) to manage how it handles the URL it receives in a request. So it can internally modify the URL on receipt to make different URLs be handled the same way, or fix common typos (mapping), or it can actually respond to tell the client itself to ask a second time, using some different, replacement, URL (redirect).
These have their uses, and could in principle handle your use-case, but they don't sound like the "right" solution for you, for these reasons:
- I don't think mapping would help at all. Mapping is almost totally internal to the web server, it says "treat this URL as if it's that URL". For example, you might use web server URL mapping to allow a user to query a forum using very-old, old and current URLs (for user convenience) using "https://example.com/index.php?area-=forum&topic=2", also "https://example.com/forum.php?topic=2" and also "https://forum.example.com?topic=2", and only handle this once, by mapping the first two of these onto the third URL internally, as the first step in handling the query. As this targets affects the query path not the IP/port, mapping isn't much use for port management, and in your case, the client never actually queries 8080 at all.
- Redirecting would work, but may not be what you want. Redirection in the web server relies upon the web server actually receiving the query (because these are web server internal functions). So the web server would have to listen on port 80 anyway to get the original query, inm order to respond with the redirect/map. It would also have to listen on port 8080. Functionally, it would need a redirect rule to have to tell any client querying port 80, to query it again using the ":8080" URL, which doesn't sound like what you want to do. The user would also see the new URL with ":8080" in it, whereas it sounds like you want it to be "transparent" and not shown.
- Also redirect would only work to redirect a standard port (80 or 443) - you couldn't redirect port 2000 to 8080 say, because the client wouldn't query on 2000 by default, in the first place, so it wouldn't ever get to the web server, even if it was listening on 2000. This might not be a problem for you though.
However if you want "intelligent" redirection, where only certain queries are rerouted to 8080, this might be the way to go, because redirect can include logic to decide which URLs should be redirected, whereas port mapping (below) would map everything.
How to correctly do it
The answer to your question is, you want the web server to respond to web requests which the client sends to the default port (80/443), but which the server actually receives on port 8080.
That means, as you can see, you need something in between that maps the ports between client and server. That way, the client sends on port 80 (default port used by web browsers), but it's actually received on port 8080 by the web server. Of course you will have to configure the web server to listen on port 8080, as this isn't standard, but it's easy and any web server should be able to have its listening ports specified.
The most usual way to do this would be within the router/firewall, via port mapping.
In simple terms, to do this, the router is given a rule, that anything received which has a destination IP of and destination port = 80, should be passed into the LAN with the destination port changed to 8080 instead. Neither the web server nor the client will be aware of the change (it's 100% handled by the router), so it will be 100% transparent to both of them. The client won't have ":8080" in its URL and won't need to redirect anything, since it queries port 80, and the web server can ignore port 80 and listen on 8080 only, since it never gets queries on port 80.
If you want a simple, straightforward way, similar to what a "DNS for ports" would do, this is probably the closest equivalent to what you're asking for in your question.