Above is the setting page for specifying DNS resolvers. My feature request is for the ability to specify custom port(s) for accessing those DNS servers. As of now, the servers specified in the picture above will be accessed via only port 53 when resolving domain names. But certain ISPs, such as mine, does DNS transparent proxies, which then redirect all DNS request to their servers. The ability to use custom ports should then help mitigates this problem.

I hope this feature request can be considered. Thanks.

If you're willing to give up proxying the DNS locally in the Mikrotik, you could assign your alternate DNS server address(es) directly in DHCP options and then put a dstnat rule for in-interface=lan
That would get the effect you want.

I was pondering whether the dstnat chain could be applied to the Mikrotik's own outbound connections, but it appears that this cannot be done. (dstnat only takes place in the prerouting phase, which is not traversed for locally-generated packets)

Another alternative would be to run a metarouter whose only purpose is to act as a DNS proxy. Then you could make the dstnat rule on the host router's virtual interface to the metarouter.
This would give nearly the same conditions as you want - but would obviosuly take up more system resources than just setting the port into the dns config.

The one thing I don't like about using dst-nat to do the same thing is lacks of failovers. In my picture above, if one server failed/unreachable, routerOS will retry with other servers in the list. With dst-nat, if the server specified in the top failed/unreachable, routerOS will not proceed to use the next dst-nat rule, causing the domain resolving process to fail.

Why don't you setup a VPN to some external server outside of that network, and run the DNS queries over that link?

PPTP and L2TP is blocked on the network. OpenVPN client still needs to be updated.

The one thing I don't like about using dst-nat to do the same thing is lacks of failovers. In my picture above, if one server failed/unreachable, routerOS will retry with other servers in the list. With dst-nat, if the server specified in the top failed/unreachable, routerOS will not proceed to use the next dst-nat rule, causing the domain resolving process to fail.

That's not true at all.

Suppose the LAN clients are assigned to use DNS servers 1.2.3.4 and 1.2.3.5
In this case, you would make dstnat rules like this:
chain=dstnat protocol=udp dst-address=1.2.3.4 dst-port=53 action=dst-nat to-address=1.2.3.4 to-ports=5353
chain=dstnat protocol=udp dst-address=1.2.3.5 dst-port=53 action=dst-nat to-address=1.2.3.5 to-ports=5353

Leave the dst IP address alone and change only the dst port. You have to make one rule for each dst address, though.
Or, you could be sloppy and do it with one rule:
chain=dstnat protocol=udp dst-port=53 action=dst-nat to-ports=5353

You may also wish to add the "in-interface=LAN" criteria to the above rules to limit them so they only apply to traffic from your LAN.

PPTP and L2TP is blocked on the network. OpenVPN client still needs to be updated.

SSTP normally works on every network. While it is a bad VPN in general, for DNS queries it should be OK.
Of course you need a server outside this ISP network, but you require that anyway to service DNS on a nonstandard port.
I know some DNS providers offer this service as standard ("dnscrypt") but unfortunately it is not simply "DNS over SSTP"
so you need a special client for it and RouterOS does not have it.

Well, I think it is questionable to add features to RouterOS merely to work around such blocks. The next thing
they implement is deep packet inspection and it again does not work anymore. Better find another ISP.

I am in the same boat, and I definitely need the local DNS proxy as I uses a couple of static DNS domains for my local servers.
As for the MetaRouter solution, it is unfortunately not available on my hardware: RB750Gr3.

Really wishes this would be solvable. Or even better, having DNS-over-TLS, DNS-over-HTTPS, or even DNSCrypt. Or is there a DNS Resolver package?

SSTP normally works on every network. While it is a bad VPN in general

i'm glad someone pointed this out. it's the TCP over TCP effect, that can cause issues over congested links. don't know it is covered anywhere in the MT docs, however.

The next thing they implement is deep packet inspection and it again does not work anymore. Better find another ISP.

trust me, they don't. if one needs to cope with 10s or 100s of gigabits of bandwidth, the expenses related to "DPI" are horrible. no reasonable thinking tech exec will do this as it would cost to much investment + effort to deliver lower quality service.
otoh i don't know whether they allowed to do this anyway - outside the US network neutrality is still a thing.

I hope this feature will be introduced in the next release!
Sending the dev team lots of love