First one has to ask whether the packet actually originated from your host in the first place. Source IP spoofing happens all the time, and without context that log entry says nothing about the authenticity of the source IP.
Next question is if you are running a DNS server on that host. If there is no DNS server on that host, then the packet they logged is most likely spoofed. And then that's what you should explain to the hosting provider.
If you are running a DNS server, then that packet could be real, but that doesn't necessarily mean there is any reason to complain about it. You do have to ask yourself if you actually need to run a DNS server. If you are running a DNS server, that you don't need in the first place, shutting it down would be a good idea, regardless of the complaint.
Now let's for a moment assume you do have a reason to run a DNS server, and that the packet did in fact originate from your DNS server. Does that mean there is something you need to do?
In that case you should think about ensuring your DNS server cannot be abused in amplification attacks. However the above packet does not look like it was part of an amplification attack. In an amplification attack you would expect to see packets at least close to 512 bytes in size or 4KB if your DNS server supports it. The logged packet is only 50 bytes in size, which is tiny in comparison.
If you are running a DNS server, the most likely explanation for the above log entry is actually a misconfiguration of the firewall, which produced the log entry. Most likely there was a real legitimate DNS request going out and a legitimate DNS reply coming back. But the firewall for some reason had lost the connection tracking entry before the reply came back.
Also the wording is hinting that they dropped the packet rather than sending an ICMP error back. ICMP errors is one of the tools, which can be used to detect spoofing attacks and activate countermeasures.
If DNS servers applied all the best countermeasures against amplification attacks, that are technically possible, then blocking unexpected UDP packets without sending ICMP errors back would be like asking to be attacked.
Which parts of my reasoning are relevant to your case depends a bit on the details. But I hope the hosting provider will realize that the complaint is not valid, when they are presented with the right parts of it.