Azure private dns resolver is a saas that provides dns. Once the resource is created, vnet links can be added to vnet of the resource to make it available to the linked vnets.
My question is: In a hub spoke, where the dns of all spoke vnets are configured to a routing appliance in the hub, and the vnet which holds the routing appliance has a vnet link to a dns forwarding ruleset, do I need to create a vnet link to a dns forwarding ruleset for all spoke vnets of is the one hub vnet link enough (because all dns traffic is routed through here)?
e.g.: spoke1-hub1
Spoke1 has dns configured on its vnet as the ip address of the firewall in hub1. Hub1 firewall has azure provided dns configured and a vnet link to private dns resolver.
AFAIK, Private DNS Resolver in a Hub and Spoke model makes sense to use when you resolve onPrem-2-Cloud (and vice versa) DNS Zones. As written in documentation, it is recomended design approach to use Inbound/Outbound Subnets, Forwarding Rule sets and Ruleset Links. => In case of this scenario Private DNS Zone and Azure Provided DNS will be resolved by the inbound endpoint. IMHO the Subnets should be placed behind the firewall if Azure Egress and Ingress should be inspected.
If you use Azure Firewall as DNS Proxy (with DNS Proxy enabled), Azure Firewall should be able to resolve Azure Provided DNS (Default DNS Server) and Private DNS Zones (e.g. private links in your VNETs and the Private DNS Zone linked to Hub - where the firewall resides). You must configure Azure Firewal as DNS Proxy in your services (or as in your case routing in UDR). Link
In both cases VNet peering is required. My suggestion is, use Private DNS Zones for your private links, as i understood from your scenario, you use cloud only hub-and-spoke model, with no on-Prem connectivity?