Is it possible (how?) to Route incoming UDP packets with one target IP to a destination IP that is resolved through a DNS query for a static URL?

I have a set of mobile devices that are configured to send UDP messages to an IP-address that is set in their SRAM. They don't have the capability to either store a URL, or resolve a URL to an IP address. The traffic going to the destination IP that the devices are sending to must pass through a gateway router under my control. The gateway router is running OpenWRT linux. I would like to route these UDP packets to Amazon Elastic Load Balancing (a AWS service). One constraint of Elastic Load Balancing is that (as far as I have been able to determine) DNS must be used to resolve the IP of the load-balancer (because at any time there may be more than one loadbalancer in use by AWS, and the choice of which to use is set at the DNS under Amazons control). That's the long story.

The short story is "How can I direct UDP packets routed through an OpenWRT router towards an address resolved through DNS at that router?"

I'm looking for a solution through IP chains/tables, firewall rules etc (or at least "plugins" with some history) rather than custom generated code.

Thank you all in advance for your help!

I'm looking for a solution through IP chains/tables, firewall rules etc (or at least "plugins" with some history) rather than custom generated code.

Not going to happen, sorry. Firewall and routing engines will typically resolve the DNS record to an IP address when the policy is activated, and Linux is no exception to this. The kernel will not perform additional DNS lookups to look for the DNS record changing.

The manpage for iptables makes this pretty clear, emphasis mine:

Address can be either a network name, a hostname, a network IP address (with /mask), or a plain IP address. Hostnames will be resolved once only, before the rule is submitted to the kernel. Please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea.

DNS traditionally does not have a role in these kinds of stacks because they are trying to keep the operation as deterministic as possible. Ignoring the complexity that implementing this code would add to the overall picture, it's also a security risk because you're essentially delegating control over your security policy to whoever controls the DNS record. Even if you're 100% certain that you trust the remote server operator, UDP based DNS is inherently spoofable protocol (DNSSEC protects against upstream forgery, but provides no protections between client and recursor aka "the last mile"), making this a terrible idea across the board. If you find a product that supports this, you probably shouldn't be supporting them!

You need to remove DNS from this equation. It's the wrong tool for the job at the layer you're functioning at.