Let me rephrase your question as an example to make sure I've understood it correctly.
You have various services, let's say HTTP, IMAP, LDAP, etc... and you want them all to be reachable by connecting to "example.com" (no subdomain). But those services aren't all on the same host. It would be better if the clients used subdomains like "www.example.com", "imap.example.com", and so on because then you could just map those names in DNS to the appropriate address, but they aren't going to do that (at least some of the time), they're going to use plain "example.com". So whatever host answers at "example.com" is going to have to dispatch requests to the actual host that handles each service.
You can use a plain TCP forwarder, like an xinetd redirect as Sirex suggests, but with that comes all the usual problems of TCP forwarders: on the host that services the request
the IP connection appears to come from the forwarding server, not the original client, so the logs and other things end up wrong.
Application-level proxy servers (reverse proxy) are also an option for those protocols that have them. But you really actually wanted to send the whole TCP/UDP connection to the other server, not introduce a proxy server. Right.
Well, now that Linux supports DNAT for IPv6 you probably want to just use that.
Alternatively, if you are using some kind of hardware load balancer, that can probably do the job for you.
The better alternative would have been DNS SRV records. Those allow clients to look up not just a hostname in the DNS but a hostname + service name together, and get back a raw hostname or IP address plus a port number where they can connect. That allows you to map "example.com" for HTTP to one IP address and "example.com" for LDAP to a different IP address.
Unfortunately, though the SRV record standard is more than 15 years old, it never got much takeup, and clients just don't use it. So it's not an option. Actually, it is frequently used together with a select few protocols like SIP, but virtually all web browsers and IMAP clients and clients for most other protocols completely ignore it.