I can successfully resolve weatherstation.wunderground.com through unbound 1.9.0.
This one-time success may not be significant, though, even if we were using the exact same config for unbound, as there's no guarantuee a recursion would travel along the same DNS resolution chain. They may even differ by intention when DNS servers to be visited would depend on our respective locations.
In consequence, I find it hard to track down such issues, especially wihout access to the affected installation. Also, failures may well be attributable to misconfigured DNS servers along that chain, and you could do nothing about that, save from alerting their respective maintainers.
You probably should consider to also ask for help at unbound or wunderground.com, in case this would be a common recent issue.
For the time being, to at least mitigate your issue, you could consider to add a respective Local DNS record for weatherstation.wunderground.com in Pi-hole.
While that may be the easiest approach, it comes with the drawback of requiring you to manually update your local record in the event of IP address changes.
Instead, you could also opt for the slightly less easier option to forward requests for that domain to a public DNS server. That way, DNS resolution would also work even if weatherstation IPs would change.
Obviously, this approach comes with the drawback of exposing respective DNS requests to your chosen public resolver.
You'd have to create a custom dnsmasq configuration file, e.g. /etc/dnsmasq.d/42-forward-weatherstation.conf with the following content:
server=/weatherstation.wunderground.com/208.67.222.222
That would send any query for that domain to OpenDNS. Feel free to use any other public DNS you like by substituting with the appropriate IP address.
Then run a dnsmasq syntax check:
pihole-FTL dnsmasq-test
If ok, restart Pi-hole:
pihole restartdns
Keep in mind that either of those options is a workaround only.
You should reassess weatherstation.wunderground.com regularly and revert to normal if appropriate.