Yes kinda but that DNS request is still a unicast dest_address
You need to keep in mind it has nothing todo with connectionless or connection or state. ICMP is connectionless and works thru firewalls if allowed. 
With traditional layer3 devices, they make routing decision solely via the dst_address, unless you have RPF ( unicast verify ) or PBR routing going on.
Here we make choice that include; protocol, which interface it comes in, what src_address, but this ( PBR ) is not the normal and any router, still looks up the destination address going forward.
With multicast routing, the source address is just as important or more so than the group subscription address of the subscriber.
So this where the problems comes into play , & with routing and more so with Firewalls.
e.g in you dns request example,
you send a packet to the dst_addr x.x.x.x:53/udp. Any router(s) involved thru the path , don' t make any decision, based on the source of the client, but rather via of the dst_addr of the target
but in ..................
In mcast routing, they (multicast-routers) have more complexity due to the dst_group that a client is a member of, and the intra-routers, must show how know of the src_address(s) of the mcast and what interface to expect that src_address on, plus when and if I should forward it ( dense mode vrs sparse... igmp and group(s) subscriptions & leaves )
Your not technically routing to an " address" per se with multicast, sense an igmp subscriber could be at any part of the multicast tree.
A lot of the newer firewalls does allow you to route local multicast and have options for IGMP proxy and setting of PIM Dense/Sparse mode interfaces. But to do this over a IPSEC tunnel, is yet to be seen.
So unless you can define a tunnel interface, with ip_addres and PIM/IGMP multicast configurations, I highly doubt you can just send multicast traffic thru it ( ipsec/tunnel ) , without deploying a true native multicast architect underneath.
With traditional layer3 devices, they make routing decision solely via the dst_address, unless you have RPF ( unicast verify ) or PBR routing going on.
Here we make choice that include; protocol, which interface it comes in, what src_address, but this ( PBR ) is not the normal and any router, still looks up the destination address going forward.
With multicast routing, the source address is just as important or more so than the group subscription address of the subscriber.
So this where the problems comes into play , & with routing and more so with Firewalls.
e.g in you dns request example,
you send a packet to the dst_addr x.x.x.x:53/udp. Any router(s) involved thru the path , don' t make any decision, based on the source of the client, but rather via of the dst_addr of the target
but in ..................
In mcast routing, they (multicast-routers) have more complexity due to the dst_group that a client is a member of, and the intra-routers, must show how know of the src_address(s) of the mcast and what interface to expect that src_address on, plus when and if I should forward it ( dense mode vrs sparse... igmp and group(s) subscriptions & leaves )
Your not technically routing to an " address" per se with multicast, sense an igmp subscriber could be at any part of the multicast tree.
A lot of the newer firewalls does allow you to route local multicast and have options for IGMP proxy and setting of PIM Dense/Sparse mode interfaces. But to do this over a IPSEC tunnel, is yet to be seen.
So unless you can define a tunnel interface, with ip_addres and PIM/IGMP multicast configurations, I highly doubt you can just send multicast traffic thru it ( ipsec/tunnel ) , without deploying a true native multicast architect underneath.
